作者:姚嵩

地球人,爱好音乐,动漫,电影,游戏,人文,美食,游览,还有其余。尽管都很菜,但毕竟是喜好。

本文起源:原创投稿

*爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。


参数阐明:

https://github.com/openark/or...

⽬的:

⽤ orchestrator 配置 MySQL 集群的⾃动切换。

已接管的数据库实例(1主1从架构):

10.186.65.5:330710.186.65.11:3307

orchestrator 的相干参数:

 "RecoveryIgnoreHostnameFilters": [],  "RecoverMasterClusterFilters": ["*"],  "RecoverIntermediateMasterClusterFilters":["*"],  "ReplicationLagQuery": "show slave status" "ApplyMySQLPromotionAfterMasterFailover": true,  "FailMasterPromotionOnLagMinutes": 1,

局部测试场景(因为orch是⾼可⽤架构,所以以下试验命令都是在raft-leader节点上执⾏)

案例1:

场景:

敞开 master,确认是否会切换(提早 < FailMasterPromotionOnLagMinutes)

操作:

# 确认已有的集群  orchestrator-client -c clusters# 查看集群拓扑,集群为 10.186.65.11:3307  orchestrator-client -c topology -i 10.186.65.11:3307 # 敞开master节点   ssh [email protected] "service mysqld_3307 stop" # 再次确认已有的集群,原集群会拆分为2个集群   orchestrator-client -c clusters # 查看集群拓扑,此时集群为 10.186.65.5:3307   orchestrator-client -c topology -i 10.186.65.5:3307 

论断:

  1. 切换胜利;
  2. 新的master节点read_only 和 super_read_only 都敞开了,能够读写;

试验截图:

案例2

场景:

敞开master,确认是否会切换(提早 > FailMasterPromotionOnLagMinutes)

FailMasterPromotionOnLagMinutes 配置的是1分钟,也就是60s

操作:

# 查看运⾏态的FailMasterPromotionOnLagMinutes参数值  orchestrator -c dump-config --ignore-raft-setup | jq .FailMasterPromotionOnLagMinutes# 确认已有的集群  orchestrator-client -c clusters# 查看集群拓扑,集群为 10.186.65.11:3307  orchestrator-client -c topology -i 10.186.65.11:3307# 创立提早slave(假如此时Slave为10.186.65.5:3307)  stop slave ;  change master to master_delay=120;  start slave ;  或者  orchestrator-client -c delay-replication -i 10.186.65.5:3307 -S 120# 期待120s  sleep 120# 查看集群拓扑,集群为 10.186.65.11:3307  orchestrator-client -c topology -i 10.186.65.11:3307# 敞开master节点   ssh [email protected] "service mysqld_3307 stop"# 再次确认已有的集群  orchestrator-client -c clusters# 查看集群拓扑,此时集群依然为 10.186.65.11:3307   orchestrator-client -c topology -i 10.186.65.11:3307

论断:

  1. 未切换;
  2. 当 备节点提早 ⼤于 FailMasterPromotionOnLagMinutes 时,不会发⽣切换。

试验截图:

案例3:

场景:

禁⽤全局复原的状况下,敞开master(提早 < FailMasterPromotionOnLagMinutes)

操作:

# 敞开全局复原  orchestrator-client -c disable-global-recoveries   orchestrator-client -c check-global-recoveries # 确认已有的集群  orchestrator-client -c clusters# 查看集群拓扑,集群为 10.186.65.11:3307  orchestrator-client -c topology -i 10.186.65.11:3307# 敞开master节点   ssh [email protected] "service mysqld_3307 stop"# 再次确认已有的集群  orchestrator-client -c clusters# 查看集群拓扑   orchestrator-client -c topology -i 10.186.65.11:3307

论断:

  1. 未切换;
  2. 当敞开了全局复原时,不会进⾏切换。

试验截图:

总结:

配置了 orchestrator 后,能够配置⾃动切换的 cluster 范畴,参数蕴含不限于:

RecoveryIgnoreHostnameFilters

RecoverMasterClusterFilters

RecoverIntermediateMasterClusterFilters

能够配置收否切换的条件,参数蕴含不限于:

FailMasterPromotionOnLagMinutes

ReplicationLagQuery

当提早超过 FailMasterPromotionOnLagMinutes 分钟时,切换失败,当禁⽤了全局复原时,不会进⾏⾃动切换。

申明:

测试场景很多,但测试工夫无限,如有具体场景需要,再具体测试。

如测试后果有出⼊,欢送探讨。

另可能存在各种因素阻⽌切换,不在此⽂章探讨范畴内。