MGR节点离线或网络分区需按怀疑→投票→驱逐→视图更新流程处理，不可盲目重启；状态为SUSPECT时大概率是抖动，应查日志是否含“Member was expelled”再决定操作。

节点离线或网络分区不是“重启就能好”的问题，MGR 的状态机不会自动原谅一个失联节点——它必须经过怀疑、投票、驱逐、视图更新这一整套仲裁流程。盲目 START GROUP_REPLICATION 只会卡在 RECOVERING 或直接报错 ERROR，甚至引发脑裂。

怎么判断是真离线还是网络抖动？

别急着操作，先看日志和状态。MGR 对“失联”的判定有明确时序，不是 ping 不通就踢人：

• 连续 5 秒没收到心跳 → 被标记为 Suspect（可疑）
• 之后等待 group_replication_member_expel_timeout 秒（MySQL 8.0.21+ 默认 5，旧版默认 0）→ 超时才触发驱逐提案
• 提案需多数派投票通过（比如 3 节点需 ≥2 票）→ 才真正从 MEMBERSHIP VIEW 中移除

所以如果你看到某个节点状态是 UNREACHABLE 或 SUSPECT，但还没变 ERROR，大概率只是抖动。查错误日志里有没有 Member was expelled 这行；没有，就等一等，别手动干预。

节点状态卡在 RECOVERING 怎么办？

RECOVERING 表示该节点正在尝试从其他成员拉取缺失数据，但常因以下原因卡住：

• GTID 差距太大，源节点的 binlog 已被 purge，无法靠增量同步追平
• 克隆（Clone）未启用，且 group_replication_recovery_complete_at 配置不匹配
• 用于恢复的复制通道 group_replication_recovery 凭据失效（比如密码改了但没同步到所有节点）
• 目标节点的 gtid_executed 和集群当前视图冲突，比如你手动执行过 RESET MASTER

验证方式：在该节点执行 SELECT * FROM performance_schema.replication_connection_status WHERE CHANNEL_NAME = 'group_replication_recovery'\G，重点看 LAST_IO_ERROR 和 LAST_IO_ERROR_TIMESTAMP。常见报错如 Access denied for user 'repl'@'x.x.x.x' 就得立刻检查账号权限和密码是否一致。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

多数派丢失后如何安全重建集群？

三节点集群中两个同时掉线，剩下一个节点状态会变成 ERROR 或长期 OFFLINE，因为它无法构成多数派，连心跳都无法发起仲裁。这时不能只在单节点上 START GROUP_REPLICATION —— 它会拒绝启动，报错类似 Group has no quorum。

• 必须由最后一个存活节点以引导模式启动：SET GLOBAL group_replication_bootstrap_group = ON;，再 START GROUP_REPLICATION
• 启动成功后立即关掉引导：SET GLOBAL group_replication_bootstrap_group = OFF;（漏这步会导致后续节点无法加入）
• 其他节点依次执行 START GROUP_REPLICATION（不要设 bootstrap_group）
• 全程确认 performance_schema.replication_group_members 中所有成员状态变为 ONLINE，且 MEMBER_ROLE 正确（单主模式下仅一个 PRIMARY）

注意：group_replication_bootstrap_group 是危险开关，只能由**唯一可信节点**在**确认无其他节点存活**的前提下使用。误用会导致两个独立组共存，即脑裂。

为什么调大 group_replication_member_expel_timeout 很关键？

默认值为 0（旧版）或 5（8.0.21+）看似合理，但在跨机房、云环境或高负载 MySQL 实例上，5 秒心跳超时太激进。一次 CPU 抢占或磁盘 I/O 峰值就可能让节点被误驱逐。

• 生产建议设为 10 或 15，配合 group_replication_autorejoin_tries = 3（8.0.16+ 支持），允许节点在短暂失联后自动重试加入
• 若用的是 GreatSQL，还可调 group_replication_communication_flp_timeout（最低可设 3），把可疑判定阈值也放宽
• 调整后需重启组复制生效，但不用重启 mysqld

最易被忽略的一点：这个参数只影响“驱逐决策”，不影响“状态显示”。节点仍可能在 SUSPECT 状态停留十几秒，只要没到超时，就不算真正失败——盯着监控看 MEMBER_STATE 切换比刷 SHOW PROCESSLIST 有用得多。