MySQL MGR高可用集群实战：从Paxos原理到故障转移的完整部署指南

1. 从主从复制到 MGR：为什么我不再用半同步

MySQL 的容灾方案经历过好几个阶段，接触过传统主从复制的人应该深有体会：主从切换靠脚本，脚本靠写change master to，一旦主库宕机，从库提升为主库中间要处理一堆延迟日志、binlog 点位，搞不好还会丢数据。到了半同步复制（Semisynchronous Replication），至少主库提交前会等一个从库 Ack，理论上能保证不丢数据，但半同步有个老毛病——它只能保证“有一个从库收到了”，不保证这个从库的日志和主库完全一致。更麻烦的是，半同步在切换时依然要靠外部组件或人工介入，遇到多机房或者网络抖动，很容易出现脑裂。

MySQL Group Replication（MGR）就是来解决这些痛点的。它不是简单把复制改一改，而是基于 Paxos 协议的组通信系统，把多个节点组成一个真正意义上的“组”。组内所有节点通过共识机制保证数据强一致，每次事务提交都要经过组成员内部协商，多数派确认后才算成功。换句话说，MGR 不是“异步的补救”，而是从架构层面把分布式一致性问题交给了 Paxos 来解决。

我第一次在生产环境搭建 MGR 是三年前，那时候官方文档还很晦涩，网上能查到的完整案例少得可怜，踩了不少坑。后来陆陆续续帮朋友和同事搭过几套，逐渐把整个流程理清楚了。这篇博文不聊玄学，直接讲 MGR 从规划、安装、初始化到故障转移的完整实操路径，所有配置都给出我实际验证过的参数，并解释为什么这么配。

适合什么人来读？如果你正在维护 MySQL 实例，而且对“高可用”的要求是：主库挂了业务不中断、数据不丢失、切换不用人肉改配置，那么这篇内容非常契合你的需求。如果你是刚接触 MySQL 的开发者，也可以照做一遍，理解 MGR 的工作原理，以后再去看其他分布式数据库会轻松很多。

2. MGR 架构解析与部署前的三大关键思考

2.1 组复制的两个核心工作模式

MGR 提供两种模式：单主模式（Single-Primary）和多主模式（Multi-Primary）。我强烈建议，如果你不是对多写有极其强烈的业务需求，直接选单主模式。

单主模式下整个组只有一个节点能写，其他节点都只读，每次事务提交由主节点协调。虽然看起来“浪费”了其他节点的写能力，但极大简化了事务冲突检测的复杂性。多主模式虽然允许所有节点写，但代价是引入写冲突检测、死锁检测、事务回滚机制，节点间还需要额外通信协调认证阶段。我在测试环境里试过多主模式，两个节点同时写同一行数据时，报错率和重启回滚的频率明显高于预期，对业务来说感知非常直接——应用层不断收到死锁和回滚报错。

生产环境我推荐单主模式，多主模式适合对写冲突容忍度很高的内部系统，或者分片明确、每个节点只写自己那部分数据的场景。这个决策在部署前就要想清楚，因为切换模式虽然官方提供group_replication_switch_to_single_primary_mode之类的指令，但中间过程要停写、要处理缓冲的事务，生产环境折腾起来风险很大。

2.2 为什么选择 MGR 而不是传统主从或 PXC

传统主从复制的缺陷已经说了，那为什么不选 Percona XtraDB Cluster（PXC）或 MySQL InnoDB Cluster？PXC 用的是 Galera 复制技术，也是同步复制，但它要求所有节点串行执行事务，性能瓶颈非常明显。MGR 的组复制通过组通信协议把事务的传播、认证、应用三个阶段分开处理，尽量减少节点间的串行等待。

MGR 的另一个优势是它可以直接复用 MySQL 8.0 的现有体系，不需要额外的中间件。InnoDB Cluster 其实是在 MGR 之上封装了 MySQL Shell 的管理功能，真正干活还是 MGR。如果你需要一个自动化的运维界面，可以用 InnoDB Cluster，但我个人更喜欢直接操作 MGR，因为控制粒度更细，排查问题也更清晰。

2.3 部署前的关键思考：网络、存储与版本

MGR 对组通信时延很敏感，因为每个事务提交都需要组内多数节点确认。官方建议节点间的往返时延 RTT 最好小于 5ms，所以我部署时一般把三个节点放在同一机房同一个二层网络里。跨机房部署 MGR 不是不可以，但你必须清楚：网络抖动直接导致事务响应变慢，如果两个机房之间的专线质量不够稳，平时没事，一旦出现丢包或中断，组内节点会反复评估“节点是否存活”，频繁触发流控甚至排斥节点（expel）。

存储方面，SSD 是必须的，因为 MGR 的认证和日志应用都是高 IO 操作。版本上，我建议直接用 MySQL 8.0.17 以上版本，8.0.17 之后 group replication 的稳定性明显提升，很多早期日志啪啪报错的场景再也没有出现过。不要用 5.7 跑 MGR 生产环境，5.7 的 MGR 属于早期实验性功能，成熟度和 Bug 修复远不如 8.0。

注意：MGR 启用前必须开启 GTID，且不能关闭 binlog。这两个条件是硬性前提，MySQL 8.0 默认开启，但如果你是从 5.7 升级过来的老实例，迁移前务必确认这两个配置。

3. 环境规划与 MySQL 安装：从零到可用的完整链路

3.1 节点规划与 OS 初始化

以最常见的三节点集群为例，我一般选用 Rocky Linux 9 或 Ubuntu 22.04 LTS 作为操作系统。三节点的好处是故障容忍数为 1，也就是说任意挂掉一个节点，集群还能正常工作。如果你要容忍两个节点同时宕机，至少需要五个节点，但这需要额外评估成本和收益，大部分业务三节点足够。

假设我规划如下：

节点	IP 地址	角色
mgr-node1	192.168.10.11	初始主节点
mgr-node2	192.168.10.12	从节点
mgr-node3	192.168.10.13	从节点

角色分配这里要明确一点，MGR 的组内节点角色在运行时是动态变化的，没有固定的“主从”概念，这里写的“初始主节点”只是第一个加入组的节点，MGR 会自动在单主模式下选举主节点。我习惯把第一个初始化的节点作为主节点，其实你也可以随机选，但第一个节点对引导配置有特殊要求，后面我会专门讲。

OS 初始化时要注意几点：关闭防火墙或放行组通信端口，关闭 SELinux（或按需放行端口），设置好每个节点的主机名并写入 /etc/hosts。MGR 的成员身份是通过server_uuid识别的，和主机名没有强绑定关系，但主机名在 MySQL 错误日志和性能监控里可读性更强，我习惯用 node1、node2、node3 这样的命名。

3.2 MySQL 8.0 安装与基础参数配置

MySQL 8.0 的安装最稳妥的方式是使用官方 Yum 仓库或二进制 tarball。以 Rocky Linux 9 为例，先安装仓库：

# 安装 MySQL Yum 仓库 rpm -Uvh https://repo.mysql.com/mysql80-community-release-el9-1.rpm # 关闭默认的 mysql 模块 dnf -qy module disable mysql # 安装 MySQL 8.0 Community Server dnf -y install mysql-community-server

如果你是在内网环境，没有外网权限，那就下载完整 tarball 包，解压后初始化。二进制包安装不复杂，但依赖项比较多，我建议能用包管理器就用包管理器，省心很多。

安装完成后先不要急着启动，改配置文件。以下是我在 MGR 节点上验证过的核心配置段，每一条都值得关注：

[mysqld] server_id=1 gtid_mode=ON enforce_gtid_consistency=ON binlog_checksum=NONE log_bin=binlog binlog_format=ROW transaction_write_set_extraction=XXHASH64 loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=OFF loose-group_replication_local_address="192.168.10.11:33061" loose-group_replication_group_seeds="192.168.10.11:33061,192.168.10.12:33061,192.168.10.13:33061" loose-group_replication_bootstrap_group=OFF loose-group_replication_single_primary_mode=ON loose-group_replication_enforce_update_everywhere_checks=OFF

这里的server_id每台要不同，group_name我直接用uuidgen命令生成一个，保证全局唯一。group_replication_local_address是 MGR 节点之间内部通信用的地址，和 MySQL 客户端的 3306 端口没有关系，我习惯单独用一个端口 33061，避免和应用连接混淆。

group_replication_group_seeds有个常见误解，它不是“启动时加入哪台”，而是“组内有哪些种子成员可供连接”，真正决定节点加入行为的是后面执行的START GROUP_REPLICATION指令。

另外一个细节，binlog_checksum=NONE是 MGR 的默认建议配置，因为 MGR 的认证机制对 binlog 事件的 checksum 比较敏感，如果开启 checksum 可能导致部分版本在节点加入时出现异常。我在实际部署中确实遇过一次因为 checksum 设置导致加入失败的案例，后来统一改成 NONE 就没再犯。

注意：loose-前缀表示该参数即使没有被当前 MySQL 版本识别，也不会导致实例启动失败。MGR 相关参数用 loose- 是官方文档推荐的常见做法，目的是保持平滑升级。

3.3 初始化实例与第一个节点的引导

配置好之后，启动 MySQL 服务，拿到初始临时密码：

systemctl start mysqld grep 'temporary password' /var/log/mysqld.log

用临时密码登录，立即修改 root 密码，然后创建专门用于 MGR 复制的账号。MGR 要求复制账号必须有REPLICATION_SLAVE、REPLICATION_CLIENT、BACKUP_ADMIN权限，而且要启用SHA-256密码认证。MySQL 8.0 默认使用caching_sha2_password，直接建用户即可：

CREATE USER 'repl'@'%' IDENTIFIED BY 'Mgr_Repl@2024'; GRANT REPLICATION SLAVE, REPLICATION CLIENT, BACKUP_ADMIN ON *.* TO 'repl'@'%';

还有其他账号也需要创建，比如监控账号，但那是运维体系的事情，这里不扩展。

第一个节点引导启动 MGR 是最容易出错的地方。原理上，第一个节点必须执行SET GLOBAL group_replication_bootstrap_group=ON，然后才能执行START GROUP_REPLICATION，这相当于告诉组“我自己就是种子，我要创建组”。如果不执行 bootstrap 直接 start，MySQL 会提示无法与组建立连接。

完整命令如下：

SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group=OFF;

这里要特别注意：bootstrap 只能执行一次。如果节点重启后不小心再次 bootstrap，大概率会生成一个同名的组，把其他成员搞懵。我在测试环境犯过这个错，当时三个节点两两分裂成两个组，排查了半天才发现是重启后遗留的 bootstrap 配置没关。

验证第一个节点是否成功成为组内成员：

SELECT * FROM performance_schema.replication_group_members;

如果看到MEMBER_STATE为ONLINE，并且当前节点是PRIMARY，说明引导成功。

4. 添加第二个、第三个节点：一步步搭建真实集群

4.1 第二、第三节点的核心配置差异

第二个节点和第三个节点的整体流程与第一个节点几乎相同，唯一要注意的是每个节点的server_id必须不同，group_replication_local_address要改成各节点自己的 IP 和端口，group_replication_group_name和group_seeds要和第一个节点保持完全一致。

我习惯把配置模板打好，直接复制到各台机上再改 IP，效率最高。比如第二个节点：

[mysqld] server_id=2 gtid_mode=ON enforce_gtid_consistency=ON binlog_checksum=NONE log_bin=binlog binlog_format=ROW transaction_write_set_extraction=XXHASH64 loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=OFF loose-group_replication_local_address="192.168.10.12:33061" loose-group_replication_group_seeds="192.168.10.11:33061,192.168.10.12:33061,192.168.10.13:33061" loose-group_replication_bootstrap_group=OFF loose-group_replication_single_primary_mode=ON loose-group_replication_enforce_update_everywhere_checks=OFF

注意第二个节点的 bootstrap 参数是OFF，绝对不能开。

4.2 数据同步的两种方式：冷拷贝与克隆插件

加入 MGR 组要求新节点的数据和组内当前主节点的数据完全一致，因为 MGR 是强一致复制，GTID 集必须对齐才能通过认证。这里有两种方案：

第一种是传统的物理备份恢复：在主节点用xtrabackup或 MySQL 官方的clone插件做一次全量备份，然后恢复到目标节点。操作路径偏手工，但如果主节点数据量大、clone 插件受限，物理备份依然是可靠的基础方案。

第二种是我推荐的 MySQL 8.0 原生克隆（Clone Plugin），它比 xtrabackup 快得多，而且支持增量阶段。启用方式：

INSTALL PLUGIN clone SONAME 'mysql_clone.so';

在目标节点执行克隆之前，需要先配置好也可以直接在主节点上用CLONE INSTANCE FROM语法，但要注意的是，官方 clone 是直接在目标实例上执行，会把当前实例的数据清空再覆盖。所以在目标机上操作时，确保目标实例的数据目录是全新初始化或者可以被覆盖的。

个人实测下来，我要重点提醒：克隆前检查目标实例的server_uuid和 GTID 状态。如果目标实例之前启动过 MySQL，数据目录里残留的 auto.cnf 会导致克隆失败，提示The slave is not configured之类的报错。解决办法是把目标实例干净停掉，删除数据目录下的 auto.cnf 或者整目录重来。

以下是使用 clone 插件在第二个节点上拉取主节点数据的 SQL 示例，需要在目标机上执行：

CLONE INSTANCE FROM 'repl'@'192.168.10.11':3306 IDENTIFIED BY 'Mgr_Repl@2024';

执行完克隆会自动重启实例，重启之后实例的配置和数据已经和主节点对齐。然后重新设置group_replication_local_address等参数（克隆不会覆盖 my.cnf 里的 MGR 参数），再执行：

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='Mgr_Repl@2024' FOR CHANNEL 'group_replication_recovery'; START GROUP_REPLICATION;

CHANGE MASTER TO ... FOR CHANNEL这步不是可选项，而是 MGR 内部恢复通道的配置。组复制在加入组时，会通过这个专用通道去主节点拉取缺失的事务，如果通道没配置好，START GROUP_REPLICATION后成员会一直卡在RECOVERING状态。

4.3 验证集群状态与常见错误处理

三个节点全部执行完START GROUP_REPLICATION后，任选一个节点执行：

SELECT * FROM performance_schema.replication_group_members;

结果应该是三行ONLINE，单主模式下只有一个是PRIMARY。再检查复制通道状态：

SELECT * FROM performance_schema.replication_connection_status WHERE CHANNEL_NAME='group_replication_applier'\G

我见过最多的问题就是新节点卡在RECOVERING状态，排查顺序建议从简到繁：

1. 防火墙是否放行了 33061 端口以及 MySQL 3306 端口；
2. 复制账号密码是否输错，权限是否齐全；
3. 新节点的 GTID 集是否正确，SHOW MASTER STATUS和组内主节点的SHOW MASTER STATUS对比；
4. 新节点是否残留旧的 binlog 和 relaylog，如果有就清掉再重新加入。

这里有个隐形坑：新节点如果之前有过业务写入，那么它的 GTID 集可能大于组内的 GTID 集，MGR 会拒绝它加入，因为“落后”可以补，但“超前”的数据无法被组内其他节点接受。遇到这种情况，最干净的做法就是清空数据目录重新初始化，然后走 clone 流程。

4.4 为什么第二个节点要等第一个节点 ONLINE 再操作

很多人喜欢把三个节点一次性全部配置好，再同时执行 START，结果手忙脚乱。我的建议是一条线走到底：第一个节点引导成功后，先验证单节点状态，再依次加第二个、第三个。原因有两个：

第一，如果按照 ABC 三个节点同时 start，容易发生资源竞争和日志交错，排查问题时你会分不清是引导问题还是组间同步问题。一步一步来，每一步都可以通过replication_group_members单独验证。

第二，MGR 组成员之间需要交换大量元数据，如果第一节点还没有形成完整的组视图，后面的节点加入时可能遇到 view change 还没完成，导致加入超时。实测下来，顺序逐个加入的稳定度远高于并发加入。

5. 故障转移与日常维护：让集群真正可用

5.1 单主模式的故障自动转移

MGR 单主模式下，组内会自动监测主节点状态。如果主节点宕机或者被隔离，组内其他成员会展开重新选举，选出一个新的主节点。这个选举基于 Paxos 协议，不需要人工干预，这一点比传统主从切换强太多。

假设主节点 192.168.10.11 宕机，执行以下查询：

SELECT MEMBER_HOST, MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members;

你会看到剩余两个节点状态变为 ONLINE，其中一个角色自动变成 PRIMARY。应用层如果配置了 VIP（虚拟 IP）或者使用 MySQL Router，流量会自动切换到新主节点。如果你没有引入任何代理层，就需要自己写一个探测脚本来获取当前主节点，然后更新应用的重连配置。

我在生产环境用的是 VIP 方式，基于 keepalived 做虚拟 IP 绑定到当前主节点。但这里有一个细节：keepalived 需要主节点角色变化时自动切换。一般脚本是查询performance_schema.replication_group_members中MEMBER_ROLE='PRIMARY'的节点，如果发现当前节点不再是主，就把 VIP 摘掉，其他节点争夺 VIP。整个过程实测下来 5 到 10 秒内可以完成，相比传统主从的分钟级恢复，体验提升明显。

5.2 手动切换主节点与计划内维护

虽然 MGR 支持自动故障转移，但有些维护场景我们需要主动把主节点切换到另一台，比如对主节点进行内核补丁升级、磁盘扩容。这时可以通过 MySQL 官方提供的函数执行平滑切换：

SELECT group_replication_set_as_primary('aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee');

参数是目标节点的MEMBER_ID，可以在replication_group_members表里查到。执行这个函数后，组内会先确保目标节点追平所有事务，然后做角色切换，不会中止组通信。整个过程比较平滑，业务能感知到的只有主节点切换瞬间的写入停顿，通常几百毫秒。

不过要注意，切换前最好确保业务持续写入量不大，否则切换期间可能出现事务排队和认证延迟。我一般会选择业务低峰期做切换演练，验证一遍流程再上生产。

5.3 多主模式的冲突检测与业务适配

虽然单主模式是生产首选，但如果你确实用到了多主模式，就必须深入理解 MGR 冲突检测机制。MGR 在所有节点上对每个写事务提取 write set，然后广播到组内做认证。如果两个事务在认证阶段发现存在交集（写同一行），后到的事务会被标记为冲突并回滚。

这意味着应用层的错误处理必须考虑这种“写提交后被回滚”的情况。通常做法是捕获死锁和回滚异常后重试事务。我测试过一个两节点的多主集群，两个应用分别连接两个节点，并发写同一行数据，结果一个事务成功一个被回滚，应用没有做重试，直接抛错。这提醒我们，选择多主不只是配置问题，还要在代码层面做好事务重试与幂等设计。

5.4 日常监控与元数据管理

MGR 日常运维依赖三个关键视图：performance_schema.replication_group_members（成员状态）、replication_group_member_stats（事务统计）、replication_connection_status（通道状态）。我建议将这些视图接入 Prometheus 或者 Zabbix 作为监控数据源，用 exporter 定期抓取。

重点监控指标包括：MEMBER_STATE是否为 ONLINE、COUNT_TRANSACTIONS_CHECKED增长是否正常、COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE是否有堆积、以及RECEIVED_TRANSACTION_SET与APPLIED_TRANSACTION_SET是否持续接近。

我遇到过一种情况，某个节点因为磁盘空间不足导致 applier 线程执行缓慢，事务队列越积越长，但成员状态一直是 ONLINE。如果只监控 ONLINE 状态，这个隐患会被埋很久。必须把事务延迟也纳入核心告警项。

注意：MGR 节点磁盘必须留足 binlog 和 relaylog 空间。因为组成员之间通过 binlog 和应用线程同步，一旦磁盘写满，节点会被组视图标记为不可用，甚至触发排除机制。

6. 常见问题速查与避坑清单

下面这些问题是读者私信和我自己踩坑频率最高的，整理成一张速查表，建议收藏备用：

故障现象	常见原因	解决方案
START GROUP_REPLICATION 后一直 RECOVERING	复制通道密码错误 / 数据没有对齐 / 33061 端口不通	检查replication_connection_status错误信息，确认账号权限，确认防火墙放行
加入时提示 GTID 领先组内事务	目标节点残留了额外的 binlog	清空数据目录重新初始化，或先执行RESET MASTER清除 GTID 执行历史
成员状态 ONLINE 但无法写入	当前节点是 SECONDARY，单主模式不允许从节点写	查询当前主节点信息，将连接切到 PRIMARY；若需要切换主，执行group_replication_set_as_primary
主节点切换后应用仍然连旧主	应用层没有感知角色变化	引入 VIP 或者 MySQL Router，利用探测脚本动态获取 PRIMARY 节点
组内节点频繁被 expel	网络抖动导致组通信超时，或系统时钟偏差过大	确保 NTP 时间同步正常，检查交换机丢包率，优化组通信超时参数
节点重启后无法自动加入组	group_replication_start_on_boot未开启	在 my.cnf 中设置loose-group_replication_start_on_boot=ON，或手动执行 START 指令
事务冲突频繁回滚	多主模式下并发写相同行	尽量避免多主写同一资源，应用层增加重试机制，或切换回单主模式
克隆报错 'The slave is not configured'	目标实例有旧 server_uuid 残留	删除数据目录 auto.cnf，重新初始化再执行 CLONE

避坑经验还有几条：

第一，MGR 组通信依赖稳定的系统时间。我用chronyc同步所有节点时间，偏差超过 100ms 会出现通信异常。第二，不要把group_replication_bootstrap_group参数设置在 my.cnf 里，哪怕设为 OFF 也有风险。这个参数只能作为 Session 级别的临时开关使用。第三，节点扩容时不要把新节点一次性配置成 AUTO_INCREMENT 步长，后面数据增长后步长不回源，会导致主键跳跃很大，影响业务预期。

7. 我踩过的最深的一个坑：binlog 导致的数据不一致

最后这段是额外的经验分享，也借此把 MGR 的一个重要特性讲清楚。

MGR 要求 binlog 格式是 ROW，这是一切的基础。但如果你从老环境迁移数据，之前实例是 STATEMENT 或者 MIXED 格式，那么初始化节点时如果不小心把 binlog_format 在 my.cnf 里留空，而 MySQL 8.0 默认是 ROW，按理说问题不大。真正的问题是：很多 DBA 在配置 MGR 时会在 my.cnf 里写binlog_format=ROW，但不会显式写transaction_write_set_extraction。

这个参数如果不设置，MGR 在计算 Write Set 时会告警，甚至直接拒绝开启组复制。我见过一个案例，节点上配置了 ROW 格式，但没写transaction_write_set_extraction=XXHASH64，启动 MGR 后报错，错误日志里提示缺少必要的插件参数。原因就是 MGR 在认证阶段必须使用 XXHASH64 哈希算法来计算事务 write set，才能进行冲突检测和认证。

另一个更深层的坑是：如果历史 binlog 的格式不是 ROW，那么新节点加入时需要回放这些 binlog 进行追平。回放过程中会因为事件格式不匹配，导致 applier 线程持续报错，最后集群无法收敛。所以如果你的数据是从 5.7 或者更早版本迁移来的，不要直接开 MGR，务必先做一轮逻辑备份恢复，确保所有数据文件都是干净可回放的 8.0 格式，然后再初始化组。

这类问题在官方文档里都有说明，但很多博客教程会直接跳过。我在这里写出来，就是希望大家部署前多做一次检查，不要像我当初那样，因为一个参数把整套集群的初始化时间拖了一整天。