1. 复制的核心链路四个角色如何接力把事务搬到备库MySQL主备同步这个词很多后端同学每天挂在嘴边可等真出故障时很少有人能在十分钟内说清楚数据到底是怎么从主库走到备库的。我之前在某个订单业务里就吃过一次亏主库磁盘异常高可用工具判定要切换切换过去之后业务立刻报主键冲突。查到最后发现备库的中继日志里堆着几百个事务没回放完切换动作把这个“还没追上”的备库直接当成了新主库数据当然对不上。从那次之后我把复制链路上的线程、日志、格式和坐标机制彻底捋了一遍。这篇文章就围绕主备同步的原理和完整过程把核心链路、binlog格式选择、GTID机制、延迟监控和切换实操逐一梳理适合正在维护主从架构的DBA、后端工程师也适合准备系统学习MySQL复制的新手建立一个完整认知。很多资料讲主备同步喜欢直接甩架构图但真正干活的时候你更需要知道每个角色在此时此刻正在做什么。整个复制机制可以看成四个角色串成的一条流水线主库会话负责提交事务并写binlog主库的dump线程负责把binlog推送给备库备库的IO线程负责接收并落地为中继日志备库的SQL线程负责读中继日志并重放。备库读到的每个事务最终都会以“事件”为单位进入本地存储。注意主库的dump线程与备库之间实际上保持着长连接主库会主动推送日志而不是备库反复轮询。理解这一点很重要它决定了同步延迟的起点尽量靠近“实时”而不是“定期拉取”。那为什么还需要两阶段提交来协调主库内部的redo log和binlog因为在InnoDB里事务提交既要写redo log也要写binlog两者如果只写一半主库一旦崩溃就可能在恢复后出现“某个事务在redo log里有、binlog里没有”的情况。备库只认binlog结果就是主库比备库多了一个事务主备从此不一致。两阶段提交保证了“redo log和binlog要么都生效要么都不生效”实际上也是整个复制机制的第一道一致性屏障。我自己记忆这套架构时习惯用一句话概括主库会话“无脑写日志”dump线程“无脑发日志”IO线程“无脑收日志”SQL线程“无脑重放日志”。四个角色的交接点分别是binlog文件、网络连接、中继日志文件和数据文件任何一个环节出问题表现出的症状都会完全不同。1.1 主库侧的两个角色会话提交与Binlog Dump主库侧最容易被忽略的一个点是binlog并不是事务执行过程中实时写的。InnoDB每个事务都有独立的binlog cache事务执行过程中产生的日志先存在cache里等到事务提交时才统一写入binlog文件。这就是为什么大事务执行时间很长但期间你在备库看不到任何动静只有当它提交那一刻日志才真正对外可见。理解这一点很多关于“为什么备库延迟突然暴涨”的疑问就能解释一半。binlog从cache落入磁盘受参数sync_binlog控制。sync_binlog0时由操作系统决定何时落盘sync_binlog1时每次事务提交都强制刷盘sync_binlogN时每N次事务提交刷一次盘。为了尽量不丢已提交事务生产环境我一般建议主库把sync_binlog和innodb_flush_log_at_trx_commit都设为1俗称“双1”。这两个参数一起为1意味着事务提交时binlog和redo log都需要真正落盘性能会有损耗但换来的是一致性底线。主库侧另一个角色是binlog dump线程。它是每来一个备库连接主库就为这个连接单独创建一个dump线程负责读取binlog并推送给备库。你可以在主库上执行SHOW PROCESSLIST看到类似下面这样的会话State是“Master has sent all binlog to slave; waiting for more updates”这就是dump线程处于空闲等待状态SHOW FULL PROCESSLIST; -- 输出里找 State 中包含 Binlog Dump 的行这个线程看起来不起眼但它承载着一个关键职责它知道每个备库当前消费到哪个binlog文件名和具体偏移量。备库如果断线重连dump线程会从备库上报的位点继续推送而不是从头重传。1.2 备库侧的IO线程、中继日志与SQL线程备库侧的工作被拆成了两个线程这是MySQL复制设计里非常巧妙的一点。IO线程负责连接主库把dump线程推送过来的binlog事件写入本地的relay log也就是中继日志。SQL线程负责读取relay log把里面的内容逐条重放到备库自己的存储引擎中。两个线程解耦IO线程受网络影响SQL线程受本地执行性能影响两者互不阻塞。为什么要多中转一层relay log而不是让SQL线程直接消费网络流最直接的原因是稳定性。主库推送的binlog事件如果不在备库本地存一份SQL线程一旦执行变慢网络连接长期挂着任何闪断都会导致数据丢失。有了relay log即使SQL线程回放很慢IO线程也可以先把日志完整收下来SQL线程慢慢追数据最终不会因为网络波动而丢。更实际的价值是当主库突然宕机时relay log里可能还攒着若干事务没重放完这决定了你的备库到底“追上”了没有。这三个线程的异常表现对应着完全不同的故障原因IO线程异常主库连不上、账号权限不对、网络被防火墙拦截、主库binlog被清理 SQL线程异常备库执行报错、主键冲突、表结构不一致、磁盘只读或空间不足很多新手一看到备库复制中断第一反应是重连IO线程实际上绝大多数复制中断来自SQL线程重放失败。我排查时的顺序通常是先看SHOW SLAVE STATUS里的Last_SQL_Error再看IO线程状态因为SQL线程错误通常更具体能直接告诉你哪条SQL、哪个库表出了问题。1.3 一个UPDATE事务在主备之间的完整生命周期把抽象角色落到具体事务上整个链路会清楚很多。假设主库上执行了这样一条更新UPDATE order_info SET status 3 WHERE order_id 10086;这条语句在autocommit开启的情况下会作为单个事务提交。主库会话在事务执行阶段把行变更记录到binlog cache事务提交流程触发两阶段提交sync_binlog1时binlog强制刷盘随后binlog文件里出现了一组事件至少包含一个GTID事件、一个Query事件或若干个Table_map加Update_rows事件dump线程感知到binlog尾部有新内容通过复制连接把这些事件推送给备库。备库IO线程收到事件后按顺序追加写入relay log同时更新主库信息记录文件记住自己已经收到的坐标。SQL线程从relay log中读取事件逐条在备库执行更新行、写入redo log和binlog如果log_slave_updates开启、提交事务。主库和备库对这个事务的最终落点其实都是做了一遍完全相同的变更只是备库是“被动执行”主库是“主动执行”。我在这个环节踩过的一个典型坑是备库的log_slave_updates没有开启。平时单个主备看不出问题但一旦这个备库后面还想再接一个从库第二个从库就永远追不上来因为它连接的这个备库根本没有把自己重放过的binlog再次写出来。所以只要备库未来可能继续向下级联复制就必须把log_slave_updatesON打开。2. Binlog格式决定一切ROW、STATEMENT、MIXED怎么选才对聊完链路必须回答一个绕不开的问题binlog文件里到底记了什么MySQL提供了三种记录格式STATEMENT、ROW、MIXED。很多生产事故的根源不是复制链路断了而是binlog格式选得不对导致备库虽然“同步跑着”数据却早就偏离了主库。这个选择会影响日志体积、同步正确性和排查binlog的难度值得认真对待。2.1 STATEMENT格式SQL原文复制空间省但确定性差STATEMENT格式记录的是SQL语句本身备库拿到后重新执行一遍。优点是日志量小因为一条更新一万行的SQL在STATEMENT格式下可能只占几百字节而在ROW格式下可能产生几MB甚至几十MB的事件。缺点是语句执行结果必须完全确定。MySQL里有一批函数在不同时间、不同节点上执行结果并不一样最典型的是NOW()、UUID()、RAND()、SYSDATE()。如果主库执行UPDATE t SET update_time NOW()备库执行时NOW已经变了两边数据就会存在秒级甚至更大的偏差。更隐蔽的是LIMIT更新的场景例如一条带ORDER BY ... LIMIT 1的UPDATE主备两边的查询计划稍有差异更新的那一条行可能都不一样。在我见过的STATEMENT格式翻车案例里最常见的是存储过程或触发器。主库调用存储过程时binlog里记录的可能是调用动作而不是过程内部的每一条语句备库触发后过程内部依赖会话变量、临时表的结果极容易不一致。MySQL官方也明确提示使用非确定性函数时STATEMENT格式无法保证复制一致。所以哪怕它省空间我也基本不推荐把它作为生产环境的默认格式。2.2 ROW格式按行变更记录安全但文件膨胀ROW格式不再记录“做了什么”而是记录“哪些行变成了什么样”。一个UPDATE事件在ROW格式下会被拆成Table_map事件加Update_rows事件其中明确包含变更行的主键、被修改列的前镜像和后镜像。备库重放时本质上是按这些行数据做精确替换执行结果几乎不受环境差异影响。代价也在这里。同样是更新一万行ROW格式会在binlog里写一万行的变更前后数据日志量大幅膨胀。如果更新的表没有主键每个事件里还需要包含整行数据膨胀倍数更夸张。为了缓解这个问题MySQL 5.6以后支持binlog_row_image参数可以设为FULL或MINIMAL前者记录所有列的镜像后者只记录被修改列和主键。MINIMAL能显著缩小日志体积是我在生产环境里的首选。ROW格式还有一个额外好处binlog可以当审计日志用。如果一个DBA误更新了一行数据借助ROW格式的binlog你能清楚看到操作前值是什么、操作后值是什么甚至可以通过解析binlog做逆向恢复。这在STATEMENT格式下几乎不可能做到。我在前一家公司做数据订正时就多次靠ROW格式的前后镜像快速恢复了被误更新的业务数据效率比找备份再回滚高得多。2.3 MIXED模式的实际表现与选型建议MIXED模式可以理解为MySQL自动判断大多数语句按STATEMENT记录以节省空间一旦遇到非确定性函数、临时表操作等容易导致复制不一致的场景就自动切换成ROW格式。这个设计初衷很美好但它并不能覆盖所有隐患比如存储过程内部的某些逻辑已经被判定为“安全”但实际操作仍然依赖会话状态跳过了自动切换。因此MIXED只是一个折中方案不是万能答案。三种格式可以放在一起对比对比维度STATEMENTROWMIXED日志体积小大尤其大事务下膨胀明显通常小特殊场景自动转ROW复制一致性受非确定性函数影响高逐行精确变更大部分可靠边缘场景仍可能有意外可读性/审计价值低只能看到SQL高能看到前后镜像取决于最终是否转为ROW生产推荐度不推荐强烈推荐兼容场景可以考虑对绝大多数生产环境我的建议是直接使用ROW并开启binlog_row_imageMINIMAL。同步一致性的优先级永远要高于磁盘空间和IO开销。磁盘可以通过扩容解决主备数据不一致的隐患却可能在切换时一次性爆发代价远不是一个binlog膨胀能比的。3. 从Position到GTID复制坐标系统的两代方案备库要接着主库继续同步就必须知道“上次收到哪了”。这个位置信息就是复制的坐标。MySQL提供了两代坐标方案老一代的“文件名文件偏移量”以及后来的全局事务标识GTID。两者的设计思路完全不同对故障定位和主备切换的影响也非常大。3.1 传统FilePosition定位的痛点传统配置中建立主从关系的核心SQL长这样CHANGE MASTER TO MASTER_HOST 192.168.1.10, MASTER_USER repl_user, MASTER_PASSWORD xxxxxx, MASTER_LOG_FILE mysql-bin.000012, MASTER_LOG_POS 4210;这里的MASTER_LOG_FILE和MASTER_LOG_POS就是主库binlog文件名加字节偏移量。备库IO线程从该坐标开始请求主库dump线程继续推送。这套逻辑本身不复杂麻烦在于切换场景。假设主A挂了备B接管成为新主业务继续写入B产生了新的binlog。此时要新增一台备C挂在B下面C应该从B的哪个binlog位点开始拉取答案是B从A同步过来的最后一个事务之后的位置也就是SHOW MASTER STATUS的当前位置。这个位置查询和记录由人来做极易出错。尤其是在原主A只是短暂故障又恢复时要把A重新变成备库必须找到A“丢失了哪些事务”的精确位点而这个位点需要结合多个节点手工比对过程繁琐且容易漏。我当时做过一次传统位点方式下的主库降级因为没算准原主库缺失的最后一个事务坐标导致新主库上已经存在的主键在旧主库上被重复插入整个链路切回去又花了大半天。这种痛苦经历让我后来在所有MySQL 5.7及以上环境里都坚持切到GTID。3.2 GTID的生成、分发与消费逻辑GTID全称Global Transaction Identifier表现形式是UUID:事务序号例如4e7f5c9a-1a2b-4c3d-8e4f-123456789012:1。前半部分是每个MySQL实例在初始化时生成的server_uuid全球唯一后半部分是该实例上事务的递进序号。一个事务在主库上生成GTID后无论它通过哪条复制链路传到哪个从库它的GTID都不会变。引入GTID后备库判断事务是否已经执行过变得非常简单每条事务都带一个固定ID备库只需检查自己的gtid_executed集合里是否已经包含这个ID。如果包含SQL线程会主动跳过如果没有包含则正常执行。这天然避免了重复执行导致的异常。建立复制关系时也不再需要手动找位点直接启用自动定位即可CHANGE MASTER TO MASTER_HOST 192.168.1.11, MASTER_USER repl_user, MASTER_PASSWORD xxxxxx, MASTER_AUTO_POSITION 1;自动定位的底层逻辑是备库把自己的retrieved_gtid_set和executed_gtid_set发给主库主库侧对比之后从备库缺失的GTID位置开始推送。这个机制解决了传统位点模式下“手工对齐位点”的最大痛点也是主备切换操作大幅简化的根本原因。3.3 GTID模式下的切换边界与经典“跳事务”操作GTID不是打开了就一定安全它有两个必须注意的配置项gtid_modeON和enforce_gtid_consistencyON。后者很重要它禁止某些可能导致GTID无法正确分配的操作比如在事务内创建临时表、同时更新多个非事务引擎表等。只开gtid_mode不开enforce_gtid_consistencyGTID不会真正给你提供一致性保障。GTID模式下最经典的运维操作是“跳过一个坏事务”。复制因为某条SQL在备库执行失败而中断例如备库上缺少一个索引更新时无法定位到对应行。你希望跳过这个出错事务让复制继续跑下去。传统位点模式可以执行SET GLOBAL sql_slave_skip_counter 1但GTID模式下这个命令失效。正确做法是手工构造一个空事务来占用这个GTID-- 先停止复制然后注入空事务 STOP SLAVE; SET GTID_NEXT 4e7f5c9a-1a2b-4c3d-8e4f-123456789012:1024; BEGIN; COMMIT; SET GTID_NEXT AUTOMATIC; START SLAVE;这样做本质上是在备库的gtid_executed里把这个GTID标记为已执行后续主库推送过来时SQL线程就会自动跳过。跳过事务治标不治本执行前最好确认备库不会因为跳过而产生结构性数据漏同步否则后面只会换来更大的坑。4. 同步延迟的真相别只盯着Seconds_Behind_Master主备同步最让运维头疼的指标就是同步延迟。备库永远只能异步跟随主库当主库压力大、写入频繁时备库可能读不过来产生延迟。但“延迟”这个指标在MySQL里并不是一个可以直接信以为真的数字它背后有不少计算和统计上的坑。4.1 Seconds_Behind_Master指标为什么不可靠SHOW SLAVE STATUS返回结果里有一列Seconds_Behind_Master字面意思是备库落后主库多少秒。它的计算逻辑是备库系统时间与SQL线程正在执行事务的binlog时间戳之间的差值。这个设计在多数时候可用但在两种情况下会严重失真。第一种是备库服务器与主库服务器之间存在系统时间差。如果备库时间比主库慢了十分钟即使复制完全实时Seconds_Behind_Master也会一直显示十分钟左右造成“永远在追赶”的错觉。第二种更隐蔽当SQL线程刚处理到某个大事务时它会把这一列的数值显示为0因为该事务还没有执行完毕无法获取最新时间戳。也就是说大事务正在拖垮备库时监控面板反而可能显示“延迟为0”等到事务执行完数值又瞬间跳回几百甚至几千秒。我自己排查延迟时从不把一个监控指标当结论。我更常用下面这些组合查看SHOW SLAVE STATUS中IO线程与SQL线程是否同时处于Yes状态对比主库和备库的SHOW MASTER STATUS位点检查备库relay log存量。如果主备之间是GTID模式直接对比双方的global.gtid_executed缺失集合就能量化差距。最简单直接的命令是多次执行主备库的SHOW MASTER STATUS和SHOW SLAVE STATUS观察位点是否在持续推进。4.2 延迟的常见成因大事务、DDL、单线程与网络阻塞同步延迟不是单一原因造成的我遇到的真实案例里最典型的有这样几类。一个千万行级别的表执行大UPDATE主库只用了几分钟但因为事务内要记录大量binlog事件备库SQL线程逐事件重放的总耗时可能是主库的好几倍。此时延迟会像水位一样快速上涨短时间无法回落。大事务是延迟治理里最棘手的场景因为它同时占满IO、CPU和锁资源。另一个常见来源是一次线上DDL。比如给大表增加字段主库执行可能几十秒但备库由于延迟或锁等待要卡在此处极长的时间甚至把后续几百个事务全堵在后面。这也是为什么很多团队会坚持在低峰期做DDL并且用专门的在线变更工具拆分执行。历史版本MySQL的SQL线程是单线程回放的备库回放速度天然受限于单实例单线程的吞吐能力。即使IO线程已经把日志全部收到relay log里SQL线程也可能追不上主库的并发写入。如果主库本身是多线程并发写入单线程回放就成了明显瓶颈。还有一类延迟被低估备库磁盘性能太差。主库用SSD备库用普通机械盘IO线程接收日志没有压力但SQL线程每执行一个事务都要频繁刷盘性能会成倍下降。我在课外的经验是至少保证备库磁盘规格不弱于主库否则延迟会随着业务增长定期爆发。4.3 治理延迟的两张牌半同步复制与并行复制针对同步延迟有两条路可以走一条是降低延迟对数据丢失的影响另一条是直接提升备库回放速度两者侧重不同。半同步复制的核心调整点是主库在事务提交时必须等待至少一个备库确认已经收到并记录了binlog才向客户端返回成功。它本质上是牺牲部分主库写入响应时间换取更低的故障数据丢失窗口。注意半同步只保证“日志收到了”不保证“事务已经重放完成”因此它降低的是“主库宕机瞬间丢掉已提交事务”的概率但延迟本身并没有减少。如果同步链路长期落后半同步不但治不好延迟反而会因为等待备库确认让主库写入变慢拖累整个业务。生产环境要谨慎使用半同步并配合超时设置防止一个慢备库拖垮主库。并行复制是真正提升回放速度的工具。MySQL 5.7之后引入了基于last_committed的并行复制策略备库SQL线程可以由多个worker线程并行重放同一时刻在主库上提交的多组事务。只要事务之间没有锁冲突并行度就能显著提升。相关参数主要是-- 设置并行从线程数 SET GLOBAL slave_parallel_workers 8; -- 事务级调度策略 SET GLOBAL slave_parallel_type LOGICAL_CLOCK;从单线程提升到8个并行worker实际收益在小事务高频写入场景下非常可观。我见过一个QPS较高的账务库开启并行复制后平时几十秒的滞后直接降到秒级。但并行复制也有前提备库磁盘和CPU要给得住否则多个worker同时刷盘反而把IO压垮延迟不降反升。5. 主备切换的最后一公里数据、坐标、意外一个都不能少主备同步最终要服务的目标是在主库故障时快速切换尽量减少业务停摆和数据丢失。但“切换”这个动作本身包含不少容易被忽略的细节尤其是切换执行前必须确认备库是否真正完整追上了主库。很多人在这一步翻车不是不会执行STOP SLAVE和CHANGE MASTER而是没有建立一套完整的切换前核对清单。5.1 切换前的数据一致性核验与坐标对齐常规计划性切换前优先确认的不是别的而是备库的状态。第一条命令就是SHOW SLAVE STATUS\G重点看Slave_IO_Running和Slave_SQL_Running是否都是YesLast_SQL_Error是否为空以及Seconds_Behind_Master是否接近0。但正如前面说的这个指标不可全信更稳妥的是对比主备两边的复制位点或GTID集合。传统位点模式下主库执行SHOW MASTER STATUS备库执行SHOW SLAVE STATUS两者指向同一binlog文件名和相近偏移量才算对齐。GTID模式下则对比两边global.gtid_executed只要备库的集合已经包含主库集合中的全部GTID就表示备库没有缺失任何事务。一种更严格的验证方式是在切换前对关键业务表做一次全量或抽样数据校验。备用库上的数据要与主库一致除了复制状态正常还需要排除那些因为误操作或复制扭曲导致的数据偏差。我通常会对比核心订单表的行数、主键最大值、更新时间最大值以及若干关键字段的哈希值。数据校验要提前做而不是在切换窗口内临时跑因为全量大表校验一次可能耗时很久。5.2 一次标准切换过程与容易漏掉的步骤计划性主备切换的完整动作按顺序大致是下面几步暂停写入在主库上执行业务侧停写操作比如关闭应用写入开关或设置read_only。等待备库追平再次确认复制位点/GTID已经对齐且所有relay log都已回放完毕可以手动执行STOP SLAVE来保证不再接收新日志。提升原备库为新主在备库上执行STOP SLAVE; RESET SLAVE ALL;然后取消read_only并确认super_read_only也已关闭。应用连接切换到新主库验证写入正常。把原主库或其他从库重新指向新主库并启动复制。这里最容易漏掉的是第2步和第3步之间的联动。很多切换脚本只执行了STOP SLAVE但忘记检查relay log是否已经完全清空。如果SQL线程还没把relay log里的积压事务重放完就停掉了这个备库在切换后立刻是一个“缺数据”的主库。正确做法是让SQL线程自然追平后再停止或者至少检查SHOW SLAVE STATUS中的Relay_Log_Space是否已经稳定在较小值且Seconds_Behind_Master已经归0。另一个常见遗漏是权限问题。新主库上的复制账号可能因为旧主库带过来的授权数据而没有同步导致从库连接失败。我在一次演练中就遇到类似问题切换后所有从库同时报连接主库失败排查半天才发现复制账号对应的用户在新主库上不存在。解决方案是在切换前就确认复制账号已在所有节点创建好并提前用相同账号测试连接。5.3 切换演练中的典型翻车案例与复盘要点有一位同事在某次切换演练中模拟主库宕机来验证高可用系统脚本判断主库不可达后自动把某备库提升为新主。因为半同步没有开启主库在崩溃前有一个已提交事务尚未发送给任何备库切换完成后这个事务彻底丢失。更麻烦的是这个事务涉及的订单已经对外返回成功业务侧后来对账时才发现少了一条记录。这次事故复盘下来结论很清晰如果要求故障场景下的主备切换尽量不丢数据就必须在半同步复制或更高等级的容灾机制上下功夫。半同步复制虽然牺牲了一点响应时间但能把“已提交而未同步到备库”的窗口大幅缩小。演练的意义也正在于此它不是为了证明流程能跑通而是为了暴露“我以为已经对齐数据其实没有”的隐性风险。我自己的习惯是每次切换演练结束后强制要求看一眼新主库与旧主库的GTID集合差异并把差异结果存档。如果整整一次演练下来两边GTID集合完全一致那说明复制链路和切换脚本都基本可靠只要存在差异不管差异多小都要先弄清楚原因再继续下一轮演练。最后分享一个日常维护的小技巧不要只在故障时才看复制状态。把主备同步的线程状态、延迟、binlog空间、relay log积压量纳入日常巡检哪怕只是每天看一眼SHOW SLAVE STATUS的关键列也能在问题发酵之前发现苗头。主备同步本质上是数据安全的地基地基稳了高可用切换才能成为真正的“兜底方案”而不是下一场事故的起点。