-
用途
- 对MySQL主从复制集群的Master的健康监控。
- 当Master宕机后把写VIP迁移到新Master。
- 重新配置集群中的其他Slave从新Master同步
-
MMM架构
主服务器发生故障时,
1.主备服务器切换为新的主服务器:
(1)主备服务器设置read_only=off。
(2)主备服务器迁移写VIP到自己。
2.从服务器切换指向新的主服务器:
(1)完成原主服务器上已复制日志的恢复。
(2)使用Change Master to命令连接指向新的主服务器。
-
MMM架构优点
-
提供了读写VIP的配置,使得读写请求都可以做到高可用。
- 工具包相对完善,不需要额外开发脚本。
- 完成故障转移后,可以继续对MySQL集群进行高可用监控。
-
MMM架构缺点
-
故障切换简单粗暴易丢事务。解决方案:使用MySQL5.7及之后的半同步复制。
- 原生不支持GTID的复制方式。解决方案:自行修改perl脚本实现。
- 社区不活跃,很久未更新版本了。
- 需要的机器和IP地址资源较多。
-
MHA架构
主服务器发生故障时,
1.选举具有最新更新的Slave从节点。
2.尝试从宕机的Master主节点保存bin_log。
3.应用差异的中继relay_log到其他Slave从节点。
4.应用从Master主节点保存的bin_log。
5.提升选举出的Slave从节点为新的Master主节点。
6.配置其他Slave从节点从新的Master主节点主从同步。
-
MHA架构优点
-
既支持日志点的主从同步,也支持GTID的主从同步。
- 可从多个Slave中选举出最合适的新Master,无需单独准备一个Master备机。
- 尝试从老Master尽可能多的保存和获取未同步日志。
-
MHA架构缺点
-
未必能获取到老Master未同步日志。解决方案:使用MySQL5.7及之后的半同步复制。
- 需要自行开发写VIP转移脚本。
- 只保证了Master高可用,未保证Slave高可用。