MySQL MGR组复制集群搭建实战：从原理到故障切换

“MGR”这个缩写第一次接触是在我负责的一套 MySQL 主从复制集群第三次因为主库宕机而深夜爬起来手动切 VIP 之后。当时我就下定决心必须换一套不需要人肉切换、不会在故障时脑裂的高可用方案。MySQL 官方自 5.7.17 就引入了 Group Replication组复制简称 MGR到了 8.0.x 已经相当成熟。这篇文章把我从零搭建三节点 MGR 集群的完整过程写出来包括配置拆解、启动顺序、故障演练和一堆只有亲手踩过才会注意的细节。适合已经熟悉 MySQL 复制基础、正在评估高可用方案的 DBA 或后端工程师。1. 为什么我把高可用方案从传统主从复制切换成 MGR1.1 传统主从复制让我吃过的苦传统主从复制异步复制、半同步复制本身并不复杂一个主库写入从库把 binlog 拉过去回放。但用来支撑一个对可用性有要求的业务系统问题会一个一个浮出来。故障转移是最头疼的。主库宕机之后从库虽然还活着但它不会主动把自己提升为新的写入点。你需要手动执行STOP SLAVE; RESET SLAVE ALL;再跑到业务所在的机器上去切换数据库连接地址或者移动 VIP虚拟 IP。如果操作慢了几分钟监控群里可能已经炸锅。更糟糕的是如果之前用的是异步复制主库在宕机前有一批事务还没来得及同步到从库站在新主库上看业务数据是“回退”的。业务方会问你刚才写进去的那几笔订单为什么不见了。后来切换到半同步复制事务提交前需要等一个从库的 ACK数据丢失窗口缩小了但架构上的隐患依然存在半同步复制的从库数量通常是 1一旦那个从库出现问题复制会静默降级回异步模式。主库此时仍然对外服务但数据保护已经失效且没有日志明确告诉你“保护级别已降低”。等到真正宕机你才发现数据少了一截。集群脑裂也是传统方案的经典事故。两套脚本同时认为自己是主库或者 VIP 漂移到了新的主库之后旧主库又重新启动两边都在接收写入最后要用很长的时间去手工比对和补偿数据。我经历过一次从那以后对“脚本切换 VIP”这套方案就彻底失去信心。1.2 MGR 解决的四个核心问题MGR 能做的事情本质上是把“一个主、多个从”的星型复制模型改成了“所有节点互相协商”的组模型。核心变化有四点第一自动选主。组里的主节点故障后剩余节点会通过内部投票决定一个新的 PRIMARY整个过程由组件自己完成不需要外部脚本干预。第二多数派确认。MGR 的事务提交基于类 Paxos 的组通信协议事务在写入主节点之后需要获得组内多数成员的确认才会最终提交。这意味着即使某个节点突然崩溃已提交事务的数据也存在于其他成员中。第三成员管理自动化。节点上线、下线、网络分区、节点恢复都会触发组视图重新配置。新节点加入时可以选择通过二进制日志进行增量恢复落后太多则可以用克隆插件全量同步。第四单主模式下的严格读写分离。在单主模式下组内只有一个节点可以接受写请求其他节点自动进入只读状态。从库即使收到SET GLOBAL read_onlyOFF的指令也会被组复制内部机制压制不会出现“不小心把写请求发到从库”这种低级的双写事故。1.3 选单主还是多主先回答三个问题MGR 支持两种模式单主模式single-primary和多主模式multi-primary。单主模式是绝大多数人的选择。它只有一个节点接收写流量其他节点作为热备份和只读扩展业务推广的风险最低。多主模式下所有节点都能写数据冲突检测的压力会落到数据库层对事务隔离、表结构设计、写入路由的要求都非常苛刻。我建议在决定使用多主模式之前先回答三个问题核心业务表是不是每条都有主键MGR 多主模式的冲突检测依赖主键没有主键的表在并发写入时会产生大量死锁和同步终止。同一行数据会不会在短时间内被不同节点同时修改例如用户余额、库存数量这类热点行多主模式下非常容易触发事务冲突。业务代码能不能接受冲突被回滚后由客户端重试多主模式下写入冲突会返回主键重复或死锁错误这需要业务层有重试机制。如果其中一个问题无法给出肯定答复就用单主模式。实际上单主模式已经能解决 90% 的高可用需求多主带来的并发写入收益远小于它引入的复杂度。这篇文章后面的配置和演练我都按单主模式展开多主模式的参数差异会在后面单独说明。2. 组复制的运作机制把 Paxos 简化到配置层面能看懂2.1 组、视图与成员状态不看懂 MGR 内部的几个核心概念配置文件就会变成“照着抄但不知道哪行会坑你”的玄学。MGR 中所有节点组成一个“复制组”组有一个唯一标识即配置项group_replication_group_name通常是一个 UUID 格式的字符串。这个标识会在组成员之间传播某个节点的配置与其不一致时该节点会直接拒绝加入。组内的成员状态可以从performance_schema.replication_group_members表里实时看到ONLINE节点正常已经参与组内事务同步。RECOVERING节点正在尝试从其他成员获取缺失的数据。OFFLINE节点未启动组复制。ERROR节点组复制运行出错。UNREACHABLE节点无法通过内部通信端口联系到其他成员。每次有成员加入、退出、失联组都会发生一次“视图改变”。视图改变后所有活跃成员重新协商当前组里的完整成员列表并刷新角色。你可以在错误日志里看到New view of group这类信息这是排查集群状态变化的重要线索。2.2 事务的提交与多数派确认在单主模式下写事务的执行过程可以简化为应用连接 PRIMARY 节点发起事务。事务在 PRIMARY 本地执行并写 binlog。提交时PRIMARY 通过组通信模块把事务广播给其他成员。每个成员收到事务后写入 relay log并由 applier 线程回放到存储引擎。当组内多数派节点确认收到并应用该事务后PRIMARY 才向客户端返回提交成功。这个确认机制和传统半同步复制完全不同。半同步复制只需要一个从库 ACK而 MGR 要求的是“多数派”确认。三节点集群中至少需要两个节点确认事务才算提交。也就是说主节点即使自己认为事务已经执行完只要没能让多数派接受它也不会把事务最终生效。这带来一个非常重要的实际结果在 MGR 中即使主节点突然被kill -9杀掉已向客户端返回成功的事务也一定存在于其他节点上。你不需要像传统异步复制那样做数据补齐新主库天然拥有全部已提交数据。这也是我把这套方案定为主要高可用选型的原因。2.3 故障检测与新主选举MGR 节点之间通过内部通信端口默认 33061 附近互相发送心跳消息。当一个节点在超时时间内没有响应其他节点会把它标记为 UNREACHABLE然后重新发起视图配置把该节点从活跃成员列表中排除。在单主模式下如果失联的节点恰好是 PRIMARY剩余节点会触发新主选举。选举结果不是随机的它倾向于选择组成员状态最健康、数据最完整、且权重配置最高的节点。默认权重相同的情况下会选择一个排序规则决定的节点作为新的 PRIMARY。由于事务提交需要多数派确认选举新主的过程没有传统可选方案里那种“旧主可能还有数据没同步完”的尴尬。旧主重新恢复并加入组后会以 SECONDARY 身份加入自动追平在它停机期间产生的事务数据在多数派机制下不会分叉。3. 环境规划与基础部署三台机器怎么摆3.1 版本选型、系统与硬件底线MGR 是 MySQL 官方功能5.7.17 起可用但 5.7 版本里的 MGR 属于早期实现某些边界行为不如 8.0 成熟。如果现在还在考虑新集群的搭建建议直接用 MySQL 8.0.x 的较新小版本比如 8.0.36 或更新版本。这一方面是因为参数和工具的兼容性更好另一方面是克隆插件CLONE等功能在 8.0 里已经非常稳定节点追平数据比传统备份恢复简单太多。操作系统层面我用的 Rocky Linux 9.x如果你习惯 Ubuntu 22.04 或 Debian 12 也没问题MGR 对系统没有特殊要求只要包管理器能正常装 MySQL 即可。硬件方面MGR 的组通信对网络延迟敏感建议各节点在同一机房或至少在同一专有网络内节点之间 RTT 控制在 5ms 以内。内存至少 4GB生产环境建议 8GB 起步磁盘优先 SSD因为组复制额外带来的 binlog 写入量并不小。三台机器的命名和 IP 规划通常是角色主机名内网 IP成员 1mgr-node1192.0.2.101成员 2mgr-node2192.0.2.102成员 3mgr-node3192.0.2.103我刻意避开了真实环境的网段你可以把 192.0.2.x 整体替换成自己的内网地址。注意节点之间的组通信流量不建议走公网安全性和稳定性都不够。3.2 IP、端口与通信网段的规划MySQL 实例本身监听 3306 端口用于客户端连接。组内通信需要额外分配一个端口也就是group_replication_local_address指向的端口通常习惯用 33061。这里有个容易被忽视的坑从 MySQL 8.0.22 左右开始组通信的底层协议除了固定端口还会在附近动态占用少量端口用于内部消息。也就是说你只在防火墙里打开 33061 是不够的最好放通 33061 到 33100 的 TCP 范围。另外group_replication_group_seeds里写的是所有成员的host:port列表这里的 host 如果是主机名必须保证各节点能互相解析如果 DNS 不稳定建议统一写 IP并在配置中关闭skip-name-resolve或确保 allowlist 覆盖所有 IP。3.3 部署 MySQL 并检查前置条件三台机器分别安装 MySQL 8.0 社区版。使用系统默认包管理工具在 Rocky Linux 上添加官方仓库后执行sudo dnf install mysql-community-server -y安装完成后不要急着启动先确认时间同步sudo systemctl enable --now chronyd chronyc tracking组内节点的时钟不需要严格一致性但大幅度的时钟偏差会影响事务时间戳判断有条件还是建议对时。初始化并启动 MySQLsudo mysqld --initialize --usermysql sudo systemctl enable --now mysqld刚装好的 MySQL 会给 root 生成一个临时密码记在错误日志里sudo grep temporary password /var/log/mysqld.log用临时密码登录后第一步是修改 root 密码。之后在正式配置 MGR 之前先检查几个基础设置用下面的 SQL 确认SHOW VARIABLES LIKE server_id; SHOW VARIABLES LIKE gtid_mode; SHOW VARIABLES LIKE binlog_format;正常情况下刚初始化的实例gtid_modeOFF需要我们在配置文件中统一改掉。千万不要直接在线执行SET GLOBAL gtid_modeON宁可改完配置文件后重启避免出现部分在线修改导致的复制中断。4. my.cnf 核心参数逐项拆解每个值为什么这么写4.1 复制基础设施参数MGR 的硬门槛MGR 对复制相关的底层配置有强制要求缺一个启动组复制就会直接报错。下面是节点 1 的完整参数模板节点 2、节点 3 只需要替换server_id、group_replication_local_address等标识性内容。[mysqld] # 节点唯一标识三台机器必须各不相同 server_id 101 # ---- GTID 强制要求 ---- gtid_mode ON enforce_gtid_consistency ON # ---- binlog 强制要求 ---- log_bin mysql-bin binlog_format ROW binlog_checksum NONE log_slave_updates ON # ---- relay log 与复制元数据 ---- relay_log relay-log relay_log_recovery ON master_info_repository TABLE relay_log_info_repository TABLE # ---- 组复制参数 ---- plugin_load_add group_replication.so group_replication_group_name a7c1b0e0-1111-2222-3333-444455556666 group_replication_start_on_boot OFF group_replication_local_address 192.0.2.101:33061 group_replication_group_seeds 192.0.2.101:33061,192.0.2.102:33061,192.0.2.103:33061 group_replication_single_primary_mode ON group_replication_enforce_update_everywhere_checks OFF # ---- 字符集建议 ---- character_set_server utf8mb4 collation_server utf8mb4_0900_ai_ci这些参数里gtid_mode和enforce_gtid_consistency是强制项。组复制后面的数据同步完全依赖 GTID如果这两项不打开启动组复制时会直接报错并拒绝执行。binlog_formatROW也是硬性要求。MGR 内部要解析 binlog 事件进行冲突检测和恢复行格式能保证字段级别的确定性。binlog_checksumNONE是从 5.7 时代继承下来的经验早期版本中如果启用 CRC32 校验某些复制事件的传输会出现兼容性问题。8.0 版本里保持组内各节点一致即可我统一设置成 NONE图省心。log_slave_updatesON经常被忽略。MGR 中每个节点既承担着本节点的写入又要通过 applier 线程回放其他节点的写入。如果不开这个参数被回放的事务不会记录到本节点自己的 binlog后续节点同步时就拿不到完整的事务链。一个组内节点掉线后想重新加入靠的就是这些 binlog 增量所以这个参数必须开启。4.2 group_replication 参数与组通信端口group_replication_group_name是一个 UUID 格式的字符串它定义了这个组的唯一标识。可以提前在任意一个节点执行SELECT UUID()生成一个然后用引号包住写进所有节点的配置。三个节点必须保持一致否则节点无法加入组。group_replication_start_on_boot指的是 MySQL 实例启动时是否自动拉起组复制。我在这里设置为 OFF是为了在搭建和演练阶段保持可控每一轮启动 MySQL 后我可以手动选择什么时候START GROUP_REPLICATION。生产环境如果希望实例重启后自动回组可以设置为 ON但前提是确认节点数据已经追平不会在启动瞬间产生冲突。group_replication_local_address是当前节点进行组内通信的地址和端口。这里用的不是客户端连接的那个 3306而是专门的组通信端口 33061两个端口在同一台机器上互不冲突。这三台机器的 local_address 各不相同分别指向自己的内网 IP。group_replication_group_seeds列出所有成员的组通信地址用于新节点加入组的初始联系。它不需要和允许列表完全一致构成了组成员互相发现的种子信息。还需要单独说明一个不在模板里的参数group_replication_bootstrap_group。它是一个动态变量不是写在配置文件里的常驻项。作用是指示节点作为空组发起者初始化创建一个全新的复制组。整组初始化时只能有一个节点把它设置为 ON用完必须立即关闭。如果多个节点同时开启并启动组复制就会出现在同一个组名下的多组不同视图数据会彻底错乱。4.3 多主模式需要改动的配置差异如果你的业务最终决定用多主模式只需要把配置文件中的这两项改掉group_replication_single_primary_mode OFF group_replication_enforce_update_everywhere_checks ONgroup_replication_enforce_update_everywhere_checks让系统在多个节点同时修改同一行数据时执行严格的冲突检测违反隔离性的事务会被直接回滚。这是必要的代价多主模式下如果不做这项检查两个节点同时修改同一行数据最终结果可能是静默互相覆盖而不是抛出错误问题会比死锁更隐蔽。多主模式下每个节点都可以写入这会给业务带来额外负担。应用代码必须把所有核心表的修改操作都收敛到主键维度避免跨节点执行无主键表的写入。而且热点行的并发写入会被回滚客户端没有重试逻辑就会不断报错。我在生产环境里几乎没有见过真正适合多主模式的业务至少在我接触过的系统里单主模式加读写分离已经足够。5. 从空实例到三节点集群初始化操作全流程5.1 初始化第一个节点bootstrap 的正确姿势切换到三台机器中扮演节点 1 的服务器先用 root 登录 MySQL创建 MGR 用于数据恢复的专用账号CREATE USER mgr_user% IDENTIFIED BY MgrUser#2024Test; GRANT REPLICATION SLAVE, REPLICATION APPLIER, BACKUP_ADMIN, GROUP_REPLICATION_STREAM ON *.* TO mgr_user%; FLUSH PRIVILEGES;这里的GROUP_REPLICATION_STREAM权限在新版本中用于流式复制恢复如果你使用的版本不支持可以适当裁剪但REPLICATION SLAVE和BACKUP_ADMIN必须保留否则新节点无法从现有成员拉取数据。然后为这个节点配置恢复通道注意这里的通道名固定为group_replication_recovery大小写敏感CHANGE REPLICATION SOURCE TO SOURCE_USER mgr_user, SOURCE_PASSWORD MgrUser#2024Test FOR CHANNEL group_replication_recovery;如果用的 MySQL 版本较旧可能只认CHANGE MASTER TO语法8.0.23 之后已经兼容新写法建议直接使用新写法。接下来是初始化组的关键步骤SET GLOBAL group_replication_bootstrap_group ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group OFF;注意顺序先开启 bootstrap 标志再启动组复制启动完成立即关闭标志。这个标志一旦打开节点就会认为自己所在组是空组拥有初始化整个组的权限。如果忘记关闭下次 MySQL 重启后又手动启动组复制它会再次尝试初始化一个全新的组和现有组的成员列表互相覆盖后果很严重。启动后第一件事是确认节点状态SELECT * FROM performance_schema.replication_group_members\G正常情况下节点 1 的状态是 ONLINE角色是 PRIMARYCHANNEL_NAME: group_replication_applier MEMBER_ID: ... MEMBER_HOST: mgr-node1 MEMBER_ROLE: PRIMARY MEMBER_STATE: ONLINE5.2 第二、第三个节点加入RECOVERING 的真相第二、第三个节点先完成同样的基础配置替换server_id、修改group_replication_local_address为各自的 IP创建一样的mgr_user然后配置恢复通道。这些准备工作完成后直接在节点 2 上执行START GROUP_REPLICATION;注意加入节点时绝对不要设置group_replication_bootstrap_groupON。这个场景下节点 2 是“加入一个已经存在的组”而不是“初始化一个组”。执行之后节点 2 的成员状态通常会经历一个短暂的分阶段RECOVERING 持续几秒钟到几分钟然后变成 ONLINE。RECOVERING 期间节点会从种子节点那里拉取缺失的 binlog 并回放。如果 binlog 量很大或者网络带宽不足这个状态会持续较久。如果你等了很久仍然停留在 RECOVERING最常见的原因是恢复账号没在目标节点上创建成功或者防火墙拦截了 33061 端口的流量。遇到这种情况不要反复重启组复制先看错误日志sudo tail -n 200 /var/log/mysqld.log日志里通常会有明确的认证失败或连接超时信息。修正问题后执行STOP GROUP_REPLICATION; START GROUP_REPLICATION;不需要重启 MySQL 进程。第三节点用同样的方式加入。全部加入后再次从任意节点查看SELECT MEMBER_HOST, MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members;理想结果是一行 PRIMARY、两行 SECONDARY且状态全为 ONLINE。这里提到的演示环境账号和密码仅用于示例生产环境请换成强度足够的独立密码并限制账号来源网段。5.3 验证集群状态的正确视角集群搭建完成后日常最常用的检查命令是-- 查看成员拓扑与角色 SELECT * FROM performance_schema.replication_group_members\G -- 查看主节点是谁 SHOW STATUS LIKE group_replication_primary_member; -- 查看每个成员的队列积压 SELECT MEMBER_ID, COUNT_TRANSACTIONS_IN_QUEUE, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE FROM performance_schema.replication_group_member_stats;COUNT_TRANSACTIONS_IN_QUEUE如果长期上涨说明某个从节点的应用速度跟不上主库写入速度要重点关注磁盘 IO 或第二条日志的回放状态。单主模式下SECONDARY 节点上的read_only是被 MGR 强制打开的即使你在这些节点手动执行SET GLOBAL read_onlyOFF也不会生效。这一点可以当作一个快速验证尝试在 SECONDARY 节点写一张临时表预期会收到只读错误。如果收到错误说明单主读写约束生效正常。6. 故障切换实测让主节点“意外死亡”一次6.1 模拟宕机后的 30 秒视图变化集群搭建完成下一步不是直接上线而是做一次故障切换演练。我的做法是在节点 1PRIMARY上直接模拟硬件掉电sudo kill -9 $(pgrep -x mysqld)这一步很激进不会走正常的 shutdown 流程也没有机会让 MySQL 主动通知组内其他成员“我要下线”。这是最接近真实宕机的场景。几秒后在节点 2 上执行SELECT MEMBER_HOST, MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members;你会看到节点 1 的状态变成 UNREACHABLE。这种状态不是立刻被移除的组复制内部有一个超时和故障探测窗口通常是几秒到十几秒。过了这个窗口节点 1 会被从活跃视图里剔除剩余的节点 2、节点 3 重新构成一个新的有效视图。6.2 新主是怎么被选出来的视图重新配置完成后节点 2 或节点 3 中的某一个会被提升为 PRIMARY。在默认权重的单主模式下选举逻辑会选择存活节点中最合适的那一个。可以通过如下命令确认SHOW STATUS LIKE group_replication_primary_member;你会发现返回的是节点 2 或节点 3 的MEMBER_ID。此时新 PRIMARY 自动打开读写能力并且因为所有已提交事务都已经在多数派节点上有副本新主库的数据量和一致性是有保证的。整个切换过程中只要业务连接的是网关而不是单台 MySQL后端应用基本感受不到中断。但如果只是简单地把应用直连到原来的主库 IP此时应用会连不上数据库因为节点 1 已经宕机。这也是为什么集群一定要接一层对外访问入口我在后面第 7 节重点讲。6.3 重启旧主、回切和检查清单演练完宕机再把节点 1 正常启动并加入集群sudo systemctl start mysqld以 root 登录后执行START GROUP_REPLICATION;节点 1 会以 RECOVERING 状态进入组自动从当前 PRIMARY 上拉取它在宕机期间错过的所有事务完成后状态变为 ONLINE角色是 SECONDARY。不需要手工设置gtid_purged也不需要重新创建账号MGR 的复制恢复通道会在 join 过程中自动接管。整个恢复过程中组内的事务同步不会中断。节点 1 追平后回到 ONLINE 状态三节点集群恢复完整。故障切换后的检查清单我现在基本稳定成了这几步确认新 PRIMARY 状态为 ONLINE所有节点无 UNREACHABLE。查看错误日志确认视图切换过程没有其他复制线程报错。对比所有节点的COUNT_TRANSACTIONS_IN_QUEUE是否趋近于 0。在业务低峰期用应用账号向新 PRIMARY 写入一条测试数据确认写入路径正常。确认 ProxySQL 或应用连接池已经自动感知到新 PRIMARY而不是仍然指向旧主。7. 从集群到对外服务ProxySQL 接入与常见问题手册7.1 用 ProxySQL 把读写流量接到 MGRMGR 本身只解决了“MySQL 内部的高可用”它没有提供一个客户端可以自动感知主节点切换的入口。因此业务侧的数据库驱动不能直连三台 MySQL而是应当通过数据库中间件统一接入。我用的方案是 ProxySQL。ProxySQL 装在一台独立的服务器上对外暴露标准的 MySQL 协议端口 6033管理端口是 6032。它通过监控账号持续探测 MGR 的replication_group_members状态当 PRIMARY 发生变化时会自动把写流量切换到新的主节点。这样主库宕机的瞬间应用连接池不会收到连不上的错误切换过程对业务基本透明。基础配置大概分四步第一步在 MySQL 端提供一个监控账号CREATE USER monitor% IDENTIFIED BY Monitor#2024Test; GRANT SELECT ON sys.* TO monitor%;第二步登录 ProxySQL 管理端口mysql -uadmin -padmin -h127.0.0.1 -P6032第三步注册后端节点。生产环境建议把写流量和读流量分到两个 hostgroup这里用一个简化配置示意INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight) VALUES (0, 192.0.2.101, 3306, 1), (1, 192.0.2.102, 3306, 1), (1, 192.0.2.103, 3306, 1);第四步配置监控规则和路由规则。ProxySQL 从 1.4.4 版本开始支持 MySQL 复制组监控它会自动把 MGR 的主节点归入写组 0把从节点归入读组 1INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (0, 1); INSERT INTO mysql_users (username, password, default_hostgroup) VALUES (app_user, AppPass2024, 0); INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, ^SELECT , 1, 1);最后执行LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;让配置生效并持久化。完成之后业务统一通过 ProxySQL 的 6033 端口访问 MySQL本文不深入展开每一个 ProxySQL 细节分支但上面的配置足够支撑一套单主 MGR 集群的正常读写路由。7.2 我遇到过的问题与排查路径搭建过程和后面的日常维护里我先后遇到过几类比较有代表性的问题写下来供你排查时参考。第一类节点启动组复制直接报 ERROR 3092。这个错误码对应的是server_id重复。排查方法很简单确认三台机器的server_id互不相同并且不是默认值 0。第二类报 ERROR 3093 或提示配置不满足要求。这通常意味着某一项强制参数没有打开比如gtid_mode还是 OFF或者binlog_format不是 ROW。把所有前置参数过一遍特别是要在 MySQL 8.0 里重启前把表结构引擎都处理好。第三类新节点一直 RECOVERING错误日志里提示认证失败。绝大多数情况是恢复账号只在一台机器上创建了而新节点在拉数据时访问的是另一个成员。解决办法是确保mgr_user在三台机器上都已经创建密码一致且权限足够。第四类节点在启动组复制后立刻变成 UNREACHABLE然后又恢复。这种通常发生在种子列表填错了、防火墙没放行组通信端口或者种子节点和 allowlist 不匹配。检查group_replication_group_seeds中的 host 字段是否为其他节点可解析的主机名或 IP再确认 33061 端口在属于组内成员的机器之间双向可达。第五类长时间运行后某个成员复制积压持续增长。先查看它的磁盘 IO 和系统负载再用replication_group_member_stats表确认是网络接收慢还是 applier 回放慢。如果是 applier 慢大概率是主库上的大事务太多或者表结构缺少主键导致回放效率低。关于脑裂防护我也多提一句MGR 对网络分区有自己的处理逻辑。如果某个节点和其他成员之间的网络断开它在一段时间后会自行退出组并拒绝新写入而不是原地“假装”自己还是主节点继续接收流量。这种“宁可降级也不盲写”的安全策略看起来会让系统短暂不可用但比双写脑裂带来的数据事故安全得多。最后再分享一个我自己的使用习惯。MGR 集群上线后我每天都会固定执行一次健康检查不只盯着成员状态还会看各节点的COUNT_TRANSACTIONS_IN_QUEUE和 binlog 磁盘占用。组复制的积压是逐渐发生的监控告警最好提早到队列积压超过阈值时触发而不是等节点已经变成 ERROR 再处理。备份策略上也建议保留传统的全量备份加 binlog 备份虽然 MGR 保证了多数派节点有副本但人为误操作、逻辑删除这类事故复制机制帮不了你备份才是最后一道防线。多花半小时把备份和监控补上远比出问题后再花一晚上抢救更划算。