MGR能保证RPO=0，因其强制多数派确认才提交事务；主从复制默认不等从库响应即返回成功，底层机制差异决定此不可通过配置绕过。
为什么MGR能保证RPO=0，而主从复制做不到
因为MGR强制多数派确认才提交事务，主从复制默认不等从库响应就返回成功。这是底层机制差异，不是配置能绕过的。
group_replication_consistency 参数怎么影响一致性行为
这个参数决定事务在组内同步的严格程度，不同取值对应不同语义：
-
eventual：默认值，事务在本地提交后立即返回，其他节点异步追上（类似半同步的松散版） -
before_on_primary_fanout：单主模式下，写操作执行前必须收到多数节点就位确认，避免读到旧数据 -
after：事务在所有存活节点都应用完才向客户端返回成功，真正实现强一致，但延迟明显上升
注意：after 模式在3节点集群中意味着至少2个节点完成apply，一旦有1个节点卡住，整个写入就会阻塞。
写集（write set）冲突检测如何防止脏写
MGR不是靠锁表或串行化来防冲突，而是靠事务提交时比对修改行的哈希集合：
- 每个事务提交前，会把修改的主键+唯一键生成一个
write set哈希值 - 该哈希广播给组内所有节点，如果另一个节点已提交过相同
write set，当前事务立刻被拒绝 - 错误信息是
ER_GROUP_REPLICATION_CONFLICTING_TRANSACTION，不是锁等待超时
这意味着：两个节点同时更新同一行，后发起的那个事务根本不会进入binlog，而是直接失败——这和主从复制里“谁先写谁赢、后写的覆盖前写”有本质区别。
网络分区时MGR为什么不会脑裂，主从复制会
关键在法定票数（quorum）机制：
- MGR要求至少
(n/2)+1个节点在线才能继续写入；3节点集群断掉1个，剩下2个仍可服务；断掉2个，剩下1个自动只读 - 主从复制没有法定概念，只要从库连得上主库就照常同步，网络分区后可能出现两个主库各自接受写入
-
group_replication_member_expel_timeout默认5秒，超时未响应即被踢出组，不是靠心跳“认为”它还活着
真正容易被忽略的是：MGR的“一致性”依赖于节点数为奇数且部署跨故障域。偶数节点（如4个）在分区时容易陷入2 vs 2僵局，导致整个组不可写——这不是bug，是Paxos协议的必然约束。
