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

1. 从主从复制到 MGR为什么我不再用半同步MySQL 的容灾方案经历过好几个阶段接触过传统主从复制的人应该深有体会主从切换靠脚本脚本靠写change master to一旦主库宕机从库提升为主库中间要处理一堆延迟日志、binlog 点位搞不好还会丢数据。到了半同步复制Semisynchronous Replication至少主库提交前会等一个从库 Ack理论上能保证不丢数据但半同步有个老毛病——它只能保证“有一个从库收到了”不保证这个从库的日志和主库完全一致。更麻烦的是半同步在切换时依然要靠外部组件或人工介入遇到多机房或者网络抖动很容易出现脑裂。MySQL Group ReplicationMGR就是来解决这些痛点的。它不是简单把复制改一改而是基于 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 ClusterPXC或 MySQL InnoDB ClusterPXC 用的是 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-node1192.168.10.11初始主节点mgr-node2192.168.10.12从节点mgr-node3192.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_id1 gtid_modeON enforce_gtid_consistencyON binlog_checksumNONE log_binbinlog binlog_formatROW transaction_write_set_extractionXXHASH64 loose-group_replication_group_nameaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa loose-group_replication_start_on_bootOFF loose-group_replication_local_address192.168.10.11:33061 loose-group_replication_group_seeds192.168.10.11:33061,192.168.10.12:33061,192.168.10.13:33061 loose-group_replication_bootstrap_groupOFF loose-group_replication_single_primary_modeON loose-group_replication_enforce_update_everywhere_checksOFF这里的server_id每台要不同group_name我直接用uuidgen命令生成一个保证全局唯一。group_replication_local_address是 MGR 节点之间内部通信用的地址和 MySQL 客户端的 3306 端口没有关系我习惯单独用一个端口 33061避免和应用连接混淆。group_replication_group_seeds有个常见误解它不是“启动时加入哪台”而是“组内有哪些种子成员可供连接”真正决定节点加入行为的是后面执行的START GROUP_REPLICATION指令。另外一个细节binlog_checksumNONE是 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_Repl2024; GRANT REPLICATION SLAVE, REPLICATION CLIENT, BACKUP_ADMIN ON *.* TO repl%;还有其他账号也需要创建比如监控账号但那是运维体系的事情这里不扩展。第一个节点引导启动 MGR 是最容易出错的地方。原理上第一个节点必须执行SET GLOBAL group_replication_bootstrap_groupON然后才能执行START GROUP_REPLICATION这相当于告诉组“我自己就是种子我要创建组”。如果不执行 bootstrap 直接 startMySQL 会提示无法与组建立连接。完整命令如下SET GLOBAL group_replication_bootstrap_groupON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_groupOFF;这里要特别注意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_id2 gtid_modeON enforce_gtid_consistencyON binlog_checksumNONE log_binbinlog binlog_formatROW transaction_write_set_extractionXXHASH64 loose-group_replication_group_nameaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa loose-group_replication_start_on_bootOFF loose-group_replication_local_address192.168.10.12:33061 loose-group_replication_group_seeds192.168.10.11:33061,192.168.10.12:33061,192.168.10.13:33061 loose-group_replication_bootstrap_groupOFF loose-group_replication_single_primary_modeON loose-group_replication_enforce_update_everywhere_checksOFF注意第二个节点的 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 repl192.168.10.11:3306 IDENTIFIED BY Mgr_Repl2024;执行完克隆会自动重启实例重启之后实例的配置和数据已经和主节点对齐。然后重新设置group_replication_local_address等参数克隆不会覆盖 my.cnf 里的 MGR 参数再执行CHANGE MASTER TO MASTER_USERrepl, MASTER_PASSWORDMgr_Repl2024 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_NAMEgroup_replication_applier\G我见过最多的问题就是新节点卡在RECOVERING状态排查顺序建议从简到繁防火墙是否放行了 33061 端口以及 MySQL 3306 端口复制账号密码是否输错权限是否齐全新节点的 GTID 集是否正确SHOW MASTER STATUS和组内主节点的SHOW MASTER STATUS对比新节点是否残留旧的 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_ROLEPRIMARY的节点如果发现当前节点不再是主就把 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_bootON或手动执行 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_formatROW但不会显式写transaction_write_set_extraction。这个参数如果不设置MGR 在计算 Write Set 时会告警甚至直接拒绝开启组复制。我见过一个案例节点上配置了 ROW 格式但没写transaction_write_set_extractionXXHASH64启动 MGR 后报错错误日志里提示缺少必要的插件参数。原因就是 MGR 在认证阶段必须使用 XXHASH64 哈希算法来计算事务 write set才能进行冲突检测和认证。另一个更深层的坑是如果历史 binlog 的格式不是 ROW那么新节点加入时需要回放这些 binlog 进行追平。回放过程中会因为事件格式不匹配导致 applier 线程持续报错最后集群无法收敛。所以如果你的数据是从 5.7 或者更早版本迁移来的不要直接开 MGR务必先做一轮逻辑备份恢复确保所有数据文件都是干净可回放的 8.0 格式然后再初始化组。这类问题在官方文档里都有说明但很多博客教程会直接跳过。我在这里写出来就是希望大家部署前多做一次检查不要像我当初那样因为一个参数把整套集群的初始化时间拖了一整天。