一、为什么需要 MGR
在传统 MySQL 高可用方案中，异步复制和半同步复制是主流选择。异步复制存在主库宕机后从库数据丢失的风险；半同步复制虽然通过 AFTER_SYNC 模式提升了数据安全性，但在超时退化为异步后仍然无法保证一致性。更重要的是，这两种方案都面临一个核心痛点：主库故障后的切换需要外部组件介入，例如 MHA、Orchestrator 或 Keepalived，切换逻辑复杂且容易出现脑裂。
MySQL 5.7.17 引入的组复制（MySQL Group Replication，简称 MGR）从根本上改变了这一局面。它基于 Paxos 协议的变体实现，将多个 MySQL 实例组成一个复制组，通过原子广播和多数派共识机制，保证事务在组内的一致性提交，并内置了自动故障检测与主节点选举能力。
二、MGR 的核心原理
2.1 基于 Paxos 的共识层
MGR 的底层依赖一个称为 XCom 的共识模块，它是 Paxos 协议的工程实现。组内每个节点都维护一份相同的数据副本，事务的提交需要经过组内多数派（N/2 + 1）的同意。这意味着在一个三节点组中，至少需要两个节点确认才能提交事务；在五节点组中，至少需要三个节点确认。
这种多数派机制带来了一个重要特性：只要多数派节点存活，集群就能正常提供服务。三节点组可以容忍一个节点故障，五节点组可以容忍两个节点故障。
2.2 事务的生命周期
一个写事务在 MGR 中的完整流程如下：
- 客户端发送事务：客户端连接到主节点（或任何可写节点），发起写事务。
- 执行并生成写集：事务在本地执行，但尚未提交。执行过程中产生的行变更被收集为 Write Set（写集），包含行数据、版本号等认证信息。
- 广播写集：主节点将 Write Set 通过 XCom 广播给组内所有节点。
- 认证阶段：每个节点收到 Write Set 后，进行冲突检测（Certification）。检测依据是行记录的版本号——如果两个并发事务修改了同一行，先达成共识的事务会获得更低的版本号，后到的事务将被判定为冲突并回滚。
- 多数派确认：如果多数派节点认证通过，事务进入提交阶段。
- 提交并应答：主节点收到多数派确认后，向客户端返回成功。所有节点最终都会应用该事务，保证数据一致。
2.3 多主模式与单主模式
MGR 支持两种运行模式：
- 单主模式（Single-Primary）：组内只有一个节点可写，其余节点为只读。主节点由组内选举产生，默认按
server_uuid排序选择。当主节点故障时，组内自动选举新主，无需外部干预。 - 多主模式（Multi-Primary）：所有节点均可读写。但多主模式下需要应用层保证不会对同一行并发写入，否则认证阶段会频繁冲突回滚。实际生产中单主模式更为常见。
2.4 故障检测与成员管理
每个节点定期向组内发送心跳。如果某节点在 group_replication_member_expel_timeout（默认 5 秒）内未响应，会被标记为可疑；超过该时间后，该节点被驱逐出组。被驱逐的节点需要重新加入组时，会经历分布式恢复（Distributed Recovery）过程，从组内某个在线节点拉取缺失的 binlog 事件并应用。
三、MGR 高可用架构设计
3.1 推荐部署拓扑
生产环境推荐至少三节点部署，且节点分布在不同的故障域（不同物理机、不同机架或不同可用区）。三节点是最小可用配置，可容忍单点故障。对可靠性要求更高的场景可采用五节点，容忍双点故障。
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Node 1 │────│ Node 2 │────│ Node 3 │
│ PRIMARY │ │ SECONDARY │ │ SECONDARY │
│ :3306 │ │ :3306 │ │ :3306 │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└───────────────────┴───────────────────┘
MySQL Router / ProxySQL
│
应用层
3.2 流量接入层
MGR 本身不提供 SQL 路由能力，需要配合 MySQL Router 或 ProxySQL 使用。MySQL Router 8.0 内置了对 MGR 的支持，可以自动感知主节点变化并将写流量路由到新主。ProxySQL 则通过健康检查脚本实现类似功能，配置更灵活。
3.3 关键参数配置
# 组复制基础配置
group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
group_replication_start_on_boot = OFF
group_replication_local_address = "192.168.1.1:33061"
group_replication_group_seeds = "192.168.1.1:33061,192.168.1.2:33061,192.168.1.3:33061"
group_replication_single_primary_mode = ON
group_replication_enforce_update_everywhere_checks = OFF
# 必须开启 GTID 和 binlog
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_checksum = NONE
log_slave_updates = ON
3.4 监控要点
运维 MGR 集群时，需要重点关注以下指标：
performance_schema.replication_group_members：查看组内成员状态（ONLINE、RECOVERING、ERROR 等）。performance_schema.replication_group_member_stats：查看事务认证队列、冲突统计、消息延迟等。- 复制延迟：通过
performance_schema.replication_group_member_stats中的COUNT_TRANSACTIONS_IN_QUEUE和COUNT_TRANSACTIONS_CHECKED评估。 - 网络延迟：MGR 对网络延迟敏感，跨机房部署时需确保 RTT 在可接受范围内（通常建议同城双活 RTT < 5ms）。
四、MGR 的局限与注意事项
尽管 MGR 提供了强大的高可用能力，但并非银弹，使用时需注意：
- 仅支持 InnoDB 引擎：MyISAM 等非事务引擎无法参与组复制。
- 每张表必须有主键：认证阶段依赖主键进行行冲突检测，无主键表会导致全表扫描认证，性能急剧下降。
- 网络要求高：MGR 的共识协议对网络延迟和丢包敏感，跨地域部署需谨慎评估。
- 大事务限制：
group_replication_transaction_size_limit默认 150MB，超大事务可能导致节点被驱逐。 - 不支持外键级联操作：在多主模式下，外键约束可能导致认证冲突。
- DDL 语句需特殊处理：在 MySQL 8.0.27 之前，DDL 在 MGR 中需要额外的协调机制；8.0.27 之后支持了原子 DDL，但仍有版本兼容性要求。
五、面试高频问题
Q1：MGR 如何保证数据不丢失？
MGR 通过多数派确认机制保证：事务必须在多数派节点认证通过后才返回客户端成功。即使主节点在返回后立即宕机，已提交的事务也至少存在于多数派节点中，新选举的主节点必然包含该事务。
Q2：MGR 与半同步复制的本质区别是什么？
半同步复制是主从之间的点对点确认，从库宕机或超时后会退化为异步；MGR 是组内多数派共识，只要多数派存活就能保证一致性，且内置自动选主和故障转移，不依赖外部组件。
Q3：MGR 中如何处理冲突？
MGR 采用乐观并发控制。事务在本地执行时不加全局锁，提交时通过 Write Set 的版本号进行认证。如果检测到冲突，后提交的事务会被回滚，客户端收到死锁或回滚错误，需要应用层重试。
Q4：MGR 节点被驱逐后如何重新加入？
被驱逐的节点需要先执行 STOP GROUP_REPLICATION，然后重新执行 START GROUP_REPLICATION。节点会进入 RECOVERING 状态，从组内在线节点拉取缺失的 binlog 并应用，完成后变为 ONLINE。
六、总结
MGR 是 MySQL 官方提供的高可用解决方案，通过 Paxos 共识协议实现了数据强一致、自动故障转移和内置成员管理。它适合对数据一致性要求高、希望减少外部依赖的场景。但在实际落地时，需要充分考虑网络条件、表结构设计、事务大小等因素，并配合 MySQL Router 或 ProxySQL 构建完整的流量接入层。理解 MGR 的认证机制和多数派原理，是掌握其运维和调优的关键。
未经允许不得转载：任鹏个人博客 » MySQL 组复制 MGR 原理与高可用架构实战
