MGR的“强一致性”指基于Paxos的多数派事务认证机制：事务须经组内多数节点（quorum）在write set层面验证通过并达成共识后才提交，确保成功返回的事务已持久化于多数节点，不因单点故障丢失。
什么是MGR的“强一致性”共识机制
MySQL MGR 的“强一致性”不是指实时强一致（linearizability），而是指基于 Paxos 的多数派写入达成的**事务提交级一致性**：一个事务只有被组内多数节点（quorum）在 write set 层面验证通过并达成共识，才会被允许提交。它不保证读操作立刻看到最新写入，但能确保：只要事务返回成功，该事务就已持久化在多数节点上，不会因单点故障而丢失。
为什么 group_replication_consistency 参数不能绕过 Paxos 投票
这个参数控制的是事务在本地执行前，是否等待组内其他节点完成某些状态同步（如应用完旧事务、确认新主身份等），但它**不改变 Paxos 投票本身**。常见取值和实际影响如下：
-
EVENTUAL：默认值，事务只等本节点写入 binlog 和 write set 广播完成，不等其他节点反馈；适合读写分离且能容忍短暂陈旧读的场景 -
AFTER：事务提交后，强制等待本事务被多数节点接收并认证（但不等应用）；提升写后读一致性，但增加延迟 -
BEFORE_AND_AFTER：最严格，要求事务执行前先等组状态稳定（如无积压、新主已就位），提交后再等多数节点认证；适用于金融类强顺序敏感业务，但显著拖慢吞吐
注意：BEFORE_AND_AFTER 无法规避 Paxos 投票耗时，只是叠加了额外等待点；若网络抖动或节点响应慢，事务会卡在 waiting for group commit 状态，而不是失败重试。
如何验证一次写入是否真的通过了多数派共识
不能只看 SELECT * FROM performance_schema.replication_group_members 中状态为 ONLINE 就认为写入安全。真正判断依据是：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查
performance_schema.replication_group_member_stats表中的count_transactions_in_queue和count_transactions_checked—— 前者非零说明有积压，后者应持续增长 - 确认
count_transactions_certified≥ 多数节点数（例如 3 节点集群需 ≥2）才表示该事务已被多数认证 - 观察
count_transactions_local与count_transactions_remote是否均衡；若前者远大于后者，说明本地写入快但远程同步滞后，可能触发流控（flow control）
错误做法：仅依赖 SHOW STATUS LIKE 'group_replication%' 或 SELECT @@group_replication_group_name 判断集群健康——这些只反映元数据，不反映事务级共识状态。
单主模式下主节点切换时的一致性断层风险
当原主宕机、新主被选举出来后，客户端如果立即发起读请求，可能读到未应用完的积压事务结果。这不是 bug，而是 MGR 默认行为（group_replication_consistency = EVENTUAL）。要缓解：
- 启用
group_replication_consistency = AFTER可让新主在切换后对新写入事务施加更强约束，但对已存在的积压无效 - 配合
group_replication_exit_state_action = READ_ONLY，确保节点离组时自动设为只读，避免脑裂写入 - 关键业务必须搭配 MySQL Router 的
read-only路由策略，把读请求导向已确认完成积压应用的节点（查MEMBER_STATE = ONLINE且count_transactions_in_queue = 0）
最容易被忽略的一点：MGR 的“强一致”保障只作用于事务提交那一刻的 write set 认证，不延伸到后续的 binlog 应用阶段。也就是说，认证通过 ≠ 数据已落盘可读。应用层必须按此设计重试逻辑和读写分离策略。
