group_replication_member_expel_timeout默认为0意味着节点被标记为UNREACHABLE后立即驱逐，不等待；MySQL 8.0.20及之前版本中，5秒探测期结束后即触发驱逐，无额外容忍时间。
因为MGR默认采用5秒探测窗口 + 即时驱逐逻辑，不是“超过5秒就踢”，而是“5秒没收到心跳 → 标记为可疑 → 立即驱逐”（MySQL 8.0.20及之前）。
group_replication_member_expel_timeout 默认为0意味着什么
该参数控制的是“被怀疑后还要等多久才踢”。在 MySQL 8.0.20 及更早版本中，group_replication_member_expel_timeout 默认值是 0，即：一旦某节点被多数派标记为 UNREACHABLE（因连续5秒未收消息），就不再等待，直接触发驱逐流程。
- 这5秒是硬编码的通信检测周期（
SUSPICION_PROCESSING_THREAD_PERIOD是另一回事，它影响的是“多久检查一次可疑状态”，默认15秒） - 真正决定是否踢出的关键时间点是：5秒探测期结束 +
group_replication_member_expel_timeout秒等待 = 实际容忍总时长 - 所以默认行为下，只要网络中断 ≥5秒，且持续到下一轮检测（最坏情况再等15秒），节点大概率被踢
为什么不能只靠自动恢复？
自动恢复（auto-rejoin）只在节点被踢出后才尝试，且有严格前提：
- 从 MySQL 8.0.21 开始才默认启用 auto-rejoin，且仅重试3次，每次间隔5分钟
- 如果节点离线期间，其他节点已推进大量事务，
group_replication_message_cache_size缓存可能被刷空，导致无法补全缺失消息 - 被踢节点恢复连通后，若发现自己的视图已过期（
view_id不匹配），会直接报错退出，不会强行加入 - auto-rejoin 失败后，节点进入超级只读模式（
super_read_only=ON），必须人工干预
如何避免误踢？调哪个参数最直接
调整 group_replication_member_expel_timeout 是最常用、最有效的手段，但要注意版本差异：
- MySQL 8.0.20 及以前：设为
5或10，可将容忍总时长拉到 10–15 秒（5秒探测 + 自定义等待） - MySQL 8.0.21+：默认已是
5，无需改；但若网络抖动频繁，可设为10～20，同时需同步增大group_replication_message_cache_size - 注意：所有节点必须设相同值，否则视图协商失败，集群无法稳定
- 临时测试可用
SET GLOBAL group_replication_member_expel_timeout = 10;，但务必写入配置文件持久化
真正容易被忽略的是缓存与超时的耦合关系：增大 group_replication_member_expel_timeout 意味着节点离线时间变长，而消息缓存大小不变时，旧消息会被快速覆盖——这时即使网络恢复，节点也因拿不到完整历史消息而无法重连。这不是超时设置的问题，是配套资源没跟上。
