MySQL高可用MHA架构方案

2022-04-27
2200

高可用

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免认证登录配置,存在一定的安全隐患
没有提供从服务器的读负载均衡功能