member_state为error说明节点已被集群驱逐，必须先修复网络等根本原因；查error.log中“gcs: timeout while waiting for message”可提前定位gcs心跳中断，立即检查skip-name-resolve、静态ip、mtr丢包率(>0.5%)及rtt抖动(σ>20ms)。
MEMBER_STATE 为 ERROR 不是配置没生效或命令漏执行，而是节点已被集群正式驱逐——此时任何 START GROUP_REPLICATION 或修改 super_read_only 都无效，必须先定位并修复底层通信中断。
查 error.log 里有没有 gcs: timeout while waiting for message
这是 GCS 层心跳失败的最早信号，比 MEMBER_STATE 变 ERROR 提前几秒甚至十几秒出现。
一旦看到这条日志，说明组通信层已无法收发 Paxos 投票消息，别等状态变 ERROR 再动手。
- 立即检查所有节点是否都设置了
skip_name_resolve=ON（DNS 解析卡顿会直接触发 GCS 超时） - 确认
loose-group_replication_local_address是静态 IP + 端口（如"192.168.164.30:33061"），不能写localhost或域名 - 检查防火墙是否放行了
group_replication_local_address对应端口（默认33061）
用 mtr 测节点间网络质量
GCS 对丢包和 RTT 抖动极度敏感：单次丢包率 > 0.5% 或 RTT 标准差 σ > 20ms 就足以导致投票失败。
mtr --report -c 100 192.168.164.10 mtr --report -c 100 192.168.164.20
- 若丢包率非零、或 RTT 波动剧烈（如从 1ms 突跳到 120ms），优先排查物理链路、交换机 buffer、虚拟机网卡队列
- 不要依赖
ping——它不走 TCP，而 GCS 使用的是自定义 UDP 协议栈，mtr更贴近真实路径
检查 group_replication_unreachable_majority_timeout 是否为 0
这个参数决定少数派节点失联后多久被踢出。值为 0 表示“立即驱逐”，对瞬断（比如一次 3 秒的网卡抖动）毫无容忍。
- MySQL ≥ 8.0.16 推荐设为
30（单位秒），再配合group_replication_autorejoin_tries=3 - 修改后需重启 MySQL 或至少执行
SET PERSIST group_replication_unreachable_majority_timeout = 30; - 注意：
SET GLOBAL不持久，重启即失效
别在 MEMBER_STATE = ERROR 时硬改 super_read_only
此时 MGR 插件已强制将 super_read_only 设为 ON，且：
-
SET GLOBAL super_read_only = OFF不生效 - 即使成功（极罕见），也会破坏集群一致性，尤其当该节点本地
gtid_executed已超前（见ERROR 3092） - 正确流程只有三步：
-
STOP GROUP_REPLICATION - 修复网络 / 权限 / 版本 / 磁盘空间等根本原因
-
START GROUP_REPLICATION
-
最易被忽略的是：节点卡在 RECOVERING 状态却不报错——这时 performance_schema.replication_group_members 的 MEMBER_STATE 时间戳超过 30 秒没更新，就得手动介入查 caching_sha2_password 认证失败、磁盘满、donor 不可用等问题。
