查状态前先看 error.log 里有没有 my-011582 / my-011583 错误码，它们分别表示 donor 连接失败和本地事务认证冲突；再查 performance_schema.replication_group_members 确认 member_state；接着验证 group_replication_member_expel_timeout 是否过小、group_replication_ip_whitelist 和防火墙端口是否配置正确。
查状态前先看 error.log 里有没有 MY-011582 / MY-011583
别急着连 MySQL 执行 SELECT，先翻 /var/log/mysql/error.log（或你实际配置的日志路径）。MGR 故障几乎都会在 error.log 里留下带 MY- 前缀的错误码，比如：
-
[ERROR] [MY-011582] Plugin group_replication reported: 'There was an error when connecting to the donor server'—— 表明节点尝试从 donor 拉取数据失败，常见于 donor 网络不通、端口被拦、或 donor 正处于RECOVERING状态 -
[ERROR] [MY-011583] Local transaction set:后面跟着一长串 hash —— 往往是认证失败，说明该节点本地有未同步事务，且与集群当前视图冲突，通常需人工介入清空或重置
这类错误不解决，后续所有状态查询都可能误导你。尤其注意日志里是否重复出现 message removed from cache before member could recover —— 这不是网络问题，是 group_replication_message_cache_size 不够用了。
用 performance_schema.replication_group_members 看真实成员状态
执行这条 SQL 是必须的，但要注意它只反映“当前被集群认可的状态”，不是“你期望的状态”：
SELECT MEMBER_ID, MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
重点关注 MEMBER_STATE 字段：
-
ONLINE：正常；OFFLINE：插件没启动或没加入过；RECOVERING：正在拉取缺失事务，此时看 error.log 是否有缓存不足警告；ERROR或UNREACHABLE：已被驱逐或通信彻底失败 - 如果某节点显示
OFFLINE但你确认已执行START GROUP_REPLICATION，大概率是group_replication_local_address配置的 IP/端口无法被其他节点访问（telnet 测试一下） - 三个节点中若两个为
ONLINE、一个为RECOVERING，不要手动 stop/start，先等 2 分钟——恢复过程本身需要时间，强行干预反而卡死
确认 group_replication_member_expel_timeout 是否设得太小
这是最常被忽略的“误踢元凶”。默认值是 0（禁用自动驱逐），但很多线上配置误设为 5 或 10：
- 执行
SELECT @@group_replication_member_expel_timeout;查当前值 - 实际容忍窗口 = 该值 + 约 5 秒故障检测延迟（detector_task 每秒检查，判定死亡需超时 5 秒）
- 若设为 5，意味着只要通信中断超 10 秒，节点就被强制移除——虚拟机、高负载、跨机房部署时极易触发
- 生产环境建议设为至少 60，修改后必须先
STOP GROUP_REPLICATION，再START GROUP_REPLICATION才生效；SET GLOBAL单独执行无效
检查 group_replication_ip_whitelist 和防火墙端口
MGR 节点间通信不走 3306，而是走 group_replication_local_address 指定的端口（如 192.168.10.65:24901）。这个端口必须双向打通：
- 在每个节点上执行
telnet {peer_ip} {port}，比如telnet 192.168.10.66 24901，不通就查防火墙或 SELinux -
group_replication_ip_whitelist若显式设置了值，则只认列表里的地址；若没设，MGR 会自动扫描本机网卡生成私有网段白名单（如192.168.0.0/16），公网 IP 默认不在其中 - 跨子网或混合云部署时，必须显式配置白名单，例如：
SET GLOBAL group_replication_ip_whitelist = "192.168.10.0/24,10.10.20.0/24";，且需先停集群再重启才生效
真正麻烦的从来不是报错本身，而是多个参数叠加影响：比如 expel_timeout 设小了导致节点被踢，踢完又因 message_cache_size 不足无法恢复，最后还卡在白名单外连不上 donor —— 排查时得一层层剥，别跳步。
