优先查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" —— 有这条，就是 GCS 心跳断了，不是 MySQL 层问题，别碰 GTID、别重置主从，直接切网络排查。
看到 MEMBER_STATE = ERROR 或 UNREACHABLE 怎么办
这说明节点已被集群驱逐，不是配置没生效，而是底层通信已中断。此时任何 SET GLOBAL 操作（比如改 super_read_only）都无效，重启 mysqld 也不起作用。
- 先执行
SELECT * FROM performance_schema.replication_group_members;确认状态，这是唯一可信来源；SHOW STATUS和information_schema.GROUP_REPLICATION_MEMBERS在失联初期就可能返回空或陈旧数据 - 若状态是
ERROR，立刻翻最近 5 分钟的error.log，搜"gcs: timeout while waiting for message"—— 出现即表示 Paxos 投票通道已卡死 - 若状态是
RECOVERING却长期不变成ONLINE，重点检查MEMBER_VERSION是否与其他节点一致（如 8.0.45 节点加入 8.0.43 组会卡住），以及caching_sha2_password认证是否失败（错误码MY-011582或Authentication requires secure connection）
网络层必须验证的三件事
MGR 节点间通信不走 3306，而是用 loose-group_replication_local_address 指定的端口（如 "192.168.164.30:33061"），DNS、丢包、RTT 抖动都会直接触发 GCS 超时。
- 所有节点必须设
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，Windows 检查入站规则）
别忽略这两个关键参数的实际影响
group_replication_unreachable_majority_timeout 和 group_replication_member_expel_timeout 控制节点被踢出的速度，值太小会让集群对网络抖动极度敏感。
-
group_replication_unreachable_majority_timeout = 0（MySQL 8.0.20 及之前默认）表示“一旦多数派失联，立即驱逐”，哪怕一次 5 秒瞬断也会变ERROR -
group_replication_member_expel_timeout默认在 8.0.21+ 是 5，但若仍为 0，则节点被标记可疑后会立刻被踢出，没缓冲窗口 - 调大这两个值前，必须同步设置
group_replication_autorejoin_tries ≥ 3，否则节点变ERROR后不会自动重试，只会一直卡在只读态
真正难排查的不是 ERROR，而是节点卡在 RECOVERING 却不报错——这时候磁盘满、donor 不可用、caching_sha2_password 认证失败、甚至 MEMBER_VERSION 小版本不兼容，都可能让它静默挂住，连错误日志都不打。盯紧 performance_schema.replication_group_members 的状态变化节奏，比盯着 SQL 响应时间更关键。
