单主模式下首个mgr节点必须手动执行set global group_replication_bootstrap_group = on;再start group_replication;，成功后立即关闭引导，否则后续节点无法加入；状态应为online，常见错误源于binlog_format、gtid等核心参数未启用。
单主模式下如何正确启动首个MGR节点
必须手动触发引导（bootstrap），否则节点会卡在RECOVERING状态，永远无法加入组。这不是配置错误，而是设计机制：MGR禁止自动引导，防止脑裂。
- 仅在**第一个节点**执行：
SET GLOBAL group_replication_bootstrap_group = ON;，然后START GROUP_REPLICATION; - 启动成功后立即执行：
SET GLOBAL group_replication_bootstrap_group = OFF;，否则后续节点无法加入 - 确认状态：
SELECT * FROM performance_schema.replication_group_members;中该节点状态应为ONLINE - 常见错误：
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group，通常因binlog_format=ROW、gtid_mode=ON或enforce_gtid_consistency=ON未启用
添加新节点时为什么一直卡在RECOVERING
新节点启动START GROUP_REPLICATION后长时间停留在RECOVERING，本质是“数据追平”阶段失败，不是网络不通就是权限或复制源不匹配。
- 检查 donor 节点是否在线且状态为
ONLINE；group_replication_group_seeds中必须包含至少一个健康 donor 的地址 - 确认 donor 节点已开启
log_slave_updates=ON，否则无法提供 relay log 给新节点恢复 - 验证账号权限：新节点连接 donor 所用的复制用户（如
repl@'%'）需具备REPLICATION SLAVE权限，且 host 匹配（不能只开localhost） - 若使用 MySQL 8.0.23+，注意
group_replication_recovery_complete_at默认为TRANSACTIONS_CERTIFIED，意味着必须等所有待认证事务完成才退出RECOVERING；可临时设为TRANSACTIONS_APPLIED加速上线（但牺牲部分一致性）
group_replication_consistency参数怎么选
这个参数直接影响读写行为和应用感知到的延迟，不是“越强越好”，而要匹配业务语义。设错会导致查询返回过期数据或事务莫名阻塞。
-
EVENTUAL（默认）：读不等待，适合报表、日志类场景；但主切后首次读可能看到旧数据 -
BEFORE_ON_PRIMARY_FAILOVER：新主启动前强制等待所有已认证事务应用完毕，避免切换瞬间数据丢失；适用于金融类强一致要求 -
AFTER_ON_PRIMARY_FAILOVER：新主上第一个写事务提交前，确保所有旧主已提交事务都已应用；平衡一致性与响应速度 - 切忌在多主模式下设
BEFORE类级别——节点间无主从关系，该参数无意义，反而引发不可预知等待
为什么3节点集群挂掉1个还能写，挂2个就全不可写
MGR依赖多数派（quorum）达成共识才能提交事务。挂掉节点数超过容忍上限，剩余节点主动降级为只读，这是防脑裂的硬性保护，不是配置问题。
- 3节点集群：多数派 = 2，最多容忍1节点故障；挂2个只剩1个，无法形成多数派 → 所有节点自动置为
UNREACHABLE或ERROR，拒绝写入 - 生产环境不要部署2节点：多数派=2，0容错，任意1节点宕机整个组不可用
- 监控关键指标：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'group_replication_primary_member'，为空说明已失联多数派 - 恢复方式只有等足够节点上线并重新达成多数派；不能靠
STOP GROUP_REPLICATION; START GROUP_REPLICATION强行重启来绕过
MGR的“自动”背后全是确定性规则，最易被忽略的是：它不解决网络分区下的决策延迟，只保证不做出错误决策。任何试图用超时重试、强制踢出节点等方式绕过多数派约束的操作，都会破坏强一致性前提。
