mysql 高可用 vip_MySQL高可用集群的VIP切换

本文介绍了在MySQL高可用集群中实现VIP切换的目的、基础环境、具体步骤、新主判定条件及相关注意事项。强调了在切换过程中数据一致性的重要性,提出了在不同场景下的应用策略,并提醒注意防止脑裂等问题。
摘要由CSDN通过智能技术生成

一、目的

实现在mysql高可用集群的VIP切换,不涉及数据补偿

二、基础环境

python3.0+

三、具体三大部分

1、启动条件检测

检测集群是否down机 方式 select 1

检测主库是否有VIP绑定 方式是 采用vip进行连接

检测从库是否正常复制和延迟

检测从库是否开启binlog中继日志写入

检测集群是否已经开启了增强半同步方式

检测集群是否开启了GTID复制

2、高可用切换流程

主库down机 如果失败则进行尝试三次进行判定

摘掉原主VIP,如果能进行SSH登录的话

从slave节点中选择新主 判断方式

打开new master节点读写功能

new master上绑定VIP

在日志中生成change语句

发送报警邮件

3、新主判定条件

选择集群从库加入选举组,条件是sql_thread 状态为YES

根据集群的成员对比 binlog(name and postion) 进行排序,选择头部成员

对新主进行进一步判定,判定条件为second_master_behind

如果为0,确保sql_thread已应用完全部relay-log

第三步判断成功,则针对新主采取以下操作:

set global read_only= off 关闭读写

ifconfig vip 绑定VIP

四、相关注意点

1、云环境和多实例环境并不适合VIP环境,所以此文章不适用,不过大体原理相同

2、数据补偿依赖增强半同步复制,这是必须的

3、在绑定VIP之前需要arpping VIP,防止出现脑裂问题

4、采用一个集群启动一个进程方式,防止出现问题互相影响,当然如果你的python能力很高,可以随意改造

5、监控好你的从库健康情况,防止高可用切换的时候无健康从库可用

五、关于应用场景情况

1、对于集群都出现延时的情况比较少见

2、一旦发生这种情况而又导致切换

重要场景 会坚持relay-log应用完才会进行切换,业务响应排后

非重要场景 不考虑relay-log应用情况进行直接

六、总结

本文章只是提供一个思路,如有意见可以联系本人进行修订

七、切换日志图示

get-article-detail-155532.html

de9aac4c9a1434469c5e7ac91c3e5f75.png

本文选自知数堂学员-邓志航的文章;

邓志航,MySQL DBA,天生的MySQL爱好者,热衷于为他人解决问题,善于总结和分享。

对数据平台构建和排查疑难问题有非常浓厚的兴趣

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值