
作者简介
无为,前饿了么 MySQL DBA,现就职于某知名互联网公司,对 MySQL、 Redis、PostgrepSQL 等主流数据库有一定了解,拥有丰富的一线运维经验。
由于能力有限,系列文章难免会存在错误或者遗漏,如果您有任何建议,可以私信给“悦专栏”公众号,我们会第一时间进行反馈。
1.1 如果 MHA manger 节点和数据库 master 节点在不同的网络,可能会因为短时间的网络问题触发 failover 而造成 VIP 脑裂现象。
解决办法:
1.2 如果 MySQL 采用单机多实例部署方式,VIP 的切换将会影响剩下实例的使用。
解决办法:采用非 VIP 切换方式,DNS切换、中间件切换、zk 切换等;
2.1 由阅读源码可知在 GTID 模式下做 failover 会跳过 save_master_binlog。
解决办法:
2.2 新主 binlog 缺失问题。
由于 GTID 模式不指定复制位点,直接使用 GTID 编号来同步,所以实际在使用中,切换之后新的 GTID 必须是连续才能设置成功。这就可能会出现新主库在很久以前执行过类似更改用户权限这类产生 binlog 事件的命令,随着时间的推移,这些日志可能已经被清理掉了。这样被提升为新主后就会出现从库找不到 binlog 的情况。
解决办法:从库开启只读模式、从库用户只提供 select 权限、设置 binlog 事件监控等。
3 Failover 相关问题
解决办法:部署 daemontools 工具,使 manager 以守护进程的方式运行。
解决办法:启动时增加 --ignore_last_failover 参数。
解决办法:配置文件中添加 ignore_fail 参数。
4 其他问题
MySQL 主从复制在缺省情况下,从库的 relay log 会在 SQL线程执行完毕后被自动删除,但是在 MHA 场景下,某些滞后从库的恢复依赖于其他从库的relay log。
解决办法:
Tip:purge_relay_logs 在清理 relay log 过程中会采用 ln -l 方式归档最近一个 relay log,不会出现 recover slave 过程中找不到 relay log 的情况。
MHA 默认是建立一个长连接,然后通过 select 1 (ping_type=SELECT) 检查连通性。但是在某些情况下,最好是通过连接/断开的方式检查,因为它可以更严格的检查 tcp 可连接性,设置 ping_type=connect 开启。
解决办法:设置 multi_tier_slave 参数,从 MHA Manager0.52 版本,支持多主机复制配置。默认情况下,它是不允许设置三个或三个以上层复制主机在 MHA 配置文件。
4.4 MHA failover 过程中 new master 和 slaves 的恢复顺序是咋样的?
答:先对 new master 做日志补偿,然后对 slaves 做日志补偿,详情见:MHA 源码阅读 第02期:MasterFailover。
4.5 MHA 是怎样获取 latest slave 的?
答:通过 show slave status 命令获取 Master_Log_File 、Read_Master_Log_Pos 值比较来获取 latest slave ,详情可见:MHA 源码阅读 第02期:MasterFailover。
专栏《MHA 源码阅读》系列文章推荐
MHA 源码阅读 第04期:问题总结