MEMBER_STATE变为ERROR是节点被集群驱逐，因GCS心跳彻底中断而丧失Paxos投票资格；须立即检查error.log中“gcs: timeout while waiting for message”出现频率（≥2次/分钟即严重），并验证skip_name_resolve=ON、loose-group_replication_local_address为静态IP、mtr丢包率≤0.5%且RTT标准差σ≤20ms，同时将group_replication_unreachable_majority_timeout调至30秒以缓解网络抖动影响。
MEMBER_STATE 变为 ERROR 不是“退群”，是已被集群驱逐——说明 GCS 层心跳彻底中断，节点已失去参与 Paxos 投票的资格。此时任何 SQL 层操作（如 SET GLOBAL super_read_only = OFF）都无效，必须先恢复通信能力。
查 error.log 里有没有 "gcs: timeout while waiting for message"
这是最直接、最早出现的信号，比 MEMBER_STATE = ERROR 提前数秒甚至数十秒。它代表组通信系统（GCS）收不到其他节点的心跳包，问题不在 MySQL 复制逻辑，而在底层网络或配置。
- 只要这条日志高频出现，立刻停止检查 GTID、binlog、用户权限等上层配置
- 重点翻最近 5 分钟日志，不是“有没有”，而是“出现频率”：每分钟 ≥2 次即属严重
- 若同时看到
gcs: failed to send message to member，说明本节点发不出心跳，问题更可能在本地防火墙或网卡
确认所有节点 skip_name_resolve 和 local_address 配置是否一致
DNS 解析卡顿或地址解析失败会直接触发 GCS 超时，且不会报 DNS 错误，只表现为心跳丢失。
- 每个节点必须设
skip_name_resolve = ON（my.cnf 中），重启 mysqld 生效 -
loose-group_replication_local_address必须写静态 IP + 端口（如"192.168.164.30:33061"），不能是localhost、127.0.0.1或域名 - 用
SELECT @@skip_name_resolve, @@group_replication_local_address;在每个节点上验证，三者必须完全一致
用 mtr 检测节点间真实链路质量
MGR 不走 3306 端口，而是走 group_replication_local_address 指定的端口（默认 33061）。ping 或 telnet 通 ≠ GCS 通。
- 在出问题节点上执行：
mtr --report -c 100 192.168.164.31（目标节点 IP） - 丢包率 > 0.5% 或 RTT 标准差 σ > 20ms，就足以让多数派投票失败
- Linux 上确认防火墙放行该端口：
firewall-cmd --add-port=33061/tcp --permanent && firewall-cmd --reload
别忽略 group_replication_unreachable_majority_timeout = 0 的杀伤力
MySQL 8.0.20 及之前版本默认值为 0，意味着“一旦多数派失联，立即驱逐”。一次 5 秒的网络瞬断就会触发 MEMBER_STATE = ERROR，且不会自动重试。
- 执行
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'group_replication_unreachable_majority_timeout'; - 若返回 0，建议改为 30（单位秒），给网络抖动留出缓冲窗口
- 同时检查
group_replication_autorejoin_tries是否 ≥ 3，否则 ERROR 后不会自动重连
RECOVERING 却不报错——这时候你查日志看不到 GCS 超时，但状态就是不动。得盯紧 performance_schema.replication_group_members 表里的 MEMBER_STATE 更新时间戳，超过 30 秒没变化，就得手动介入查 MEMBER_VERSION、认证插件、磁盘空间这些静默故障点。 
