MySQL HA 方案 MMM、MHA、MGR、PXC 对比
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