作者:姚嵩

地球人,爱好音乐,动漫,电影,游戏,人文,美食,旅游,还有其他。虽然都很菜,但毕竟是爱好。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


参数说明:

https://github.com/openark/orchestrator/blob/master/go/config/config.go

⽬的:

⽤ 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 root@10.186.65.11 "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 root@10.186.65.11 "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 root@10.186.65.11 "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 分钟时,切换失败,当禁⽤了全局恢复时,不会进⾏⾃动切换。

声明:

测试场景很多,但测试时间有限,如有具体场景需求,再具体测试。

如测试结果有出⼊,欢迎探讨。

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


avatar
100
  Subscribe  
提醒