MySQL HA 方案 MMM、MHA、MGR、PXC 对比

MySQL高可用架构

MMM

(Multi Master Replication Manager)

 

资源	数量	说明
主DB	2	用于主备模式的主主复制
从DB	0~N台	可以根据需要配置N台从服务器
IP地址	2n+1	N为MySQL服务器的数量
监控用户	1	用户监控数据库状态的MySQL用户(replication)
代理用户	1	用于MMM代理端改变read_only状态

故障转移步骤：

• Slave服务器上的操作

  • 完成原主上已经复制的日志恢复

  • 使用Change Master命令配置新主

• 主服务器上操作

  • 设置read_only关闭

  • 迁移VIP到新主服务器

优点：

• 提供了读写VIP的配置，试读写请求都可以达到高可用

• 工具包相对比较完善，不需要额外的开发脚本

• 完成故障转移之后可以对MySQL集群进行高可用监控

缺点：

• 故障简单粗暴，容易丢失事务，建议采用半同步复制方式，减少失败的概率

• 目前MMM社区已经缺少维护，不支持基于GTID的复制

适用场景：

• 读写都需要高可用的

• 基于日志点的复制方式

MHA

（MySQL Master High Availability）

需要资源：

资源	数量	说明
主DB	2	用于主备模式的主主复制
从DB	2~N台	可以根据需要配置N台从服务器
IP地址	n+2	N为MySQL服务器的数量
监控用户	1	用户监控数据库状态的MySQL用户(replication)
复制用户	1	用于配置MySQL复制的用户

MHA采用的是从slave中选出Master，故障转移：

• 从服务器：

  • 选举具有最新更新的slave

  • 尝试从宕机的master中保存二进制日志

  • 应用差异的中继日志到其它的slave

  • 应用从master保存的二进制日志

  • 提升选举的slave为master

  • 配置其它的slave向新的master同步

优点：

• MHA除了支持日志点的复制还支持GTID的方式

• 同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。

缺点：

• MHA需要自行开发VIP转移脚本。

• MHA只监控Master的状态，未监控Slave的状态

MGR

（MySQL Group Replication）

支持多主模式，但官方推荐单主模式：

• 多主模式下，客户端可以随机向MySQL节点写入数据

• 单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理.

// 查看MGR的组员
select * from performance_schema.replication_group_members;
// 查看MGR的状态
select * from performance_schema.replication_group_member_stats;
// 查看MGR的一些变量
show variables like 'group%';
// 查看服务器是否只读
show variables like 'read_only%';

优点：

• 基本无延迟，延迟比异步的小很多

• 支持多写模式，但是目前还不是很成熟

• 数据的强一致性，可以保证数据事务不丢失

缺点:

• 仅支持innodb

• 只能用在GTID模式下，且日志格式为row格式

适用的业务场景：

• 对主从延迟比较敏感

• 希望对对写服务提供高可用，又不想安装第三方软件

• 数据强一致的场景

Percona的PXC

Percona XtraDB Cluster是MySQL高可用性和可扩展性的解决方案, 的特性如下：

• 同步复制，事务要么在所有节点提交或不提交。

• 多主复制，可以在任意节点进行写操作。

• 在从服务器上并行应用事件，真正意义上的并行复制。

• 节点自动配置。

• 数据一致性，不再是异步复制。

优点：

• 当执行一个查询时，在本地节点上执行。因为所有数据都在本地，无需远程访问。

• 无需集中管理。可以在任何时间点失去任何节点，但是集群将照常工作，不受影响。

• 良好的读负载扩展，任意节点都可以查询。

缺点：

• 加入新节点，开销大。需要复制完整的数据。

• 不能有效的解决写缩放问题，所有的写操作都将发生在所有节点上。

• 有多少个节点就有多少重复的数据。

 

	MMM	MHA	MGR	PXC
优点		成熟稳定、对MySQL侵入小、 宕机后保证数据一致	原生高可用、数据一致性保证、支持多主	类似MGR
缺点	太旧，2010年后停止维护；仅支持基于binlog的同步 不支持；MySQL5.6以后的提供的多线程同步技术 没有读负载的功能 主从切换时，容易造成数据丢失 ；MMM监控服务存在单点故障，避免的监控服务单点，需要自行实现	选主方式过时、需要配合第三方脚本进行自动切换；管理节点单点；MySQL异步复制中的数据丢失，不能保证数据强一致性	管理不方便（需配合mysql-shell）	性能损耗大（降低为1/3）、 大事务会卡住整个集群、需要用第三方发行版MySQL

---

限制与不足

• 仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测；

• 必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set

• COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景

• 目前一个MGR集群最多支持9个节点

• 不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚

• 二进制日志不支持binlog event checksum

---

参考

https://juejin.cn/post/6844903812700831752

https://tech.meituan.com/2017/06/29/database-availability-architecture.html

https://cloud.tencent.com/developer/article/1054465

https://www.zhihu.com/question/53617036/answer/135776740

https://juejin.cn/post/6844903785848897543

https://www.talkwithtrend.com/Question/416891-2877659

https://my.oschina.net/Declan/blog/3114672