大家好我是小耶写功课只是为了我踩过的坑你们别再踩了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来判断从库是否已收到数据。SCNSystem Change Number数据库系统的变更号用于精确标识数据库在某个时间点的状态。在Oracle迁移场景中SCN是增量同步的起始点。GTIDGlobal 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 ReplicationMGR在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。故障切换变得可靠新副本创建不再是麻烦事缺失的事务可以快速定位。六、三种复制模式怎么选复制模式数据一致性RTO适用场景异步复制可能丢数据分钟级需人工切换非核心业务、日志同步半同步复制不丢数据AFTER_SYNC分钟级需人工切换大多数生产业务MGR不丢数据 自动选主秒级核心交易、金融级高可用选型建议非核心业务用异步复制或半同步复制核心业务用MGR单主模式已经部署了半同步复制但希望减少人工切换的可以逐步迁移到MGR。七、小结MySQL复制的三层机制解决的是三个不同层面的问题。异步复制提供了基础的复制能力但存在数据丢失风险半同步复制的AFTER_SYNC模式解决了主库崩溃时的数据一致性问题MGR的Paxos协议解决了自动选主和脑裂防护问题GTID解决了主从切换时的手工位点问题。生产环境的最佳实践是用GTID做基础用AFTER_SYNC半同步做数据保障核心系统升级到MGR。小耶在手SQL 不愁还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~
