先查error.log中“gcs: timeout while waiting for message”，有则说明GCS心跳中断，需立即排查网络：所有节点设skip_name_resolve=ON、loose-group_replication_local_address用静态IP、mtr检测丢包率>0.5%或RTT标准差σ>20ms即危险。
节点离线不是配置问题，而是通信断了——先查 error.log 里有没有 gcs: timeout while waiting for message，有就直接切网络排查，别碰 GTID、别重置主从、别改 super_read_only。
怎么看节点真离线还是假离线
唯一可信来源是 SELECT * FROM performance_schema.replication_group_members;。这张表的 MEMBER_STATE 字段才是事实：
-
ONLINE：真正可用 -
RECOVERING：还在拉取和回放事务，但没卡住 -
ERROR或UNREACHABLE：已被集群驱逐，底层通信已中断，此时任何SET GLOBAL都无效 -
OFFLINE：插件根本没启动，不是故障，是没开
别用 SHOW STATUS LIKE 'group_replication%' 或 information_schema.GROUP_REPLICATION_MEMBERS，这些在节点刚失联时就可能返回空或陈旧数据，尤其 GROUP_REPLICATION_MEMBERS 在 8.0.23+ 已废弃。
查到 ERROR / UNREACHABLE 后第一步做什么
立刻翻最近 5 分钟的 error.log，搜 gcs: timeout while waiting for message：
- 出现这条日志 = GCS 心跳通道卡死，属于 Paxos 投票层失败，和 MySQL 层无关
- 此时
MEMBER_VERSION不一致、caching_sha2_password认证失败（错误码MY-011582）也会导致卡在RECOVERING，但不会触发这条 GCS 超时日志 - 如果没搜到这条，再查是否因
group_replication_unreachable_majority_timeout = 0导致瞬断就被踢（MySQL 8.0.20 及之前默认值），建议调成 30 或更高
网络层必须验证的三件事
MGR 节点间通信走的是 loose-group_replication_local_address 指定的端口（比如 "192.168.164.30:33061"），不是 3306：
- 所有节点必须设
skip_name_resolve = ON，否则 DNS 解析卡顿 >5 秒就会让 GCS 心跳超时 -
loose-group_replication_local_address必须写静态 IP + 端口，绝不能是localhost、127.0.0.1或域名 - 用
mtr --report -c 100 {peer_ip}测连通性：丢包率 >0.5% 或 RTT 标准差 σ >20ms 就足以导致投票失败；同时确认防火墙放行该端口（Linux 用firewall-cmd --add-port=33061/tcp）
节点长期卡在 RECOVERING 怎么办
先确认 MEMBER_VERSION 是否一致（如 8.0.45 节点加入 8.0.43 组会卡住），再检查认证：
- 若报错含
Authentication requires secure connection或错误码MY-011582，说明caching_sha2_password握手失败，需在 donor 节点上临时允许非安全连接：SET PERSIST require_secure_transport = OFF; - 远程克隆（clone plugin）要求 donor 和 joiner 版本完全一致；binlog 回放则要求 donor 的 patch 版本 ≤ joiner（8.0.17+ 才有此限制）
- 不要依赖
performance_schema.replication_group_member_stats判断同步进度，它只反映本节点视角，断连后数据极易陈旧或为 NULL
最常被忽略的是：GCS 超时和 MySQL 层状态完全解耦，MEMBER_STATE = ERROR 时，节点进程可能还在跑，但已无法参与任何共识——这时候重启 mysqld 没用，重配参数也没用，得先让网络说话。
