一、介绍
MGR （MySQL Group Replication）是MySQL自带的一个插件 ，MGR集 群是多个MySQL Server节点共同组成的分布式集群 ，每个Server都有完整的副本，基于 ROW格式的二进制日志文件（Binary Log） 和 GTID**（Global Transaction Identifier，全局事务标识符）** 特性实现。
二、MGR的优点
- 强一致性：基于 MySQL 原生事务日志（binlog）和复制框架，采用类 Paxos 的 XCom 共识协议实现组复制，以插件形式提供，确保集群内数据的强一致性和事务的原子性与持久性
- 高容错性：只要(节点总数/2 + 1)个节点无故障就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制
- 高扩展性：节点的新增/移除都是自动的，新节点加入后自动从其他节点同步状态，直至与其他节点保持一致；节点移除了，其他节点自动更新组信息
- 高灵活性：有单主模式和多主模式，单主模式自动选主，所有更新操作都在主进行；多主模式，所有节点可以同时处理更新操作
三、MGR的使用约束
- 仅支持InnoDB表，且每张表必须有一个主键，用于做 writeset(修改的主键集合) 冲突检测
- 必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与writeset；主从状态信息存于表中（--master-info-repository=TABLE 、--relay-log-info-repository=TABLE），--log-lave-updates打开
- MGR不支持大事务，事务大小最好不超过143MB，当事务无法在5秒内通过网络在组成员间复制消息时，会怀疑成员宕机了、并将其驱逐出局
- 一个MGR集群最多支持9个节点
- 不支持外键和save point特性，无法做全局约束检测和部分事务回滚
- 二进制日志不支持Binlog Event Checksum
四、MGR适用场景
- 金融交易、重要数据存储、对主从一致性要求高的场景
- 核心数据总量未过亿
- 读多写少的应用场景，如互联网电商
五、注意事项
- 临时关闭selinux防火墙，开启后端口将无法访问
- MGR需要开启新端口24901同步交换，MySQL配置文件中要注意相关端口配置，服务器要开放对应端口
- 配置完所有节点后，一定要执行RESET MASTER命令，它会删除之前已产生的BinLog，因为之前的BinLog包含创建用户这种高权限操作，用于主从同步的rpl_user账户没有权限执行，会导致RelayLog重放无法正确执行，导致从属服务器卡在"RECEVERING"状态
六、MGR模式介绍
- 单主模式（Single-Primary Mode）：只有master节点可读可写（称为 PRIMARY），其余slave节点只读（称为SECONDARY）
- 多主模式（Multi-Primary Mode）：所有节点都可读可写
七、事务执行流程
前提：设置MGR集群6个节点，1主5从。
- 主节点执行事务 ：在 InnoDB 层执行 SQL，生成 binlog event （记录原始 SQL 或行变更），提取 writeset =
{ (t, id=100) }（修改的主键集合），InnoDB 写 redo log（事务此时未提交，是prepare 状态） - 广播 ：主节点将
(GTID, writeset, binlog_event)通过 XCom 发送给所有从节点 - 从节点接收信息后：不执行SQL，先进行认证，检查 writeset 是否与本地认证注册表中的事务冲突，无冲突给主节点返回认证通过ACK
- 主节点收到ACK ：认证通过节点数量>=总节点数(包含主节点自己)/2 + 1，则写binlog(commit状态)、写 redo log(commit状态)，返回客户端成功。未收到足够认证通过数量，则回滚该事务
- 从节点通过异步线程，执行事务 ：通过
binlog_event 重放
问题：
1、全局事务顺序是如何实现的？
通过 XCom（基于 Paxos 的组通信系统）实现"原子广播"（Atomic Broadcast），保证所有节点以完全相同的顺序接收事务消息。
2、每个节点都保存一份全局事务信息表？
是的！每个节点维护两个关键内存结构：
- Certification Registry（认证注册表）：存储已认证事务的 writeset 和 GTID，用于冲突检测
- Applier Queue（应用队列）：存储已认证但未回放的事务（按全局顺序排队）
3、从节点异步应用过程中，会查到事务未提交前的数据吗？
会！这是 MGR 的"最终一致性读"特性。
可以设置参数group_replication_consistency = 'BEFORE'，作用：在当前会话执行任何读操作（如 SELECT）之前，强制等待本节点（本地副本）执行完所有 已在 MGR 集群中达成共识（certified）但尚未在本节点重放（applied）的事务。
4、主从节点事务提交时间不一致，会导致相同查询不同结果吗？
会！但这属于"读不一致"，而非"数据不一致"。MGR 保证所有节点最终存储的数据相同。