节点状态反复变UNREACHABLE或ERROR，首要排查日志中"gcs: timeout while waiting for message"错误，直接指向GCS心跳中断，需立即检查skip-name-resolve、静态IP配置、mtr丢包率（>0.5%）及RTT抖动（σ>20ms）。
节点状态反复变 UNREACHABLE 或 ERROR，先看日志里有没有 "gcs: timeout while waiting for message"
这条错误直接指向组通信系统（GCS）收不到心跳，不是应用层连接问题，而是底层消息通道中断。它常和网络抖动、防火墙拦截、DNS解析卡住强相关。不要一上来就查 GTID 或重置主从——那些是状态已经崩了之后的补救动作。
实操建议：
- 立刻检查
error.log最近 5 分钟是否高频出现该错误；若存在，跳过同步类排查，直奔网络层 - 确认所有节点都已配置
skip-name-resolve=ON，且loose-group_replication_local_address使用的是静态 IP（如"192.168.164.30:33061"），绝不能是域名 - 用
mtr --report对其他节点做 100 次探测，重点关注丢包率（>0.5% 危险）和 RTT 标准差（σ > 20ms 就可能触发 Paxos 投票超时）
performance_schema.replication_group_members 显示 MEMBER_STATE = OFFLINE 但节点进程还在，大概率是 group_replication_exit_state_action 生效了
这个参数决定节点被踢出集群后的“善后行为”。默认值是 read_only，但如果你设成了 offline_mode，节点就不会自动退出 mysqld 进程，只是断开 GCS 连接并拒绝新事务——看起来像“掉线”，其实进程还活着，ps aux | grep mysqld 能看到。
实操建议：
- 执行
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'group_replication_exit_state_action';确认当前值 - 若为
offline_mode，需手动执行STOP GROUP_REPLICATION;再START GROUP_REPLICATION;才能重新加入；仅重启 MySQL 不起作用 - 若希望故障后自动重试，检查
group_replication_autorejoin_tries是否 ≥ 3（默认为 0）
节点能 ping 通、端口 telnet 也通，但就是加不进集群，重点查 caching_sha2_password 认证失败
MySQL 8.0+ 默认认证插件是 caching_sha2_password，而 MGR 的恢复通道（group_replication_recovery）在未启用 SSL 时会拒绝该插件连接，报错典型为：Authentication requires secure connection 和 Maximum number of retries when trying to connect to a donor reached。
实操建议：
- 登录 MySQL 后执行：
SELECT plugin FROM mysql.user WHERE user = 'mgr_user';，确认复制用户是否用了caching_sha2_password - 临时修复：用
ALTER USER 'mgr_user'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx';切换认证方式（生产环境建议配 SSL） - 验证恢复通道状态：
SELECT * FROM performance_schema.replication_connection_status WHERE CHANNEL_NAME = 'group_replication_recovery'\G，关注LAST_IO_ERROR字段
RESET MASTER 后节点仍无法加入，必须核对 gtid_purged 是否与集群一致
RESET MASTER 会清空本地 GTID 集合，但如果没手动设置 gtid_purged 为集群中最小的已提交 GTID 区间，新节点就无法通过写集校验，永远卡在 RECOVERING 状态。
实操建议：
- 在任一健康节点上执行：
SELECT @@global.gtid_executed;，取结果中最左的 UUID 和最小序号（如bd4ff52e-2868-11ea-91f0-0050568b6568:1-8） - 在待恢复节点上执行：
STOP GROUP_REPLICATION;→RESET MASTER;→SET GLOBAL gtid_purged = 'bd4ff52e-2868-11ea-91f0-0050568b6568:1-8'; - 注意：该语句只能在
gtid_executed为空时执行，否则报错GTID_PURGED can only be set when GTID_EXECUTED is empty
真正容易被忽略的点是：MGR 的“掉线”往往不是单点故障，而是多数派通信链路中某条路径持续劣化——比如三节点集群，A↔B 通、A↔C 通，但 B↔C 单向丢包，就会导致 B 和 C 互相把对方标为 UNREACHABLE，而 A 始终认为它们在线。这种隐性不对称网络问题，用常规 ping 或 telnet 很难暴露，必须用 mtr 或抓包比对双向路径。
