MGR通过多数派确认（N/2+1）强制事务提交前完成写集校验与投票，确保金融级强一致；要求GTID、ROW格式、InnoDB主键表为硬性门槛，自动故障转移无需人工干预。
因为金融场景对数据一致性、故障恢复确定性和写入可追溯性有硬性要求，而MGR在事务提交阶段就强制多数派确认，天然规避了异步复制中“主挂了但从没收到binlog”这类致命丢失风险。
事务提交必须过半数节点确认
异步复制下，COMMIT返回客户端时，binlog可能还没发出去；MGR中，一个事务只有被至少 N/2 + 1 个节点通过 certify 阶段（即写集校验+多数派投票）后，才真正提交。这意味着：哪怕主节点突然断电，只要集群中仍有法定数量的节点存活，该事务就已持久化在多数副本上，不会丢失。
常见错误现象：ER_GROUP_REPLICATION_CONFLICTING_TRANSACTION 报错不是缺陷，而是冲突检测生效的表现——它阻止了两个并发写同一行的事务同时成功，避免了最终不一致。
- 3节点集群：至少2个节点确认才能提交
- 5节点集群：至少3个节点确认才能提交
-
group_replication_consistency = AFTER可进一步要求事务在所有节点 apply 完成后才返回，但会增加延迟
GTID + ROW 格式 + InnoDB 强制约束
金融系统不允许模糊的日志格式或弱一致性引擎。MGR 要求必须开启 gtid_mode=ON、binlog_format=ROW、表必须有主键且使用 InnoDB——这三点直接堵死了传统异步复制里常见的几类隐患：
- STATEMENT 格式下
NOW()、UUID()等函数导致主从不一致 - MyISAM 表无法支持写集（write set）冲突检测，MGR 启动直接拒绝
- 无主键表在多主写入时无法生成唯一写集哈希，事务会被静默拒绝
这些不是“建议配置”，而是 MGR 的启动硬门槛。你没法绕过去，也就没法误配。
自动故障转移不依赖外部仲裁或人工干预
异步复制主库宕机后，切换是否安全完全依赖 DBA 判断：从库的 Seconds_Behind_Master 是不是 0？relay log 有没有 gap？binlog position 对不对？任何误判都可能导致数据回退或丢失。
MGR 不需要这些判断。它靠 group_replication_member_expel_timeout（默认 5 秒）检测失联，靠 group_replication_group_seeds 中预设的法定节点列表做重新配置。只要剩余节点满足法定人数，新主自动选出，应用层看到的只是短暂连接中断，无需重连逻辑或中间件介入。
性能影响点：group_replication_flow_control_mode = QUOTA 在高写入压力下会主动限流，防止落后节点被踢出——这不是故障，而是保护一致性不被稀释的必要机制。
真正容易被忽略的是：MGR 的“强一致”只针对写事务；只读事务（SELECT）不参与组内投票，也不等待同步。如果你的应用混用读写分离连接池，且没做事务级粘性控制，就可能读到旧数据——这不是 MGR 的 bug，而是它按设计把一致性成本精准锚定在写路径上。
