member_state为error说明节点已被驱逐，须先修复网络等根本原因；查error.log中“gcs: timeout while waiting for message”可提前定位gcs心跳中断，立即检查skip-name-resolve、静态ip、mtr丢包率（>0.5%）及rtt抖动（σ>20ms）。
直接查 performance_schema.replication_group_members 表确认 MEMBER_STATE 是 ERROR，说明该节点已被集群驱逐，不是配置没生效或命令没执行，而是底层通信已中断——必须先恢复网络或修复根本原因，否则任何重启或 SET GLOBAL 操作都无效。
查 error.log 里有没有 “gcs: timeout while waiting for message”
这条日志是 GCS 层心跳中断的明确信号，比任何 SQL 状态都早、更底层。它出现时，MEMBER_STATE 还可能显示为 UNREACHABLE，但几秒后就会变成 ERROR。
- 不要等状态变
ERROR再查日志，只要发现这条错误，立刻停掉同步类排查，直奔网络 - 检查所有节点是否都设置了
skip_name_resolve=ON，否则 DNS 解析卡顿会触发 GCS 超时 -
loose-group_replication_local_address必须用静态 IP（如"192.168.164.30:33061"），不能写域名或localhost - 用
mtr --report -c 100对其他节点探测，丢包率 > 0.5% 或 RTT 标准差 σ > 20ms 就足以让 Paxos 投票失败
确认 group_replication_unreachable_majority_timeout 是否为 0
这个参数决定少数派节点在失联后多久被踢出。值为 0 表示“立即驱逐”，对网络抖动极度敏感——哪怕一次 5 秒的瞬断，都会导致 MEMBER_STATE 变 ERROR。
- 生产环境建议设为 ≥ 30（单位：秒），给网络自愈留出窗口
- 注意：该参数仅在 MySQL ≥ 8.0.16 才生效；旧版本只能靠
group_replication_member_expel_timeout控制驱逐延迟 - 调大后需配合
group_replication_autorejoin_tries ≥ 3，否则节点变ERROR后不会自动重试加入
别碰 super_read_only 强行解锁
MEMBER_STATE = ERROR 时，super_read_only 会被插件自动设为 ON，且此时执行 SET GLOBAL super_read_only = OFF 不生效，重启后也会被重置。
- 执行
SELECT @@global.super_read_only, @@global.read_only只是为了验证：若前者为 1、后者为 0，说明是 MGR 自动锁死，不是人为误操作 - 强行修改不仅无效，还可能破坏集群一致性——尤其当该节点本地 GTID 已超前（见 ERROR 3092 场景）
- 正确做法是先
STOP GROUP_REPLICATION，再修复网络/权限/版本问题，最后START GROUP_REPLICATION
真正麻烦的不是状态变 ERROR，而是节点卡在 RECOVERING 却不报错——这时候 MEMBER_VERSION 不一致、caching_sha2_password 认证失败、磁盘满或 donor 不可用，都可能让它静默挂住，连 ERROR 日志都不打。得盯紧 performance_schema.replication_group_members 的更新时间戳，超过 30 秒没变化就得手动介入。
