my-011495不是脑裂发生，而是mgr通过多数派机制成功拦截脑裂——节点因无法联系多数成员而主动阻塞写入；其本质是paxos协议下安全保护行为，需通过调优超时参数、修复网络解析等预防，而非依赖force_members强行恢复。
MySQL 8.0 组复制（MGR）本身通过多数派机制天然防脑裂，MY-011495 报错不是脑裂发生，而是脑裂**已被阻止**——节点因失联多数成员而主动阻塞写入。真正要解决的，是让集群在分区后能快速恢复多数，或安全重建。
为什么 MY-011495 不是“发生了脑裂”，而是“成功拦截了脑裂”
MGR 的 Paxos 协议要求事务必须获得多数节点确认才能提交。当一个节点发现剩余可达成员数 ≤ 总成员数 / 2（例如 3 节点中只剩 1 个在线），它就无法再达成多数，于是立即执行 block all updates。这不是故障，是设计行为。
- 错误信息
This server will now block all updates是保护动作，不是崩溃 - 状态停留在
RECOVERING或ERROR，说明该节点已退出共识流程，不参与投票 - 只要还有 ≥2 个节点互通（如 3 节点中 2 个在线），它们就能继续服务并选举新主
group_replication_force_members 是最后手段，不是常规配置项
这个变量仅用于极端场景：全部节点失联、网络完全分裂且无法自动恢复时，人工强制指定新组成员列表。它会清空原组状态，不可逆。
- 必须在所有目标节点上**同时设置相同值**，例如：
SET GLOBAL group_replication_force_members = "192.168.0.123:33061,192.168.0.136:33061" - 设置后需重启 MGR 插件：
STOP GROUP_REPLICATION; START GROUP_REPLICATION; - 操作前必须确认这些节点数据一致（否则强制加入会导致数据覆盖丢失）
- 生产环境严禁写入 my.cnf —— 它只应作为临时应急命令使用
真正有效的预防措施：缩短检测与恢复窗口
多数场景下，MY-011495 源于网络抖动或短暂隔离未及时恢复。关键参数要调得更激进：
-
group_replication_unreachable_majority_timeout：默认 0（无限等待）。建议设为 30（秒），超时后节点可尝试重新探测或触发告警 -
group_replication_recovery_retry_count：默认 10。提高到 30–60，避免因瞬时连接失败直接放弃重连 -
group_replication_recovery_reconnect_interval：默认 60 秒。调低至 5–10 秒，加快重试节奏 - 确保
group_replication_member_expel_timeout≥ 30（默认 0），防止误踢暂时慢的节点
最容易被忽略的底层前提：/etc/hosts 和主机名必须严格匹配
所有节点卡在 RECOVERING、日志反复报 Unknown MySQL server host 'mgr-node2'，90% 是因为 hosts 配置不一致或解析失败。
- 每台机器的
/etc/hosts必须**逐行完全相同**，例如：192.168.0.123 mgr-node1、192.168.0.136 mgr-node2 - 主机名不能是
localhost或127.0.0.1，且三节点主机名必须互异 -
group_replication_local_address中的地址必须能被其他节点用ping mgr-node2解析通 - 禁用 SELinux（
setenforce 0）和放行33061端口，否则插件连 bind 都失败，根本走不到多数判断逻辑
