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' 就得立刻检查账号权限和密码是否一致。
面向 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 有用得多。
