1. MGR简介 | 深入浅出MGR

关注

原创最新推荐文章于 2026-05-17 12:30:45 发布 2.7k 阅读 AI 写同款· GEO 优化 ›

GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。

MGR是MySQL Group Replication的缩写，即MySQL组复制。

在以往，我们一般是利用MySQL的主从复制或半同步复制来提供高可用解决方案，但这存在以下几个比较严重的问题：

因为上述几个明显的缺点，因此MySQL推出了全新的高可用解决方案 -- 组复制，这是本系列文章要着重介绍的新特性。

MGR是MySQL 5.7.17开始引入的，但随着5.7版本逐渐退出历史舞台（MySQL 5.7已于2020年10月起不再做大的功能更新，只有修修补补以及针对安全更新），更多MGR相关特性都只在MySQL 8.0上才有。

因此，如果线上还有基于MySQL 5.7版本的MGR环境的话，建议尽快升级、迁移到MySQL 8.0版本。进一步提醒，推荐MySQL 8.0.22及之后的版本，整体会更稳定可靠，也有些很不错的新功能（不只是MGR方面的）。

MGR具备以下几个特点：

MGR可以选择单主（Single-Primary）模式 file

如上图所示，一开始S1节点是Primary角色，提供读写服务。当它发生故障时，剩下的S2-S5节点会再投票选举出S2作为新的Primary角色提供读写服务，而S1节点再达到一定超时阈值后，就会被踢出。

亦可选择多主（Multi-Primary）模式（再次强烈建议选用单主模式） file

如上图所示，一开始S1-S5所有节点都是Primary角色，都可以提供读写服务，任何一个节点发生故障时，只需要把指向这个节点的流量切换下就行。

上述两种架构模式下，应用端通过MySQL Router连接后端在MGR服务，当后端节点发生切换时，Router会自动感知，对应用端来说几乎是透明的，影响很小，架构上也更灵活。

首先来个MGR的技术架构图： Group Replication Plugin Architecture

MGR是以Plugin方式嵌入MySQL，部署更灵活方便。

事务从Server层通过钩子（hook）进入MGR API接口层，再分发到各组件层，在组件层完成事务Capture/Apply/Recover，通过复制协议层（Replication Protocol Logics）传输事务，最后经由GCS协调事务在各节点的最终一致性。

MGR节点间由组通信系统（GCS）提供支持，它提供了故障检测机制、组成员角色管理，以及安全且有序的消息传递，这些机制可确保在各节点间一致地复制数据。这项技术的核心是Paxos算法的实现，在MySQL里称之为XCom，由它充当MGR的通信引擎。

对于要提交的事务，组中的多数派节点必须就全局事务序列中给定的事务顺序达成一致。各节点做出决定提交或中止事务的选择，但所有节点都要做出相同的决定。如果发生网络分区，导致节点间无法达成一致决定，则在网络恢复前，MGR无法工作。

MGR支持单主和多主两种模式，在单主模式下，各节点会自动选定主节点，只有该主节点能同时读写，而其他（从）节点只能只读。在多主模式下，所有节点都可以进行读写。

相对于MariaDB Galera Cluster（以及基于此技术的Percona XtraDB Cluster，下面为了书写方便，都统称为PXC），个人认为MGR具备以下几个优势：

PXC的消息广播机制是在节点间循环的，需要所有节点都确认消息，因此只要有一个节点故障，则会导致整个PXC都发生故障。而MGR则是多数派投票模式，个别少数派节点故障时，一般不影响整体的可用性。这也是PXC存在的最大问题。
PXC的节点间数据传输除了binlog，还有个gcache，这相当于是给MySQL又增加两个黑盒子。而MGR则都是基于原生binlog的，没有新增黑盒子，运行起来更可靠，需要排障时也更方便。
发生网络分区时，整个PXC集群都不可用。而MGR则至少还能提供只读服务。
PXC的流控机制影响更大，一旦触发流控，所有节点都受到影响。而MGR触发流控后，只会影响本地节点，不影响远程节点。当然了，MySQL的流控做的也比较粗糙，在GreatSQL中进一步完善和优化。
执行DDL期间，整个PXC集群都不可同时执行DML，也就是说不支持Online DDL。而MGR是支持的，这也是很大的优势。

相对于传统主从复制（Replication），我认为MGR的优势有以下几点：

主从复制非常容易产生复制延迟，尤其是当表中没有显式主键时。而在MGR里，要求表一定要有主键（或是可用作聚集索引的非空唯一索引），避免了这个问题。
半同步复制中，一旦slave因为锁或其他原因响应慢的话，也会导致master事务被阻塞。MGR是采用多数派确认机制，个别节点响应慢对Primary节点的影响没那么大（不要选用AFTER模式）。
主从复制没有类似MGR那样提供事务数据的一致性保证。MGR自带了事务数据一致性保障机制。

以上是我根据MySQL、MariaDB、Percona的资料整理得到的观点，不一定准确和全面，有不完善的地方还请留言指正。