MySQL高可用MHA架构方案

一、完整的MHA的架构方案

二、MHA故障发现与转移过程

MHA在启动的时候会有前置检查

MHA会每3s向主节点发送一个select 1 的sql语句，看主节点能不能执行成功，并且把1返回，如果能正常的返回那么证明现在的主节点是可以使用的，如果连续ping3都无法通信的话，现在MHA就会认为主节点是存在问题的，但是可能是网络的原因，所以HMA manager会通知所有的从属节点，slave1 MHA node，slave2 MHA node等，尝试使用SSH连接主节点，如果从属节点也无法连接到服务器的时候，就会认为主节点挂掉了，就会执行故障转移的操作。

故障发现的过程：

首先会切断VIP虚拟IP和主节点的连接，同时主从之间的连接也会断开，然后MHA manager会连接到binlog server备份服务器，然后获取备份服务器的binlog日志，把binlog日志保存到MHA manager服务器上。

故障转移的过程：

首先从属服务器之间会进行数据的比对，作为MHA manager会下发指令进行故障转移，会查看那个节点的relaylog是最新的，查询到最新的之后，作为最新的节点服务器就会向所有的节点服务器发送差异数据。把缺失的日志内容发送给节点服务器，然后同步数据。首先要保证，从属服务器节点之间的数据是同步的

虽然所有的从属节点的数据都是同步的，但是和备份服务器里面的binlog还是存在差异的，然后MHA manager 会把从备份服务器里面拿到的binlog日志和从节点的binlog会进行比较，把存在差异性的部分发往每一个从属节点，从属服务器接收到差异之后，与当前的binlog合并并应用，这样所有的从属服务器的数据和我们主服务的数据就同步了。

然后就到了选择那个服务器作为主服务器：
方案一：指定谁是主

方案二：看那个的slave的日志是最新的

方案三：按注册实例列表向后选择

最后MHA manager 会让VIP虚拟IP指向新的主服务器

原有的主服务器恢复后，会作为从服务器来使用，这个会由MHA自动来完成的

MHA的优缺点：
优点：
由per语言开发的开源工具
可以支持基于GTID的复制模式
当主DB不可用时，从多个从服务器中选举出来新的主DB
提供了主从切换和故障转移功能，在线故障转移时不易丢失数据
同一个监控节点可以监控多个集群

缺点：
需要编写脚本或利用第三方工具来实现VIP的配置
MHA启动后只只监控主服务器是否可用，没办法监控从服务器
需要基于SSH免认证登录配置，存在一定的安全隐患
没有提供从服务器的读负载均衡功能