首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >MHA 源码阅读 第04期:问题总结

MHA 源码阅读 第04期:问题总结

作者头像
数据库交流
发布于 2022-04-25 08:36:23
发布于 2022-04-25 08:36:23
6710
举报
文章被收录于专栏:悦专栏悦专栏

作者简介

无为,前饿了么 MySQL DBA,现就职于某知名互联网公司,对 MySQL、 Redis、PostgrepSQL 等主流数据库有一定了解,拥有丰富的一线运维经验。

这是专栏《MHA 源码阅读》的最后一篇,感谢您的阅读。

由于能力有限,系列文章难免会存在错误或者遗漏,如果您有任何建议,可以私信给“悦专栏”公众号,我们会第一时间进行反馈。

在前面几期,我们聊了 MHA 的部分源码。小编在源码阅读过程中,想到了几个问题,在这一节跟大家一起交流下。

1 MHA+VIP 缺点

1.1 如果 MHA manger 节点和数据库 master 节点在不同的网络,可能会因为短时间的网络问题触发 failover 而造成 VIP 脑裂现象。

解决办法:

  • 设置 masterha_secondary_check 脚本增加第三方检测。
  • 尽量保证 manger 节点在同一网段,并添加监控。

1.2 如果 MySQL 采用单机多实例部署方式,VIP 的切换将会影响剩下实例的使用。

解决办法:采用非 VIP 切换方式,DNS切换、中间件切换、zk 切换等;

2 GTID 的潜在风险

2.1 由阅读源码可知在 GTID 模式下做 failover 会跳过 save_master_binlog。

解决办法:

  • 配置 binlog server 或者把主库配置成 binlog server,虽然在 save_master_binlog 阶段不做 save binlog,但是在 recover_master 过程中会调用 binlog server 去补齐日志。
  • 升级 MySQL 至 5.7 版本并采用半同步复制模式。

2.2 新主 binlog 缺失问题。

由于 GTID 模式不指定复制位点,直接使用 GTID 编号来同步,所以实际在使用中,切换之后新的 GTID 必须是连续才能设置成功。这就可能会出现新主库在很久以前执行过类似更改用户权限这类产生 binlog 事件的命令,随着时间的推移,这些日志可能已经被清理掉了。这样被提升为新主后就会出现从库找不到 binlog 的情况。

解决办法:从库开启只读模式、从库用户只提供 select 权限、设置 binlog 事件监控等。

3 Failover 相关问题

3.1 MHA 在完成 failover 后会退出。

解决办法:部署 daemontools 工具,使 manager 以守护进程的方式运行。

3.2 两次 failover 时间小于 8 小时导致 failover 失败问题。

解决办法:启动时增加 --ignore_last_failover 参数。

3.3 因某一 slave 故障导致 failover 失败问题。

解决办法:配置文件中添加 ignore_fail 参数。

4 其他问题

4.1 Relay log 可能会被误清理的问题。

MySQL 主从复制在缺省情况下,从库的 relay log 会在 SQL线程执行完毕后被自动删除,但是在 MHA 场景下,某些滞后从库的恢复依赖于其他从库的relay log。

解决办法:

  • 设置 relay_log_purge 参数为 0。
  • 使用 purge_relay_logs 脚本定时清理 relay log。

Tip:purge_relay_logs 在清理 relay log 过程中会采用 ln -l 方式归档最近一个 relay log,不会出现 recover slave 过程中找不到 relay log 的情况。

4.2 ping_type 选择。

MHA 默认是建立一个长连接,然后通过 select 1 (ping_type=SELECT) 检查连通性。但是在某些情况下,最好是通过连接/断开的方式检查,因为它可以更严格的检查 tcp 可连接性,设置 ping_type=connect 开启。

4.3 MySQL 三层架构问题怎么使用 MHA?

解决办法:设置 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 源码阅读 第01期:MasterMonitor

MHA 源码阅读 第02期:MasterFailover

MHA 源码阅读 第03期:MasterRotate

MHA 源码阅读 第04期:问题总结

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-10-29,如有侵权请联系 cloudcommunity@tencent.com 删除
目录
  • 这是专栏《MHA 源码阅读》的最后一篇,感谢您的阅读。
  • 在前面几期,我们聊了 MHA 的部分源码。小编在源码阅读过程中,想到了几个问题,在这一节跟大家一起交流下。
  • 1 MHA+VIP 缺点
  • 2 GTID 的潜在风险
  • 3.1 MHA 在完成 failover 后会退出。
  • 3.2 两次 failover 时间小于 8 小时导致 failover 失败问题。
  • 3.3 因某一 slave 故障导致 failover 失败问题。
  • 4.1 Relay log 可能会被误清理的问题。
  • 4.2 ping_type 选择。
  • 4.3 MySQL 三层架构问题怎么使用 MHA?
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档