MySQL复制机制深入：半同步复制的两种模式、MGR的Paxos实现与GTID原理

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

MySQL的主从复制是最常用的高可用方案，但默认的异步复制有一个硬伤：主库写完即返回成功，binlog还没传到从库时主库宕机，这部分数据就丢了。

半同步复制解决了这个问题——主库等待至少一个从库确认收到binlog后才返回。但半同步复制有两种等待模式，选错了照样丢数据。

今天把MySQL复制这件事从基础到深入彻底讲清楚。

一、先搞清楚几个核心概念

Binlog（二进制日志） ：MySQL Server层的日志，记录所有数据变更操作（INSERT、UPDATE、DELETE等）。Binlog以事件为单位，每个事件描述一个变更。它是主从复制的数据来源——从库通过读取主库的Binlog来同步数据。

Relay Log（中继日志） ：从库上的日志。从库的I/O线程从主库拉取Binlog后，先写入本地的Relay Log，再由SQL线程读取Relay Log并重放。Relay Log相当于Binlog在从库上的中转站。

主库（Master） ：接受写入操作的数据库实例，产生Binlog。

从库（Slave/Replica） ：通过复制主库的Binlog来同步数据的数据库实例。

ACK（确认） ：从库收到Binlog后向主库发送的确认信号。半同步复制依赖ACK来判断从库是否已收到数据。

SCN（System Change Number） ：数据库系统的变更号，用于精确标识数据库在某个时间点的状态。在Oracle迁移场景中，SCN是增量同步的起始点。

GTID（Global Transaction Identifier） ：全局事务标识符，格式为server_uuid:transaction_id，每个事务在提交时被分配一个全局唯一的GTID。

二、异步复制：基本流程与结构性问题

异步复制是MySQL默认的复制模式。它的工作流程分三步：

第一步：主库执行事务，写Binlog，存储引擎提交，返回客户端成功。

第二步：从库的I/O线程连接主库，请求从指定位置开始的Binlog。主库的Dump线程读取Binlog并发送给从库。从库I/O线程收到后写入本地的Relay Log。

第三步：从库的SQL线程读取Relay Log，重放其中的事件，更新从库数据。

异步复制的核心问题是数据丢失风险。 主库写完Binlog就返回客户端成功，完全不等待从库确认。如果主库在Binlog发送到从库之前宕机，这部分事务在从库上不存在。故障切换后，主库上已提交的数据在从库上消失了。

这个问题的本质是：异步复制的“复制”是一个后台过程，与主库的事务提交没有同步关系。

三、半同步复制：两种等待模式

半同步复制在异步复制的基础上增加了一个等待环节：主库在返回客户端之前，等待至少一个从库确认收到Binlog。

但“等待”发生在哪个环节，直接决定了故障切换时的数据一致性。MySQL 5.7引入了rpl_semi_sync_master_wait_point参数控制这个时机。

AFTER_COMMIT模式（MySQL 5.6默认）的执行顺序是：主库写Binlog → 主库存储引擎提交 → 发送Binlog到从库 → 等待从库ACK → 返回客户端。

问题出在第三步和第四步之间。主库已经提交了事务，其他客户端能看到这个事务的结果。但Binlog可能还没传到从库。故障切换到从库后，这个事务在从库上不存在——其他客户端在主库上看到的数据，在从库上消失了。

AFTER_SYNC模式（MySQL 5.7+默认）把存储引擎的提交推迟到了ACK之后：主库写Binlog → 发送Binlog到从库 → 等待从库ACK → 主库存储引擎提交 → 返回客户端。

主库在等到从库确认之前，事务在存储引擎层面还未提交。其他客户端看不到这个事务的结果。主库宕机时，事务要么在从库上存在（ACK已发出），要么在主库上也不存在（ACK未发出）——两端数据始终一致。

AFTER_SYNC模式解决的是主库崩溃时其他客户端看到的数据与从库不一致的问题。这也是MySQL 5.7之后默认使用AFTER_SYNC的原因。

四、MGR：基于Paxos的自动选主与脑裂防护

半同步复制解决了数据丢失风险，但故障切换仍然需要人工介入。MySQL Group Replication（MGR）在5.7.17引入，目标是实现自动选主和故障自愈。

MGR的核心是分布式状态机复制——组内所有服务器就数据库状态变更达成一致。每个事务在提交前，必须经过组内多数节点的认证和排序。这意味着MGR不依赖Binlog的异步传播，而是通过组通信协议保证数据一致性。

MGR的核心技术是Paxos算法的实现。Paxos充当组通信引擎，提供故障检测、组成员关系和全序消息传递。事务的提交顺序由组内多数节点投票决定，保证所有节点以相同顺序应用事务。

MGR支持两种运行模式：

单主模式：只有一个节点接受写入，系统自动选举主节点。主节点宕机后，组内自动选举新的主节点，无需人工介入。适合大多数生产场景。

多主模式：所有节点都可以接受写入。但多主模式对应用层有额外要求——并发写入可能产生冲突，需要应用层处理。适合对写入扩展要求极高的场景。

MGR内置了脑裂保护机制。如果网络分区导致组内成员无法达成多数一致，系统在问题解决之前不会继续处理事务。这种保护保证了数据不会因为网络问题而在两个分区上分别写入、产生冲突。

五、GTID：让主从切换不再依赖手工位点

传统复制依赖Binlog文件名和位点来定位同步位置。主从切换时，DBA需要手动查找从库的同步位点，操作复杂且容易出错。GTID解决了这个问题。

每个事务在提交时被分配一个全局唯一的GTID，格式是server_uuid:transaction_id。从库记录已执行的GTID集合，主从切换后，从库会自动跳过已执行的GTID，只同步缺失的事务。

GTID的核心价值是自动定位。不再需要手动指定MASTER_LOG_FILE和MASTER_LOG_POS，从库通过GTID集合判断自己缺哪些事务，自动向新主库请求。

GTID的启用需要按顺序切换gtid_mode，不能直接跳变。gtid_mode有四个值：OFF（只能复制匿名事务）、OFF_PERMISSIVE（新事务匿名，可复制GTID或匿名）、ON_PERMISSIVE（新事务GTID，可复制GTID或匿名）、ON（所有事务必须GTID）。在线切换必须按OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON的顺序逐步过渡。

生产环境的最佳实践是：从一开始就启用GTID。 故障切换变得可靠，新副本创建不再是麻烦事，缺失的事务可以快速定位。

六、三种复制模式怎么选

选型建议：非核心业务用异步复制或半同步复制；核心业务用MGR单主模式；已经部署了半同步复制但希望减少人工切换的，可以逐步迁移到MGR。

七、小结

MySQL复制的三层机制解决的是三个不同层面的问题。异步复制提供了基础的复制能力，但存在数据丢失风险；半同步复制的AFTER_SYNC模式解决了主库崩溃时的数据一致性问题；MGR的Paxos协议解决了自动选主和脑裂防护问题；GTID解决了主从切换时的手工位点问题。生产环境的最佳实践是：用GTID做基础，用AFTER_SYNC半同步做数据保障，核心系统升级到MGR。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~