group_replication_member_expel_timeout 默认为0（禁用自动驱逐），设为5秒时叠加5秒故障检测延迟，总容忍仅10秒，易致节点误踢；生产环境建议设为至少60秒，并需重启group replication才生效。
group_replication_member_expel_timeout 设置过小导致节点被误踢
节点频繁掉线、状态在 RECOVERING 和 OFFLINE 之间跳变，往往不是网络真断了，而是 group_replication_member_expel_timeout 设得太紧。默认值是 0（即禁用自动驱逐），但很多配置里被设成 5 或 10 秒——而 MGR 的故障探测本身就有约 5 秒延迟（detector_task 每秒检查，判定“死亡”需超时 5 秒）。实际总容忍窗口 = group_replication_member_expel_timeout + 5 秒。若设为 5，意味着只要通信中断超 10 秒，节点就被强制移除。
建议操作：
- 确认当前值：
SELECT @@group_replication_member_expel_timeout; - 生产环境建议设为至少 60（单位：秒），尤其在虚拟机、高负载或跨机房部署时
- 修改后需重启 Group Replication（先
STOP GROUP_REPLICATION，再START GROUP_REPLICATION），仅 SET GLOBAL 不生效
group_replication_message_cache_size 不足引发恢复失败
节点短暂离线后尝试重连，却卡在 RECOVERING 状态，日志里出现类似 “message removed from cache before member could recover” 的警告——说明它想拉取的事务已被其他节点的 XCom 缓存清理掉了。这不是网络问题，是缓存撑不住。
关键点：
-
group_replication_message_cache_size默认是 1GB，但吞吐量高的集群可能几秒就填满 - 缓存需覆盖「节点最长可能离线时间 × 每秒平均事务数」，保守估算应 ≥ (
group_replication_member_expel_timeout+ 5) × 预估峰值 TPS × 平均事务大小（通常 1–5KB） - 调整后同样需重启 Group Replication 才生效；不能只改变量就指望缓存立刻扩容
防火墙/SELinux 拦截 MGR 专用端口通信
Windows 或 Linux 上安装后状态始终为 OFFLINE，performance_schema.replication_group_members 查不到其他成员，且 telnet {peer_ip} {port} 失败——大概率是通信端口被拦。MGR 不走 3306，而是用 group_replication_local_address 指定的端口（如 192.168.10.65:24901）进行节点间 P2P 通信。
必须检查：
- 所有节点的防火墙放行该端口（Linux：
firewall-cmd --add-port=24901/tcp；Windows：入站规则允许 TCP 24901） - SELinux 若启用，需执行
setsebool -P mysqld_can_network_connect on（CentOS/RHEL） - Windows 下特别注意：
group_replication_local_address不能写localhost或127.0.0.1，必须用本机真实 IP，否则其他节点无法反向连接
节点间 host 解析失败导致心跳发不出
日志中反复出现 are_you_alive_op 超时、xcom_send_message failed，但 telnet 端口通——说明底层 TCP 连接能建，但上层协议握手失败。常见于节点用主机名配置 group_replication_group_seeds，但 /etc/hosts 或 DNS 未正确映射。
排查要点：
- 每个节点执行
ping mgr1（假设 seeds 里写了mgr1:24901），必须返回对应 IP；不通就立刻补/etc/hosts - MySQL 内部也依赖 hostname ——
SELECT @@hostname;返回值必须能在其他节点上解析，否则 xcom 初始化阶段就静默失败 - Windows 用户额外注意：服务若以 LocalSystem 账户运行，
hosts文件解析可能不生效，建议改用显式 IP 配置所有group_replication_*地址项
