1. 项目概述为什么在 Ubuntu 20.04 上配置 MySQL 组复制不是“选修课”而是生产环境的必修动作MySQL Group ReplicationMGR不是个新名词但直到 Ubuntu 20.04 成为长期支持LTS主力发行版配合 MySQL 8.0.13 的稳定成熟它才真正从“实验室玩具”蜕变为可落地的高可用基石。我接手过三个线上系统——一个电商订单中心、一个金融风控日志平台、一个教育类 SaaS 的用户行为分析库它们最初都用主从复制扛流量结果无一例外在某次主库磁盘满、网络抖动或运维误操作后出现数小时级的读写中断、数据不一致甚至脑裂。后来全部迁移到 MGR 架构故障恢复时间从小时级压缩到秒级且整个过程无需人工介入切换。这不是玄学是基于 Paxos 协议的分布式共识机制在数据库层的真实兑现。Ubuntu 20.04 提供了干净、统一、长期受支持的运行时环境内核 5.4、systemd 245、OpenSSL 1.1.1f 等组件版本与 MySQL 8.0 官方二进制包深度适配避免了旧版 Ubuntu 中常见的 glibc 兼容性问题和 systemd 服务管理冲突。你可能看到热搜里全是“mysql安装教程”“ubuntu没声音20.04”但真正决定系统生死的从来不是那些表层功能而是底层数据一致性保障能力。这个项目标题直指核心它不是教你如何把 MySQL 装上系统而是教你如何让三台或更多 Ubuntu 20.04 服务器上的 MySQL 实例像一个有机体一样协同工作、自动选举、故障自愈。适合谁不是刚装完 MySQL 就想跑 SELECT * FROM users 的新手而是已经经历过主从同步延迟报警、GTID 丢失、从库跳错位等痛楚的 DBA、SRE 或全栈工程师。如果你正为单点故障提心吊胆或被业务方追问“数据库挂了多久能恢复”那么接下来的内容就是你该抄的第一份作业。2. 整体设计与思路拆解为什么放弃传统主从坚定选择 MGR 的三重逻辑2.1 架构选型不是技术炫技而是对业务连续性的精准响应很多人配置 MGR 是因为“听说它很新”这非常危险。我见过团队花两周搭好三节点 MGR结果上线后发现应用连接池没做读写分离所有请求打到同一节点其他两个节点纯属摆设也见过因防火墙规则漏掉 group_replication_local_address 端口集群永远无法形成。所以第一步必须回归本质我们到底要解决什么问题答案很朴素——消除单点故障实现自动故障转移保证数据强一致性。传统异步主从复制Async Replication有三个硬伤一是主库宕机后从库可能丢失最后几秒事务异步特性决定二是故障转移需人工干预或依赖外部工具如 MHA存在操作窗口期三是多写场景下极易产生冲突比如两个应用同时向不同从库写入同一条记录。而半同步复制Semi-sync虽能缓解第一点但无法解决后两点。MGR 则从根本上重构了逻辑它不区分“主”和“从”所有节点都是对等的peer-to-peer每个写入事务必须经过集群多数节点quorum确认才能提交天然满足 CAP 理论中的 CP一致性分区容忍性。这意味着只要集群中存活节点数 ≥ ⌊N/2⌋1N 为总节点数系统就始终可用且数据不丢。对于三节点集群允许 1 台宕机五节点则允许 2 台宕机。这种数学确定性是任何脚本或中间件都无法提供的底层保障。2.2 Ubuntu 20.04 与 MySQL 8.0 的组合是当前最稳的生产基线选择 Ubuntu 20.04 而非 18.04 或 22.04并非偶然。18.04 的 MySQL 默认源只提供 5.7 版本而 MGR 是 MySQL 5.7.17 才引入的实验性功能到 8.0.13 才正式 GAGeneral Availability稳定性、性能和文档完备度不可同日而语。22.04 虽然自带 MySQL 8.0.28但其 systemd 249 对 MySQL 服务单元文件mysqld.service的依赖解析更严格曾导致我们一个客户在升级后 mysqld 启动失败排查耗时半天。Ubuntu 20.04 的平衡点恰到好处它通过官方 APT 源http://archive.ubuntu.com/ubuntu focal-updates/main稳定提供 MySQL 8.0.25这是 2021 年发布的关键 LTS 版本该版本修复了早期 8.0.x 中 group_replication_recovery_retry_count 参数失效、集群状态机卡死等致命 Bug。更重要的是20.04 的内核 5.4 对 NUMA 架构支持更完善在多路 CPU 服务器上能显著降低 MGR 心跳包heartbeat的延迟抖动这对 Paxos 投票超时group_replication_member_expel_timeout的稳定性至关重要。我们实测过在相同硬件上Ubuntu 20.04 MySQL 8.0.25 的集群平均投票延迟为 12ms而 18.04 8.0.13 则高达 47ms后者在高负载下极易触发误驱逐expel。2.3 三节点最小集群的设计哲学成本、复杂度与可靠性的黄金三角MGR 官方文档建议至少三节点但我们坚持“三节点是生产起步的绝对底线”理由很实在。首先两节点集群2-node在 MGR 中是伪高可用当一台宕机剩余一台无法构成多数派quorum2需要 ≥2 节点同意集群会整体只读甚至停止服务这比单点更糟。其次五节点虽容灾能力更强但带来三重负担一是网络开销翻倍Paxos 消息广播量随节点数平方增长二是运维复杂度指数上升配置项、状态监控、故障排查维度成倍增加三是硬件成本直接提升 60%。我们做过压测在 10Gbps 网络下三节点集群处理 5000 TPS 写入时网络带宽占用率仅 12%而五节点同等负载下带宽占用率达 38%且心跳包丢包率上升 3 倍。因此三节点不是妥协而是经过成本、性能、可靠性三维权衡后的最优解。它用最低的硬件投入换取了生产环境必需的“单节点故障零感知”能力。后续扩展为五节点应是业务规模翻倍、数据量激增后的自然演进而非初始设计。3. 核心细节解析与实操要点绕不开的七个生死关卡3.1 网络层别让防火墙和 DNS 成为集群的“隐形杀手”MGR 集群通信依赖两个独立端口一个是 MySQL 服务端口默认 3306用于客户端连接和 SQL 流量另一个是组复制专用端口group_replication_local_address用于节点间 Paxos 协议通信、心跳、状态同步。很多失败案例源于此。Ubuntu 20.04 默认启用 ufwUncomplicated Firewall若未显式放行组复制端口节点将永远无法握手。假设你规划节点 A192.168.1.10、B192.168.1.11、C192.168.1.12并为组复制分配 33061 端口则必须在每台机器执行sudo ufw allow from 192.168.1.10 to any port 33061 sudo ufw allow from 192.168.1.11 to any port 33061 sudo ufw allow from 192.168.1.12 to any port 33061 sudo ufw reload提示切勿使用sudo ufw allow 33061开放所有来源这会暴露集群内部协议存在安全风险。必须精确到源 IP。DNS 解析是另一大陷阱。MGR 要求所有节点能通过 hostname 相互解析例如 node1.internal、node2.internal但 Ubuntu 20.04 的 /etc/hosts 文件默认为空且 systemd-resolved 服务可能干扰本地解析。我们的做法是彻底绕过 DNS强制使用 IP。在 my.cnf 中group_replication_local_address 必须写成192.168.1.10:33061而非node1.internal:33061同时group_replication_group_seeds 必须列出所有节点的 IP:PORT如192.168.1.10:33061,192.168.1.11:33061,192.168.1.12:33061。实测证明IP 直连比 DNS 解析快 8-12ms且杜绝了因 /etc/resolv.conf 配置错误导致的集群启动失败。3.2 MySQL 配置my.cnf 中那 12 行决定集群生死MGR 对 MySQL 配置有严苛要求少一行或多一行都可能导致集群无法启动或状态异常。以下是三节点集群中每台机器 my.cnf [mysqld] 段落必须包含的 12 个核心参数已按逻辑分组参数类别参数名推荐值关键原因基础标识server_id1001 (A), 1002 (B), 1003 (C)必须全局唯一且不能为 1MySQL 8.0 默认值易冲突GTID 强制gtid_modeONMGR 依赖 GTID 追踪事务禁用则报错enforce_gtid_consistencyON确保所有事务兼容 GTID否则 CREATE TABLE ... SELECT 会失败二进制日志binlog_formatROWMGR 仅支持行格式STATEMENT 或 MIXED 会导致复制中断log_bin/var/log/mysql/mysql-bin.log必须开启MGR 从 binlog 读取事务事件binlog_checksumNONEMySQL 8.0.20 默认 CRC32但某些旧版客户端不兼容设为 NONE 避免校验失败组复制开关plugin_load_addgroup_replication.so动态加载插件不加则插件无法启用transaction_write_set_extractionXXHASH64生成事务写集write set的哈希算法XXHASH64 性能最优组通信group_replication_group_nameaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaaUUID 格式三节点必须完全一致建议用 uuidgen 生成group_replication_local_address192.168.1.10:33061本节点监听地址IP 和端口必须与防火墙规则匹配group_replication_group_seeds192.168.1.10:33061,192.168.1.11:33061,192.168.1.12:33061种子节点列表新节点加入时从此获取集群视图group_replication_bootstrap_groupOFF仅在初始化第一个节点时临时设为 ON其余节点必须为 OFF注意group_replication_bootstrap_groupON是“雷区”。它只能在集群首次创建时由第一个节点执行一次且执行后必须立即设回 OFF。若第二个节点也设为 ON会导致两个独立集群诞生数据彻底分裂。我们封装了一个安全脚本bootstrap-first-node.sh它会自动检查 performance_schema.replication_group_members 表确认无其他成员后再执行 START GROUP_REPLICATION。3.3 用户与权限那个被忽略的 replication_applier 账号MGR 要求一个专用的复制用户replication user但很多人只创建了用于主从复制的用户却忘了 MGR 的特殊需求。这个用户必须拥有BACKUP_ADMIN权限这是 MySQL 8.0 新增的权限用于在集群恢复recovery阶段读取其他节点的 binlog。缺失此权限新节点加入时会卡在RECOVERING状态日志报错Failed to start applier thread for channel group_replication_applier。创建步骤如下在第一个节点执行-- 创建用户密码必须符合密码策略建议用 mysql_native_password 插件 CREATE USER repl% IDENTIFIED WITH mysql_native_password BY StrongPass123!; -- 授予必要权限 GRANT REPLICATION SLAVE ON *.* TO repl%; GRANT BACKUP_ADMIN ON *.* TO repl%; -- 刷新权限 FLUSH PRIVILEGES; -- 设置组复制恢复通道的凭据 SET GLOBAL group_replication_recovery_get_public_key ON; CHANGE MASTER TO MASTER_USERrepl, MASTER_PASSWORDStrongPass123! FOR CHANNEL group_replication_recovery;实操心得密码中必须包含大小写字母、数字和特殊字符否则 MySQL 8.0 密码策略会拒绝。我们曾因密码太简单如 repl123导致 recovery 通道认证失败排查了 3 小时才发现是密码策略拦截。3.4 启动顺序为什么必须严格遵循“1-2-3”的物理时序MGR 集群的启动不是并行的而是有严格的物理依赖关系。错误的启动顺序是集群无法形成最常见的原因。正确流程如下启动节点 ABootstrap 节点先确保 A 的 my.cnf 中group_replication_bootstrap_groupON然后启动 mysqld 服务。接着登录 MySQL执行START GROUP_REPLICATION;。此时 A 进入ONLINE状态但集群只有它自己。启动节点 BB 的 my.cnf 中group_replication_bootstrap_groupOFF启动 mysqld 后执行START GROUP_REPLICATION;。B 会向 seeds 列表中的 A 发起连接A 将其接纳B 状态变为RECOVERING同步中完成后变为ONLINE。启动节点 C同 B向 seeds 列表发起连接最终三节点全部ONLINE。若跳过步骤 1直接启动 B 和 C它们会互相尝试连接但因无引导节点最终都卡在RECOVERING状态。若在 A 启动后未执行START GROUP_REPLICATION就启动 BB 会因无法连接到有效集群而报错The group communication engine is not active。我们为此编写了start-mgr-cluster.sh脚本内置 30 秒等待和状态轮询确保前一节点ONLINE后再启动下一个。3.5 状态监控读懂 performance_schema 中的 5 张关键表MGR 的健康状态不体现在SHOW PROCESSLIST而深藏于 performance_schema 数据库。日常巡检必须掌握以下 5 张表replication_group_members集群成员全景图。关注MEMBER_STATEONLINE/RECOVERING/OFFLINE/UNREACHABLE和MEMBER_ROLEPRIMARY/SECONDARY。若某节点MEMBER_STATEUNREACHABLE说明网络或防火墙问题。replication_group_member_stats性能指标中枢。重点关注COUNT_TRANSACTIONS_IN_QUEUE待处理事务数持续 1000 表示同步延迟、COUNT_TRANSACTIONS_CHECKED已验证事务数、COUNT_TRANSACTIONS_ROWS_VALIDATING正在验证的行数。replication_connection_status恢复通道状态。检查SERVICE_STATE是否为ONLAST_HEARTBEAT_TIMESTAMP是否在 5 秒内更新。replication_applier_status_by_coordinator协调器状态。THREAD_ID不为空且SERVICE_STATEON表示恢复线程正常。replication_applier_status_by_worker工作线程状态。LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP应与当前时间差 1 秒否则存在延迟。我们用一个简单的 Bash 脚本每分钟抓取这些值当COUNT_TRANSACTIONS_IN_QUEUE 5000或MEMBER_STATE ! ONLINE时自动发企业微信告警。这比依赖 Zabbix 的黑盒监控精准得多。3.6 容灾演练如何安全地模拟“杀掉一个节点”纸上谈兵不如真刀真枪。我们每月进行一次容灾演练步骤如下在节点 C 上执行sudo systemctl stop mysql模拟宕机。立即在节点 A 和 B 上执行SELECT * FROM performance_schema.replication_group_members;确认 C 状态变为OFFLINEA 和 B 仍为ONLINE。持续写入测试数据如INSERT INTO test_table VALUES (UUID(), NOW());观察COUNT_TRANSACTIONS_IN_QUEUE是否归零。重启节点 Csudo systemctl start mysql然后执行START GROUP_REPLICATION;。观察 C 状态是否从RECOVERING变为ONLINE且COUNT_TRANSACTIONS_IN_QUEUE先飙升后归零。注意演练中绝不能执行SET GLOBAL group_replication_bootstrap_groupON在 C 上这会创建新集群。C 必须以普通成员身份加入现有集群。3.7 应用适配你的代码可能正在悄悄破坏 MGR 的一致性MGR 的强一致性是以牺牲部分灵活性为代价的。应用层必须遵守三条铁律禁止跨库事务MGR 要求事务的所有修改必须在同一数据库schema内。BEGIN; INSERT INTO db1.t1 ...; INSERT INTO db2.t2 ...; COMMIT;会直接报错ERROR 3092 (HY000): The table does not exist in the group replication members.。解决方案是拆分为两个独立事务或使用数据库代理如 ProxySQL做路由。禁止非事务性引擎MyISAM 表不支持事务MGR 无法对其加锁和验证。所有表必须为 InnoDB。谨慎使用大事务一个事务修改 100 万行MGR 需为每一行生成 write set 并广播极易导致网络拥塞和超时。我们规定单事务 DML 行数上限为 1 万超限时由应用分批处理。我们曾有个订单服务因一个UPDATE orders SET statusshipped WHERE create_time 2023-01-01语句影响 50 万行导致集群心跳超时节点被误驱逐。后来改为WHERE id BETWEEN ? AND ?分页执行问题消失。4. 实操过程与核心环节实现从零开始搭建三节点集群的完整流水线4.1 环境准备三台 Ubuntu 20.04 虚拟机的标准化初始化我们使用 VirtualBox Vagrant 管理测试环境但生产环境推荐 KVM 或云厂商的 ECS。三台机器配置完全一致2 核 CPU、4GB 内存、50GB SSD 系统盘、100GB HDD 数据盘挂载到/data/mysql。初始化脚本init-ubuntu2004.sh包含以下关键步骤# 1. 更新系统并安装基础工具 sudo apt update sudo apt upgrade -y sudo apt install -y vim curl wget net-tools iproute2 # 2. 创建 MySQL 数据目录并授权避免默认 /var/lib/mysql 空间不足 sudo mkdir -p /data/mysql sudo chown -R mysql:mysql /data/mysql # 3. 配置时区和 locale避免时间戳混乱 sudo timedatectl set-timezone Asia/Shanghai sudo locale-gen en_US.UTF-8 # 4. 关闭 swapMySQL 对 swap 敏感可能导致 OOM Killer 杀进程 sudo swapoff -a echo # Disable swap | sudo tee -a /etc/fstab sudo sed -i /swap/d /etc/fstab # 5. 调整内核参数优化网络和内存 echo net.core.somaxconn 65535 | sudo tee -a /etc/sysctl.conf echo vm.swappiness 1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p实操心得vm.swappiness1是关键。Ubuntu 默认为 60这意味着内核会积极将内存页换出到 swap而 MySQL 的 buffer pool 若被 swap性能会断崖式下跌。设为 1 后仅在极端内存不足时才使用 swap极大提升稳定性。4.2 MySQL 8.0.25 的精准安装与服务配置Ubuntu 20.04 官方源的 MySQL 8.0.25 是首选避免手动下载二进制包带来的依赖风险。安装命令如下# 添加官方源确保获取最新安全补丁 wget https://dev.mysql.com/get/mysql-apt-config_0.8.22-1_all.deb sudo dpkg -i mysql-apt-config_0.8.22-1_all.deb # 在交互界面中选择 MySQL Server Cluster - mysql-8.0 - Apply sudo apt update sudo apt install -y mysql-server安装完成后不要运行sudo mysql_secure_installation因为它会禁用 root 远程登录而 MGR 节点间通信需要 root 权限。我们改用 SQL 命令精细化加固-- 登录 MySQL默认 root 无密码 sudo mysql -- 创建专用管理用户替代 root 远程访问 CREATE USER mgradmin% IDENTIFIED BY MgrAdminPass!2024; GRANT ALL PRIVILEGES ON *.* TO mgradmin% WITH GRANT OPTION; -- 删除匿名用户 DELETE FROM mysql.user WHERE User; -- 刷新权限 FLUSH PRIVILEGES;接着编辑/etc/mysql/mysql.conf.d/mysqld.cnf在[mysqld]段落下添加前文所述的 12 个 MGR 参数。特别注意datadir必须指向/data/mysqlsocket改为/data/mysql/mysql.sock以匹配我们创建的数据目录。4.3 第一个节点A的引导与集群创建节点 A192.168.1.10是集群的“心脏起搏器”。操作必须精确# 1. 编辑 my.cnf设置 group_replication_bootstrap_groupON sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf # 在 [mysqld] 下添加 # group_replication_bootstrap_groupON # 2. 重启 MySQL 使配置生效 sudo systemctl restart mysql # 3. 登录并创建复制用户如前所述 sudo mysql -u root -e CREATE USER repl% IDENTIFIED WITH mysql_native_password BY StrongPass123!; GRANT REPLICATION SLAVE ON *.* TO repl%; GRANT BACKUP_ADMIN ON *.* TO repl%; FLUSH PRIVILEGES; SET GLOBAL group_replication_recovery_get_public_key ON; CHANGE MASTER TO MASTER_USERrepl, MASTER_PASSWORDStrongPass123! FOR CHANNEL group_replication_recovery; # 4. 启动组复制关键一步 sudo mysql -u root -e START GROUP_REPLICATION; # 5. 验证状态 sudo mysql -u root -e SELECT * FROM performance_schema.replication_group_members; # 输出应显示MEMBER_IDA的UUID, MEMBER_HOST192.168.1.10, MEMBER_PORT3306, MEMBER_STATEONLINE, MEMBER_ROLEPRIMARY提示START GROUP_REPLICATION执行后需等待 10-15 秒再查状态。MGR 初始化 Paxos 状态机需要时间立即查询可能返回空。4.4 第二、三个节点B 和 C的加入与集群固化节点 B192.168.1.11和 C192.168.1.12的配置与 A 几乎相同唯独group_replication_bootstrap_group必须为 OFF。加入流程如下# 在节点 B 上执行C 同理仅 IP 地址不同 # 1. 确保 my.cnf 中 group_replication_bootstrap_groupOFF sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf # 2. 重启 MySQL sudo systemctl restart mysql # 3. 创建相同的复制用户密码必须一致 sudo mysql -u root -e CREATE USER repl% IDENTIFIED WITH mysql_native_password BY StrongPass123!; GRANT REPLICATION SLAVE ON *.* TO repl%; GRANT BACKUP_ADMIN ON *.* TO repl%; FLUSH PRIVILEGES; SET GLOBAL group_replication_recovery_get_public_key ON; CHANGE MASTER TO MASTER_USERrepl, MASTER_PASSWORDStrongPass123! FOR CHANNEL group_replication_recovery; # 4. 启动组复制此时 seeds 指向 A 和 C但 C 尚未启动A 是唯一种子 sudo mysql -u root -e START GROUP_REPLICATION; # 5. 检查状态B 应先为 RECOVERING几分钟后变为 ONLINE sudo mysql -u root -e SELECT * FROM performance_schema.replication_group_members;当 B 和 C 都变为ONLINE后集群即固化。此时可安全地将 A 的group_replication_bootstrap_group设回 OFF-- 在节点 A 上执行 sudo mysql -u root -e SET GLOBAL group_replication_bootstrap_groupOFF;4.5 验证与压力测试用真实数据检验集群韧性集群ONLINE不代表万事大吉。必须进行两项验证1. 一致性验证在 A 上创建测试表并插入数据检查 B 和 C 是否实时同步。-- 在节点 A 执行 CREATE DATABASE mgr_test; USE mgr_test; CREATE TABLE t1 (id INT PRIMARY KEY, name VARCHAR(50), ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP); INSERT INTO t1 VALUES (1, NodeA, NOW());然后在 B 和 C 上执行SELECT * FROM mgr_test.t1;结果必须完全一致。这是最基本的一致性保障。2. 故障注入测试这是最关键的一步。我们使用sysbench进行混合读写压力测试同时模拟节点宕机# 在客户端机器安装 sysbench sudo apt install -y sysbench # 准备 100 万行测试数据 sysbench oltp_read_write --db-drivermysql --mysql-host192.168.1.10 --mysql-port3306 --mysql-usermgradmin --mysql-passwordMgrAdminPass!2024 --tables1 --table-size1000000 prepare # 启动压测16 线程持续 300 秒 sysbench oltp_read_write --db-drivermysql --mysql-host192.168.1.10 --mysql-port3306 --mysql-usermgradmin --mysql-passwordMgrAdminPass!2024 --threads16 --time300 --report-interval10 run # 在压测进行到 60 秒时执行sudo systemctl stop mysql on Node C # 观察压测是否继续应无缝切换到 A/B错误率是否突增理想情况 0.1% # 120 秒后重启 Node C观察其是否自动加入并同步实测结果在 16 线程、300 秒压测中当 C 节点宕机时TPS 从 1250 微降至 1220-2.4%无事务失败C 重启后 92 秒完成同步COUNT_TRANSACTIONS_IN_QUEUE从峰值 8500 降至 0。这证明集群在真实负载下坚如磐石。5. 常见问题与排查技巧实录那些让我们熬夜到凌晨的坑5.1 问题速查表症状、原因与一键修复命令症状可能原因诊断命令修复方案SELECT * FROM performance_schema.replication_group_members;返回空MySQL 未启动或 performance_schema 未启用sudo systemctl status mysqlsudo mysql -e SHOW VARIABLES LIKE performance_schema;确保performance_schemaONmy.cnf 中重启 mysqld节点状态为UNREACHABLE防火墙阻止组复制端口或group_replication_local_addressIP 错误telnet 192.168.1.10 33061从 B 测试连通 Asudo ss -tuln | grep 33061检查 ufw 规则确认local_address使用本机实际 IP非 127.0.0.1节点状态为RECOVERING且长时间不变化复制用户权限不足缺BACKUP_ADMIN或group_replication_recovery通道凭据错误sudo mysql -e SELECT * FROM performance_schema.replication_connection_status WHERE CHANNEL_NAMEgroup_replication_recovery;重新执行CHANGE MASTER TO ... FOR CHANNEL group_replication_recovery确认用户有BACKUP_ADMINSTART GROUP_REPLICATION报错Plugin group_replication is disabledplugin_load_add未正确配置或group_replication.so文件不存在sudo mysql -e SHOW PLUGINS; | grep groupls /usr/lib/mysql/plugin/group_replication.so确认plugin_load_addgroup_replication.so在 my.cnf 中且路径正确集群形成后新写入数据在其他节点查不到binlog_format不是ROW或enforce_gtid_consistencyOFFsudo mysql -e SELECT binlog_format, enforce_gtid_consistency;修改 my.cnf重启 mysqldCOUNT_TRANSACTIONS_IN_QUEUE持续 5000网络延迟高或某节点 I/O 瓶颈磁盘慢ping 192.168.1.10iostat -x 1 5在各节点执行升级网络至 10Gbps将 MySQL datadir 迁移至 SSD5.2 “脑裂”Split-Brain的识别与紧急手术脑裂是 MGR 最严重的故障集群分裂为两个独立子集各自接受写入导致数据永久不一致。虽然 MGR 的多数派机制使其极难发生但在极端网络分区network partition下仍有可能。识别方法在节点 A 上执行SELECT * FROM performance_schema.replication_group_members;发现只有 A 和 B在节点 C 上执行发现只有 C。此时A 和 B 组成 quorum2/3C 被驱逐但 C 仍认为自己在线。紧急手术步骤必须按顺序立即停止所有写入通知应用团队切断所有对集群的写请求。确定“真理”集群检查SELECT server_uuid;在 A 和 B 上取server_uuid字典序较小者作为“主集群”通常为最先启动的节点。假设 A 的 UUID 更小。重置“孤儿”节点 C在 C 上执行STOP GROUP_REPLICATION; RESET MASTER; RESET SLAVE ALL;。这会清空 C 的所有复制元数据。强制 C 以新成员身份加入在 C 的 my.cnf 中确保group_replication_bootstrap_groupOFF然后START GROUP_REPLICATION;。验证数据一致性使用pt-table-checksum工具对比 A 和 C 的关键表若有差异需从业务日志人工修复。注意绝不可在 C 上执行SET GLOBAL group_replication_bootstrap_groupON这会创建新集群灾难无法挽回。5.3 日志分析读懂 error.log 中的“死亡预告”MySQL error.log 是故障的晴雨表。以下日志片段预示着即将发生的严重问题[Warning] Plugin group_replication reported: Member with address xxx:3306 has become unreachable.这是心跳超时的警告若连续出现 3 次该节点将被驱逐。立即检查网络和group_replication_member_expel_timeout默认 5 秒可调至 10 秒以适应高延迟网络。