最近碰到MySQL的MHA维护的事情，想着把MHA架构技术点整理下。MySQL中MHA高可用架构广泛应用于5.6 和5.7的版本。同时操作系统支持6,7系列（CentOS6.* ，CentOS7.* ）。8,9系列因为依赖变更，脚本无法兼容操作系统环境，安装比较困难。
MHA概述
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，MHA是由
日本人开发，是一套优秀的MySQL故障切换和主从复制的高可用软件。采用perl语言编写的一个脚本管理工具。
早期适配复制Position模式，之后GTID模式（需要自己修改部分代码，网上有修改方式）。
它的特点是在保障高可用自切换的前提下，最大限度的保障主从数据的一致性。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且 能做到故障自动检测和切换，扩展性较好，可靠性更高。
MHA官网：
https://code.google.com/archive/p/mysql-master-ha/
GitHub地址：
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
文档：
https://github.com/yoshinorim/mha4mysql-manager/wiki
MHA工作原理：
主库实例挂掉但是ssh还能连接：
- 1、监控到主库宕机，选择一个新的主，被选择的新主会取消从库的角色（ reset slave）
选择标准：
一是根据其他从库的binlog日志的位置选择最新的从库作为新的主库
二是如果设置了半同步从库，直接选择半同从库作为新的主库 - 2、从库通过MHA自带的脚本程序，通过ssh向主库索取缺失部分的binlog
- 3、其他从库与新的主库从新构建主从，继续提供服务
- 4、如果由vip机制，将VIP从原来的主库漂移到新的主库，让应用无感知
主节点服务器宕机（ssh已经连接不上）：
- 1、监控到主机宕机后，尝试ssh连接，连接失败
- 2、通过上边所讲的选择标准选择新的主库
- 3、计算从库之间的relay-log的差异，补偿到新的其他从库
- 4、其他从库从新与新主构建主从关系，继续提供服务
- 5、如果由VIP机制，将VIP从原主漂移到新主，让应用无感知
- 6、如果有binlog server 机制，会继续将binlog server中缺失的事物，补偿到新的主库
组件
MHA由Manager（管理节点）和MHA Node（数据节点）组成
1)MHA Manager:可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
2)MHA Node:
部署在所有运行MySQL的服务器上，无论是master还是slave。通常由MHA Manager的脚本触发，无需人工操作。主要作用有三个。
1）保存二进制日志
如果能够访问故障master，会拷贝master的二进制日志
2）应用差异中继日志
从拥有最新数据的slave上生成差异中继日志，然后应用差异日志
3）清除中继日志
在不停止SQL线程的情况下删除中继日志
备注：在MHA实现Master故障切换过程中，MHA Node会试图访问故障的master（通过SSH），如果可以访问（不是硬件故障，比如InnoDB数据文件损坏等），会保存二进制文件，以最大程度保 证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。
3）一次完整MHA故障切换流程：
a)保存故障的master节点的binlog日志;
b)Manager查找最新更新的slave节点；
c)应用差异的relay log日志到其他的slave；
d)在slave节点上应用从master保存的binlog日志；
e)提升一个slave为新的master；
f)使其他的slave连接新的master进行复制。
优缺点
| 优点 | 缺点 |
|---|---|
| 故障自动检测和切换 | 需开通SSH |
| 扩展性较好 | 数据一致性 |
| 可靠性更高 | 管理节点是单节点 |
| 基于原生复制 | 有可能会存在脑裂问题 |
备注：脑裂问题是网络切割导致的，现在的网络情况越来越好，但一个局域网 很少触发。
运维上面需要注意：
1.scp拷贝文件时 进行限流操作 或 使用多个网卡
2.arpping要切换的时候 进行清除动作:
my $ssh_start_vip = "/sbin/ifconfig ebond1.2111:$key $vip/24";
my $ssh_stop_vip = "/sbin/ifconfig ebond1.2111:$key down";
my $ssh_send_garp = "/sbin/arping -U $vip -I ebond1.2111 -c 1";
3.故障切换时，可以自行判断哪个从库与主库的数据最接近，就切换到上面，可以减少数据的丢失，保证数据的一致性。
4.支持 binlog server，可提高 binlog 传送效率，进一步减少数据丢失风险。 5.可以配置 MySQL 5.7 的增强半同步，来保证数据的时时同步。
除吃之外，会有一些比较棘手的缺点：
- 自动切换的脚本太简单，而且比较老化，建议后期逐渐完善。
- 搭建MHA架构，需要开启操作系统互信协议，所以对于系统安全性来说，是个不小的考验。
常见错误
1.错误信息「Can’t locate Log/Dispatch.pm in @INC」
[shell]# masterha_check_ssh --conf=/opt/mha_manager/app1.cnf
Can't locate Log/Dispatch.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/share/perl5/MHA/SSHCheck.pm line 29.
BEGIN failed--compilation aborted at /usr/local/share/perl5/MHA/SSHCheck.pm line 29.
Compilation failed in require at /usr/local/bin/masterha_check_ssh line 25.
BEGIN failed--compilation aborted at /usr/local/bin/masterha_check_ssh line 25.
该错误提示是因为MHAManager主机的软件未安装完整，将所需软件安装:
2.错误信息 「SSH Configuration Check Failed!」
[error][/usr/local/share/perl5/MHA/SSHCheck.pm, ln111] SSH connection from root@192.168.1.14(192.168.1.14:22) to root@192.168.1.15(192.168.1.15:22) failed!
SSH Configuration Check Failed!
at /usr/local/bin/masterha_check_ssh line 44.
集群中ssh免密登陆未设置好，仔细检查并重新设置好集群中的全部机器的ssh免密登录即可。
总结
虽然HA虽然在今天的眼光看来有些“过时”，但它确实为整个MySQL高可用领域奠定了坚实的基础。MHA的过时，是因为技术从“手工打造”走向了“原生集成”和“云原生”。但它所确立的“监测-选主-提升-切换”这一套故障处理流程，作为高可用领域的经典范式，将长久地存在于每一个MySQL DBA的认知体系中。理解MHA，就像是理解了内燃机的工作原理，再看现在的混动汽车、电动汽车，会更容易把握其本质。
