一 目的 实现在mysql高可用集群的VIP切换,不涉及数据补偿
二 基础环境 python3.0+
三 具体三大部分
一 启动条件检测
1 检测集群是否down机 方式 select 1
2 检测主库是否有VIP绑定 方式是 采用vip进行连接
3 检测从库是否正常复制和延迟
4 检测从库是否开启binlog中继日志写入
5 检测集群是否已经开启了增强半同步方式
6 检测集群是否开启了GTID复制
二 高可用切换流程
1 主库down机 如果失败则进行尝试三次进行判定
2 摘掉原主VIP,如果能进行SSH登录的话
3 从slave节点中选择新主 判断方式
4 打开new master节点读写功能
5 在new master上绑定VIP
6 在日志中生成change语句
7 发送报警邮件
三 新主判定条件
1 选择集群从库加入选举组,条件是sql_thread 状态为YES
2 根据集群的成员对比 read binlog(name and postion) 进行排序,选择头部成员
3 对新主进行进一步判定,判定条件为second_master_behind
如果为0,确保sql_thread已应用完全部relay-log
4 第三步判断成功,则针对新主采取以下操作
1 set global read_only= off 关闭读写
2 ifconfig vip 绑定VIP
四 相关注意点
1 云环境和多实例环境并不适合VIP环境,所以此文章不适用,不过大体原理相同
2 数据补偿依赖增强半同步复制,这是必须的
3 在绑定VIP之前需要arpping VIP,防止出现脑裂问题
4 采用一个集群启动一个进程方式,防止出现问题互相影响,当然如果你的python能力很高,可以随意改造
5 监控好你的从库健康情况,防止高可用切换的时候无健康从库可用
五 关于应用场景情况
1 对于集群都出现延时的情况比较少见
2 一旦发生这种情况而又导致切换
重要场景 会坚持relay-log应用完才会进行切换,业务响应排后
非重要场景 不考虑relay-log应用情况进行直接
六 总结
本文章只是提供一个思路,如有意见可以联系本人进行修订,欢迎
七 补充模拟故障场景
1 mysql 挂掉后 短时间无法重启
2 mysql挂掉后 迅速自启动
3 服务器异常宕机
4 mysql最大连接数被打满
