脑裂时应选BEFORE或AFTER：BEFORE在事务开始前检查是否属多数派，避免少数派写入；AFTER要求提交前多数派全部落盘，保障强一致。
MySQL组复制脑裂时，group_replication_consistency 怎么选
脑裂发生时，MGR不会自动“选边站”，而是靠多数派+一致性配置共同决定谁能继续写入。关键变量是 group_replication_consistency，它不控制选举，但决定事务能否提交——哪怕节点还在组里。
常见错误现象：脑裂后部分节点看似在线、能连上，但执行 INSERT 报错 ERROR 3092 (HY000): The server is not configured properly to be an active member of the group，其实是该节点已失去多数派支持，但一致性级别设太高（如 AFTER），拒绝提交。
-
EVENTUAL：不等其他节点确认，可能写入分裂后的少数派分支 → 脑裂后数据不一致风险最高 -
BEFORE：事务开始前检查本节点是否在多数派中 → 脑裂后多数派外的节点直接拒绝新事务 -
AFTER：提交前等所有在线多数派节点落盘 → 少数派节点无法提交，但多数派内强一致 - 生产环境建议用
BEFORE_ON_PRIMARY_FAILOVER或AFTER，避免脑裂期间产生不可合并的写入
MGR多数派判断失败的典型原因
MGR判断“多数派”只看当前 group_replication_group_members 视图中状态为 ONLINE 的节点数，不考虑网络延迟、心跳超时阈值或手动踢出残留记录。
使用场景：集群从3节点缩容到2节点后未调 group_replication_autorejoin_tries，或网络抖动导致一个节点反复进出 UNREACHABLE 状态，但 performance_schema.replication_group_members 里还留着旧记录。
- 检查真实在线节点数：
SELECT MEMBER_STATE FROM performance_schema.replication_group_members WHERE MEMBER_STATE = 'ONLINE'; - 强制清理失效成员需先停掉对应节点的 MGR（
STOP GROUP_REPLICATION;），再在其他节点执行SET GLOBAL group_replication_force_members = ''; -
group_replication_member_expel_timeout设太小（如默认0）会导致短暂网络抖动就触发驱逐，反而加剧脑裂感知
脑裂后如何安全恢复，而不是强行重启
强行对少数派节点执行 START GROUP_REPLICATION 极易造成 GTID 冲突或事务回滚失败，因为其二进制日志已包含多数派拒绝的事务。
性能影响：恢复过程不是“重连即完事”，MGR会做完整状态传输（SST 或 IST），若启用了 group_replication_recovery_complete_at 为 TRANSACTIONS_CERTIFIED，还要等所有认证事务完成才能对外提供服务。
- 先确认哪个子集是多数派（至少 ⌊N/2⌋+1 个
ONLINE节点），只在这个子集上操作 - 在少数派节点上执行：
STOP GROUP_REPLICATION;→RESET MASTER;→ 清空gtid_executed相关系统变量（必要时） - 多数派稳定后，再以
group_replication_start_on_boot=OFF启动少数派节点，手动START GROUP_REPLICATION接入 - 切勿跳过
RESET MASTER直接重连 —— 这是多数数据不一致的根源
group_replication_single_primary_mode 对脑裂的影响被严重低估
单主模式下脑裂更危险：一旦多数派丢失主节点，整个集群写入冻结；但如果配置了 group_replication_enforce_update_everywhere_checks=OFF，又开了多主，脑裂时两个子集都可能选出自己的主，产生冲突更新。
容易踩的坑：以为开了单主就“天然防脑裂”，其实只是把问题从“写冲突”转成“全集群不可写”。而运维人员常在脑裂后手动切主，却忘了检查 group_replication_primary_member 是否真在多数派中。
- 单主模式下，主节点必须同时满足：在
ONLINE状态 + 属于当前多数派 + 其group_replication_group_name与集群一致 - 多主模式下，
group_replication_enforce_update_everywhere_checks=ON是底线，否则同一行在两个子集被不同事务修改，合并时直接报ER_GRP_RPL_UWE_CHECK_FAILED - 没有银弹配置能绕过“多数派存活”这个物理前提 —— 所有隔离机制都是在多数派存在前提下的补救，不是替代
