凌晨被电话叫起来屏幕上就一行红字Could not execute Delete_rows event on table xxx.rundetails; 读取bin文件失败。业务侧的订单状态卡住不动了下游对账数据停在几个小时前主从延迟监控一路飙红。这条报错信息看着吓人其实它把两个不同层面的问题塞进了一句话里——前半截是事件执行阶段的失败后半截是文件读取阶段的失败。处理这类问题的关键是先判断到底坏在哪一层是 MySQL 的 binlog 文件本身被写坏了是下游解析器读到了半截事件还是从库回放时找不到对应行记录。这三个方向的排查手法、修复代价和风险等级完全不同搞混了顺序很容易在小问题上动大手术把本来只是同步位点跳一下的事情做成全量重建。这篇内容写给正在跟 MySQL 主从同步、binlog 订阅、变更数据捕获CDC打交道的人不管你用的是自研的 binlog 消费程序还是开源的解析组件只要你的链路上有“读 binlog 事件”这一步这套排查思路就能直接套用。文中涉及的库表名我统一做了脱敏命令和参数可以照抄但动手之前请务必先在从库或测试环境验证一遍。1. 先把这条报错拆成两半来看1.1 报错文本里的两个独立故障点Could not execute Delete_rows event on table xxx.rundetails这半句描述的是事件已经读出来了但执行不下去。ROW 格式下一条 Delete_rows 事件里装的是被删记录的“前镜像”before image也就是删除之前那一行的完整字段值。执行方拿到这份前镜像要去目标端把对应的行找出来删掉。找不到或者字段对不上就会报这个错。它的本质是数据不一致不是文件坏了。读取bin文件失败这半句描述的是事件还没读出来IO 层就出问题了。可能是文件被截断、校验和失败、offset 越界也可能是读取方把位点定位到了一个事件的中间位置从一个畸形偏移开始解析自然读出一堆乱码。它的本质是文件或位点损坏。这两件事经常同时出现是因为它们往往来自同一个根因一个超大事务把 binlog cache 撑爆了事务在写 binlog 的中途被中断文件里留下了一段残缺的事件序列。残留下游读的时候先报读取失败跳过这段又撞上了执行失败。所以看到这条报错别急着单独处理某一半先把整条链路的因果串起来。提示如果报错里同时出现Error_code: 1032和Cant find record那基本可以确定是执行侧的行匹配失败优先往数据一致性方向查不要一上来就怀疑文件损坏。1.2 Delete_rows 为什么格外容易出事同样是行事件Update_rows 和 Write_rows 出问题的概率明显低于 Delete_rows。原因不复杂删除操作依赖前镜像做精确定位而前镜像的完整性直接决定了能不能找到目标行。如果表结构在同步链路的两端不一致——比如源端加过列、改过字段类型、换过字符集或者两端的主键定义有细微差异——前镜像里的字段和目标端对不上匹配就会失败。另一个高发场景是大批量删除。业务上做数据清理、归档、批量撤销时一条 SQL 删掉几十万行ROW 格式下就会生成一个体积巨大的 Delete_rows 事件序列。这种事件在传输、缓存、解析三个环节都容易踩坑缓存不够会被截断网络缓冲不够会被拆包拆错解析端内存不够会 OOM。我见过最典型的一次是一条DELETE FROM xxx.rundetails WHERE create_time ...一次性干掉了两百多万行binlog 单文件直接跳到下一个编号下游解析到一半就报读取失败。还有一种更隐蔽的情况没有主键或唯一索引的表。这种表上的删除前镜像定位只能靠全字段比对一旦有字段是浮点数、时间戳或者大文本精度和编码的微小差异都会让匹配失败。所以凡是进同步链路的表主键这件事没有商量余地。1.3 一条最典型的故障链复盘把常见现场还原一下某业务系统有一张明细表rundetails按时间做定期清理。某天清理任务的时间范围写错了一次性删了几百万行。这个事务产生的 binlog 体积远超max_binlog_cache_size的限制事务在写 binlog 的过程中被中止。binlog 文件里留下了一个不完整的事务——事件头写了事件体没写完checksum 自然对不上。下游的解析程序按位点顺序读读到这个位置先是校验和不匹配报了读取失败运维同学为了尽快恢复手工把位点往前跳了一段跳到了一个 Delete_rows 事件的中间解析器从畸形偏移开始解码解出来的表名、列数全是乱的于是又报了“无法在表上执行 Delete_rows 事件”。两个报错前后脚出现看起来像是两个问题其实是同一个根因的两次表现。这条链路告诉我们一个判断原则先确认 binlog 文件本身是否完整再谈执行失败。文件都不完整讨论事件执行毫无意义文件完整而执行失败才轮到数据一致性排查。2. binlog 文件结构读懂“读取失败”卡在哪2.1 一个事件由哪几部分组成binlog 文件不是纯文本它是一串二进制事件的顺序拼接。每个事件由三块构成公共头event header19 字节、事件体event body长度不定、校验和checksum4 字节开启binlog_checksumCRC32时存在。公共头里最关键的是四个字段时间戳、事件类型、服务器 ID、事件长度。事件长度这个字段决定了读取方要往后读多少字节如果它和实际剩余字节数对不上读取就会越界。理解这一点非常重要因为绝大多数“读取失败”都是事件长度字段和实际文件长度不匹配造成的。文件被截断时最后一个事件的长度字段还老老实实写着“我要 5000 字节”但文件里只剩 2000 字节读取方读到 2000 字节就到文件末尾了校验和算不出来直接报错。事件体内部的结构又因类型而异。Delete_rows 事件体里包含表 ID、标志位、列数、列位图然后是若干行记录每行记录前面还有一个行标记字节。这个结构是严格按位排列的中间任何一个字节错位后面的解析全盘皆输。所以“从中间某个偏移开始读”这种操作在 binlog 上是绝对行不通的必须从事件的起始位置对齐。2.2 checksum 与截断两种不同性质的“坏”文件层面的问题分两类处理方式完全不同。第一类是逻辑损坏通常是文件被意外截断。磁盘写满、进程被杀、文件系统异常、拷贝过程中断都会造成这种结果。特征是文件大小小于预期最后一个事件的长度字段指向文件之外。这类损坏用mysqlbinlog --verify-binlog-checksum一扫就能确认报错信息一般是Event crc check failed或者Wrong event length。第二类是物理损坏文件大小正常中间某些字节被改写了。这种相对少见多发生在存储介质异常或者被其他进程误写的场景。特征是按位点读的时候在某个固定位置稳定报同一个错用mysqlbinlog --start-position精确跳过去还是错。区分这两类的意义在于逻辑损坏可以靠跳位点绕过物理损坏必须放弃这段文件。逻辑损坏往往只影响文件末尾前面的数据是好的物理损坏的位置不可预测继续用这段文件重放风险无法评估。另外要提醒一句binlog_checksum这个参数在链路两端必须一致。源端开了 CRC32下游解析器却按无校验和的格式去读每读一个事件都会错位四个字节表现出来就是“读什么都是乱的”。这类配置问题排查起来最费时间因为报错信息完全一样只是文件本身一点毛病都没有。2.3 为什么坏点常常落在事务中间理论上一个事务的所有事件应该原子地写入 binlog。但实际实现里事务提交时是把整个事务的 binlog 先写到 binlog cache再一次性刷到文件。这个“一次性”的前提是 cache 装得下。装不下的时候MySQL 会报Multi-statement transaction required more than max_binlog_cache_size bytes of storage事务回滚但已经写下去的部分不会自动清理。这就是坏点落在事务中间的原因。文件里出现了一个有 BEGIN 却没有 COMMIT 的事件序列或者一个 Delete_rows 事件头写了但行数据只写了一半。这种残缺事务在文件里是“合法”存在的——每个单独事件的长度字段和校验和可能都是对的只是语义上不完整。读取方如果只看单个事件的完整性是发现不了的只有在尝试执行或者做事务级校验时才会暴露。排查这类问题的有效手段是按事务边界切分验证。用mysqlbinlog加--start-datetime和--stop-datetime把时间窗口缩到最小逐段输出看哪一段的输出在中途戛然而止。正常的事务输出一定是 BEGIN 开头、COMMIT 结尾中间有缺口就说明被截断了。3. 现场定位的实操步骤3.1 第一步分清是主库坏了、从库坏了还是解析器坏了这一步决定了后续所有动作的方向千万不要跳。我习惯用三个问题快速定位第一个问题主库上这个 binlog 文件本身能正常读吗在主库上执行mysqlbinlog --verify-binlog-checksum --base64-outputdecode-rows -vv /path/to/mysql-bin.000123 /tmp/out.txt看退出码和报错。能完整输出且无报错说明源文件是好的问题在下游。第二个问题从库的 IO 线程和 SQL 线程分别是什么状态执行SHOW REPLICA STATUS\G老版本用SHOW SLAVE STATUS\G重点看Replica_IO_Running、Replica_SQL_Running、Last_IO_Error、Last_SQL_Error、Relay_Log_File、Relay_Log_Pos。如果 IO 线程正常但 SQL 线程停了报的又是 1032那是执行侧的数据不一致文件没问题。如果 IO 线程就停了报的是读取错误那才轮到文件层面。第三个问题如果是独立的 CDC 解析程序它读的是主库的 binlog 还是从库的 relay log读主库 binlog 出问题查主库文件和位点读 relay log 出问题先确认这个 relay log 是不是从主库完整拉取的。我遇到过一次从库的relay_log_purge开着IO 线程还在写、SQL 线程还没消费完文件就被清理了SQL 线程再去读就是“文件不存在”。三个问题的答案组合起来基本能锁定故障层。定位不清就动手最常见的错误是把从库的数据不一致当成文件损坏去重建白折腾好几个小时。3.2 用 mysqlbinlog 做分段验证确认要查文件之后mysqlbinlog是唯一靠谱的工具。几个常用组合我整理在下面# 1. 全文件校验看有没有 checksum 失败或长度异常 mysqlbinlog --verify-binlog-checksum /var/lib/mysql/mysql-bin.000123 /dev/null # 2. 只输出指定位置区间的事件用于精确定位坏点 mysqlbinlog --start-position4 --stop-position1048576 \ --base64-outputdecode-rows -vv /var/lib/mysql/mysql-bin.000123 # 3. 按时间窗口切分适合不知道具体位点的场景 mysqlbinlog --start-datetime2024-05-20 02:00:00 \ --stop-datetime2024-05-20 02:10:00 \ --base64-outputdecode-rows -vv /var/lib/mysql/mysql-bin.000123 # 4. 只看事务边界快速判断有没有 BEGIN/COMMIT 不成对 mysqlbinlog --base64-outputdecode-rows -vv /var/lib/mysql/mysql-bin.000123 \ | grep -E ^(BEGIN|COMMIT|# at) | head -100二分法是这里最好用的技巧。文件 1GB 报错先用--stop-position524288000试前半段不报错就把--start-position挪到 524288000 试后半段报错就继续二分。通常在五六轮之内就能把坏点缩到几 KB 的范围再精确到具体事件。这个方法比从头扫一遍快得多尤其是文件放在慢盘上的时候。输出的内容里要重点看三样东西# at N后面的位点是否连续、每个事务的 BEGIN 和 COMMIT 是否成对、Delete_rows 事件里的表名和列数是否正常。表名出现乱码说明偏移错了列数是零或者异常大说明事件体被截断BEGIN 后面直接跟下一个 BEGIN说明中间的事务被吃掉了。注意带-vv参数会输出伪 SQL遇到大字段BLOB、TEXT时输出体积会爆炸重定向到文件时记得挂个| head -c 50000000之类的保护别把磁盘撑爆。另外--base64-outputdecode-rows不能省否则 ROW 事件只输出 BASE64 编码看不出来是什么操作。3.3 核查事务体积与缓存参数定位到坏点之后下一步是搞清楚为什么会坏。绝大多数情况下答案是大事务撞上了缓存上限。需要核对的参数有这几个参数作用常见默认值建议值max_binlog_cache_size单个事务可用的 binlog cache 上限5.7 极大值近似不限8.0 为 4GB按最大事务体积的 1.5 倍设一般 2GB 到 8GBbinlog_row_imageROW 格式下记录哪些列FULL同步链路可评估改 MINIMALbinlog_transaction_compression是否压缩事务OFF8.0.20 以上可开 ONmax_allowed_packet单个网络包上限64MB大事务场景要同步调大binlog_format日志格式ROW保持 ROW估算最大事务体积有个简单公式影响行数 × 单行 binlog 记录大小。单行记录大小约等于行内各列的实际字节数之和再加上每行十几字节的元信息开销。举个例子一张有 30 个字段、平均行宽 300 字节的表一次删 300 万行产生的 binlog 约 300 万 × 300 字节 ≈ 900MB加上前镜像和事务开销实际可能到 1.2GB 以上。如果max_binlog_cache_size只设了 512MB这个事务必然被中止。反过来算也很有用想知道能安全承受多大的事务就拿当前 cache 上限除以单行记录大小。cache 设 2GB、单行 300 字节理论上限大约 700 万行但实际留 30% 余量更稳妥按 500 万行控制。这个数字应该写进数据清理任务的规范里批次大小不允许超过它。这里有个容易被忽略的细节max_binlog_cache_size是会话级参数改全局只影响新连接。而且它只限制事务缓存不限制单个事件的大小。所以调整它解决的是“事务太大写不进去”不是“单个事件太大读不出来”。后者要靠控制单条 SQL 的影响行数来解决方向不同。3.4 位点与 GTID 的核对方法跳过损坏事件之前必须把位点算准。这里有两套坐标系用哪种取决于你的环境开没开 GTID。开 GTID 的环境位点用Executed_Gtid_Set表示。从库的Retrieved_Gtid_Set是从主库拉到了哪些事务Executed_Gtid_Set是执行完成了哪些。两者差集就是还没执行的事务。跳过某个事务就是把这个 GTID 手工塞进gtid_executed里命令是SET GTID_NEXTxxxx:nnn; BEGIN; COMMIT; SET GTID_NEXTAUTOMATIC;。这套操作看起来简单但顺序错了会造成 GTID 空洞后续主从切换时会出大问题务必在测试环境先演练。没开 GTID 的环境位点就是 binlog 文件名加偏移量。跳过的方法有两种一种是用CHANGE MASTER TO MASTER_LOG_FILE..., MASTER_LOG_POS...直接跳到损坏事件之后一种是在从库上STOP SLAVE; SET GLOBAL sql_slave_skip_counter1; START SLAVE;跳过一个事件。后者只能跳事件级别跳不了单个事务大事务场景不够用。核对位点时一定要拿下游实际消费到的位置和文件里事件的真实位置对照不能凭感觉。CDC 程序一般在元数据表里存消费位点从库的位点在SHOW REPLICA STATUS里。拿这两个数去和mysqlbinlog输出里的# at N比对能立刻发现位点是不是正好卡在事件中间。卡在中间就是偏移量不对必须回退到上一个完整事件的起始位置。4. 三套修复方案与取舍4.1 应急跳过把卡住的事件绕过去业务等着恢复的时候跳过是最快的方案代价是这段时间的数据变更会丢失。适用条件是损坏范围明确、只涉及少量事务、丢失的数据可以接受或者能事后补偿。操作路径是这样的先用 3.2 的二分法精确定位到损坏事件的前一个完整事件的结束位置记下这个位点然后在从库上停掉同步用CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE..., SOURCE_LOG_POS...把位点指过去启动同步观察几分钟。如果这个坏点后面还有别的问题会很快再报错说明损坏范围比预期大得换方案。跳过的判断标准要写清楚丢的是哪张表、哪个时间段、大概多少行、业务能不能补。这些信息必须让业务方确认不能运维单方面决定。我吃过一次亏跳过一个看起来只涉及日志表的事务结果里面混着一条主表的状态变更业务侧对账差了三天才发现。CDC 程序侧的跳过逻辑不太一样一般是在消费位点元数据里直接改数值或者配置一个黑名单过滤掉特定的表或事件类型。改之前务必确认这个位点是不是会被其他消费者共用共用的话改一个会影响一片。4.2 重建从全量备份加增量重放数据不一致范围不明、或者损坏的是一大段连续事件跳过就不合适了得走重建。这条路慢但干净是最终兜底方案。流程分三步。第一步做全量用物理备份工具在从库或者新实例上恢复一份基准数据记录下备份对应的一致性位点GTID 或者 binlog 文件加偏移量。这一步的坑在于备份期间主库还在写如果备份工具不支持一致性快照恢复出来的数据本身就是花的后面重放多少增量都补不回来。第二步重放增量从备份位点开始把 binlog 事件重放到新实例上。这里要严格按事务边界重放遇到损坏事件直接报错停住手工确认后跳过。重放工具建议用原生复制而不是 mysqlbinlog 管道因为原生复制有重试和错误记录出问题好追溯。第三步校验用行数统计、校验和比对、关键业务表的抽样比对做三重验证。行数统计只能发现总量差异发现不了同量换位校验和比对要求两端表结构完全一致计算开销大抽样比对最实用按主键区间抽几百条比对关键字段。三种方法组合用能覆盖绝大多数不一致场景。重建的时间成本要提前估算。1TB 的库物理备份恢复加上几个小时的重放通常要 4 到 8 小时具体看 IO 和网络。这段时间业务侧要么接受延迟要么走双写过渡方案得提前和业务对齐。4.3 CDC 侧断点与脏数据处理如果链路是独立的 CDC 程序而不是原生复制处理思路要调整。这类程序的容错能力和原生复制不一样很多组件在遇到解析错误时默认行为是整体退出而不是跳过恢复后从上次提交的位点重来容易陷入“一启动就报错、报错就退出”的死循环。处理这类问题分两步。先修数据源把损坏的 binlog 段处理掉要么让上游重新生成要么在读取时过滤掉这一段。再修消费端把消费位点回退到一个确定完整的位置让程序从头开始解析这个位置之后的事件。回退量要给足退到损坏位置之前的最后一个事务边界宁可多解析一些重复事件也不能从半截开始。重复事件的处理是 CDC 程序的必修课。回退位点必然带来事件重放消费端如果没做幂等就会出现重复写。幂等的做法有两种按主键做 upsert 而不是 insert或者在消费端维护一个已处理位点的记录重复的直接丢弃。前者对删除操作不友好删除是幂等的重复删没问题但插删交错时有顺序问题后者需要额外的存储。我一般建议业务侧的表都带更新时间戳消费端按时间戳做条件更新天然幂等。脏数据的清理容易被漏掉。CDC 程序在崩溃前可能已经写了一部分数据到目标端回退重放时这部分数据会被再写一次。如果目标端是消息队列会多出重复消息如果是数据库可能触发唯一键冲突。清理动作要在位点回退之后、重放开始之前做不然重放会一直卡在冲突上。4.4 参数与规范的长期调整修完当下的问题还得防着下次。参数层面max_binlog_cache_size按最大事务体积的 1.5 倍设置这个数值要定期复核业务量涨了要跟着调。binlog_row_image如果同步链路不需要完整前镜像可以评估改成 MINIMALDELETE 事件只记主键体积能压下来一大截代价是下游拿不到删除前的其他字段值需要在业务侧确认。规范层面的动作更关键。批量操作必须分批任何DELETE或UPDATE都要带LIMIT每批控制在几千行批次之间 sleep 一小会儿给复制链路喘息时间。这条规范要写进代码评审的检查项靠人自觉迟早会出事。DDL 和批量 DML 要错开别在同一时间窗口里既改表结构又跑大批量清理两种操作叠加产生的 binlog 膨胀最难排查。监控也要补上。binlog 文件大小的增长速度、单事务 binlog 体积的最大值、复制延迟的突增、CDC 消费位点的停滞时长这四个指标建了告警大部分问题能在业务方发现之前暴露。其中单事务体积这个指标最好用直接对着max_binlog_cache_size设阈值到 70% 就告警留出处置时间。5. 常见问题速查与避坑5.1 典型报错对照表报错特征大概率原因优先动作Could not execute Delete_rows eventCant find record主从数据不一致目标行不存在比对两端表结构与数据检查是否发生过人工删数Could not execute Delete_rows event 表名乱码读取位点落在事件中间用 mysqlbinlog 回退到上一个完整事件起点Event crc check failed文件被截断或校验和配置不一致核对两端binlog_checksum再做文件校验Wrong event length文件末尾不完整确认磁盘空间定位最后一个完整事务Multi-statement transaction required more than max_binlog_cache_size单事务体积超限调大参数 业务侧拆批Client requested master to start replication from position file size位点越界用SHOW BINARY LOGS核对文件大小修正位点relay log read failurerelay log 损坏停止同步清空 relay log从备份位点重新拉取解析进程启动即退出无明确报错消费位点指向损坏段回退消费位点到已知完整位置这张表是我从历次故障里攒下来的遇到报错先对一遍能省掉大量猜测时间。表里没覆盖的情况按“先文件后执行、先上游后下游”的顺序查基本不会走偏。5.2 我踩过的几个坑坑一只看报错不看上下文。第一次遇到这条报错的时候我直接按“数据不一致”处理去目标端补了那条记录的删除结果重启同步后跑到同一个位点又报错折腾了三轮才想到去看文件本身。后来养成习惯报错出现的第一动作永远是跑一遍--verify-binlog-checksum三十秒的事能省几个小时。坑二跳过事件跳得太大。用sql_slave_skip_counter1跳过的时候跳的单位是“事件”不是“事务”。一个大事务由几十个事件组成跳一次根本不够跳多了又会把后面正常的事务也跳掉。这个参数在 ROW 格式加 GTID 的环境里尤其危险我的做法是能用位点就不用这个参数实在要用先把它背后到底会跳过哪些事件用 mysqlbinlog 验证一遍。坑三忽略字符集和排序规则的差异。有次执行侧报找不到记录查了半天数据确实在最后发现源端和目标端的表排序规则不一样utf8mb4_general_ci和utf8mb4_0900_ai_ci对某些字符的比对结果不同导致按字符串主键匹配失败。这类问题用常规的数据比对工具查不出来得盯SHOW CREATE TABLE的每一行。坑四以为调大参数就万事大吉。max_binlog_cache_size调大能解决写入失败但解决不了读取失败更解决不了执行失败。参数调整只是缓解症状根因是业务侧不加约束的批量操作。我现在的做法是参数调整和业务规范同步推进只调参数不改规范两三个月内必然复发。坑五在从库上直接做修复不记录。手工跳过位点、手工补数据这类操作做完一定要记录清楚什么时间、改了什么、为什么改、影响范围多大。我见过最惨的一次是半年前有人手工跳过一个事务没留记录半年后主从切换新主库缺了那批数据花了两天才定位到原因。变更记录这件事麻烦一时省心半年。坑六备份验证只看文件大小。重建方案里用了备份恢复完发现数据是花的因为备份工具在热备时没锁住一致性位点。验证备份不能只看文件生成成功要实际恢复一个实例出来跑一遍校验查询。备份的价值在于能恢复不在于能生成。坑七把 binlog 当永久归档。binlog 有保留期默认几天到十几天过期就清。遇到过下游消费停滞一周多回头去拉 binlog 发现文件已经没了只能走全量重建。链路上任何一方的消费延迟都要纳入监控延迟超过 binlog 保留期的一半就必须告警。5.3 一套可以直接抄的应急检查单真出事的时候人是慌的按清单走能避免遗漏。我把顺序固定下来确认业务影响范围哪些表、哪些功能受影响先给业务方一个初步判断保存现场把报错日志、SHOW REPLICA STATUS输出、相关 binlog 文件复制一份出来别在原文件上操作跑文件校验mysqlbinlog --verify-binlog-checksum确认文件完整性二分定位圈出损坏事件的精确位点区间核对参数max_binlog_cache_size、binlog_row_image、binlog_checksum两端是否一致判定方案损坏范围小走跳过范围大走重建中间地带先跳过保业务再排期重建执行修复每一步操作前记录当前位点方便回滚验证结果行数、关键字段抽样、下游消费位点跟上三项都过了才算完补充监控把这次的触发条件加成告警规则写复盘根因、处置过程、改进项三部分都要有改进项要落到人和时间。这套检查单不需要多高的技术含量价值在于防止慌乱中的误操作。第 2 步的保存现场尤其重要我见过直接在原文件上做截断操作的把本来还能救的数据彻底毁了。
凌晨被电话叫起来屏幕上就一行红字Could not execute Delete_rows event on table xxx.rundetails; 读取bin文件失败。业务侧的订单状态卡住不动了下游对账数据停在几个小时前主从延迟监控一路飙红。这条报错信息看着吓人其实它把两个不同层面的问题塞进了一句话里——前半截是事件执行阶段的失败后半截是文件读取阶段的失败。处理这类问题的关键是先判断到底坏在哪一层是 MySQL 的 binlog 文件本身被写坏了是下游解析器读到了半截事件还是从库回放时找不到对应行记录。这三个方向的排查手法、修复代价和风险等级完全不同搞混了顺序很容易在小问题上动大手术把本来只是同步位点跳一下的事情做成全量重建。这篇内容写给正在跟 MySQL 主从同步、binlog 订阅、变更数据捕获CDC打交道的人不管你用的是自研的 binlog 消费程序还是开源的解析组件只要你的链路上有“读 binlog 事件”这一步这套排查思路就能直接套用。文中涉及的库表名我统一做了脱敏命令和参数可以照抄但动手之前请务必先在从库或测试环境验证一遍。1. 先把这条报错拆成两半来看1.1 报错文本里的两个独立故障点Could not execute Delete_rows event on table xxx.rundetails这半句描述的是事件已经读出来了但执行不下去。ROW 格式下一条 Delete_rows 事件里装的是被删记录的“前镜像”before image也就是删除之前那一行的完整字段值。执行方拿到这份前镜像要去目标端把对应的行找出来删掉。找不到或者字段对不上就会报这个错。它的本质是数据不一致不是文件坏了。读取bin文件失败这半句描述的是事件还没读出来IO 层就出问题了。可能是文件被截断、校验和失败、offset 越界也可能是读取方把位点定位到了一个事件的中间位置从一个畸形偏移开始解析自然读出一堆乱码。它的本质是文件或位点损坏。这两件事经常同时出现是因为它们往往来自同一个根因一个超大事务把 binlog cache 撑爆了事务在写 binlog 的中途被中断文件里留下了一段残缺的事件序列。残留下游读的时候先报读取失败跳过这段又撞上了执行失败。所以看到这条报错别急着单独处理某一半先把整条链路的因果串起来。提示如果报错里同时出现Error_code: 1032和Cant find record那基本可以确定是执行侧的行匹配失败优先往数据一致性方向查不要一上来就怀疑文件损坏。1.2 Delete_rows 为什么格外容易出事同样是行事件Update_rows 和 Write_rows 出问题的概率明显低于 Delete_rows。原因不复杂删除操作依赖前镜像做精确定位而前镜像的完整性直接决定了能不能找到目标行。如果表结构在同步链路的两端不一致——比如源端加过列、改过字段类型、换过字符集或者两端的主键定义有细微差异——前镜像里的字段和目标端对不上匹配就会失败。另一个高发场景是大批量删除。业务上做数据清理、归档、批量撤销时一条 SQL 删掉几十万行ROW 格式下就会生成一个体积巨大的 Delete_rows 事件序列。这种事件在传输、缓存、解析三个环节都容易踩坑缓存不够会被截断网络缓冲不够会被拆包拆错解析端内存不够会 OOM。我见过最典型的一次是一条DELETE FROM xxx.rundetails WHERE create_time ...一次性干掉了两百多万行binlog 单文件直接跳到下一个编号下游解析到一半就报读取失败。还有一种更隐蔽的情况没有主键或唯一索引的表。这种表上的删除前镜像定位只能靠全字段比对一旦有字段是浮点数、时间戳或者大文本精度和编码的微小差异都会让匹配失败。所以凡是进同步链路的表主键这件事没有商量余地。1.3 一条最典型的故障链复盘把常见现场还原一下某业务系统有一张明细表rundetails按时间做定期清理。某天清理任务的时间范围写错了一次性删了几百万行。这个事务产生的 binlog 体积远超max_binlog_cache_size的限制事务在写 binlog 的过程中被中止。binlog 文件里留下了一个不完整的事务——事件头写了事件体没写完checksum 自然对不上。下游的解析程序按位点顺序读读到这个位置先是校验和不匹配报了读取失败运维同学为了尽快恢复手工把位点往前跳了一段跳到了一个 Delete_rows 事件的中间解析器从畸形偏移开始解码解出来的表名、列数全是乱的于是又报了“无法在表上执行 Delete_rows 事件”。两个报错前后脚出现看起来像是两个问题其实是同一个根因的两次表现。这条链路告诉我们一个判断原则先确认 binlog 文件本身是否完整再谈执行失败。文件都不完整讨论事件执行毫无意义文件完整而执行失败才轮到数据一致性排查。2. binlog 文件结构读懂“读取失败”卡在哪2.1 一个事件由哪几部分组成binlog 文件不是纯文本它是一串二进制事件的顺序拼接。每个事件由三块构成公共头event header19 字节、事件体event body长度不定、校验和checksum4 字节开启binlog_checksumCRC32时存在。公共头里最关键的是四个字段时间戳、事件类型、服务器 ID、事件长度。事件长度这个字段决定了读取方要往后读多少字节如果它和实际剩余字节数对不上读取就会越界。理解这一点非常重要因为绝大多数“读取失败”都是事件长度字段和实际文件长度不匹配造成的。文件被截断时最后一个事件的长度字段还老老实实写着“我要 5000 字节”但文件里只剩 2000 字节读取方读到 2000 字节就到文件末尾了校验和算不出来直接报错。事件体内部的结构又因类型而异。Delete_rows 事件体里包含表 ID、标志位、列数、列位图然后是若干行记录每行记录前面还有一个行标记字节。这个结构是严格按位排列的中间任何一个字节错位后面的解析全盘皆输。所以“从中间某个偏移开始读”这种操作在 binlog 上是绝对行不通的必须从事件的起始位置对齐。2.2 checksum 与截断两种不同性质的“坏”文件层面的问题分两类处理方式完全不同。第一类是逻辑损坏通常是文件被意外截断。磁盘写满、进程被杀、文件系统异常、拷贝过程中断都会造成这种结果。特征是文件大小小于预期最后一个事件的长度字段指向文件之外。这类损坏用mysqlbinlog --verify-binlog-checksum一扫就能确认报错信息一般是Event crc check failed或者Wrong event length。第二类是物理损坏文件大小正常中间某些字节被改写了。这种相对少见多发生在存储介质异常或者被其他进程误写的场景。特征是按位点读的时候在某个固定位置稳定报同一个错用mysqlbinlog --start-position精确跳过去还是错。区分这两类的意义在于逻辑损坏可以靠跳位点绕过物理损坏必须放弃这段文件。逻辑损坏往往只影响文件末尾前面的数据是好的物理损坏的位置不可预测继续用这段文件重放风险无法评估。另外要提醒一句binlog_checksum这个参数在链路两端必须一致。源端开了 CRC32下游解析器却按无校验和的格式去读每读一个事件都会错位四个字节表现出来就是“读什么都是乱的”。这类配置问题排查起来最费时间因为报错信息完全一样只是文件本身一点毛病都没有。2.3 为什么坏点常常落在事务中间理论上一个事务的所有事件应该原子地写入 binlog。但实际实现里事务提交时是把整个事务的 binlog 先写到 binlog cache再一次性刷到文件。这个“一次性”的前提是 cache 装得下。装不下的时候MySQL 会报Multi-statement transaction required more than max_binlog_cache_size bytes of storage事务回滚但已经写下去的部分不会自动清理。这就是坏点落在事务中间的原因。文件里出现了一个有 BEGIN 却没有 COMMIT 的事件序列或者一个 Delete_rows 事件头写了但行数据只写了一半。这种残缺事务在文件里是“合法”存在的——每个单独事件的长度字段和校验和可能都是对的只是语义上不完整。读取方如果只看单个事件的完整性是发现不了的只有在尝试执行或者做事务级校验时才会暴露。排查这类问题的有效手段是按事务边界切分验证。用mysqlbinlog加--start-datetime和--stop-datetime把时间窗口缩到最小逐段输出看哪一段的输出在中途戛然而止。正常的事务输出一定是 BEGIN 开头、COMMIT 结尾中间有缺口就说明被截断了。3. 现场定位的实操步骤3.1 第一步分清是主库坏了、从库坏了还是解析器坏了这一步决定了后续所有动作的方向千万不要跳。我习惯用三个问题快速定位第一个问题主库上这个 binlog 文件本身能正常读吗在主库上执行mysqlbinlog --verify-binlog-checksum --base64-outputdecode-rows -vv /path/to/mysql-bin.000123 /tmp/out.txt看退出码和报错。能完整输出且无报错说明源文件是好的问题在下游。第二个问题从库的 IO 线程和 SQL 线程分别是什么状态执行SHOW REPLICA STATUS\G老版本用SHOW SLAVE STATUS\G重点看Replica_IO_Running、Replica_SQL_Running、Last_IO_Error、Last_SQL_Error、Relay_Log_File、Relay_Log_Pos。如果 IO 线程正常但 SQL 线程停了报的又是 1032那是执行侧的数据不一致文件没问题。如果 IO 线程就停了报的是读取错误那才轮到文件层面。第三个问题如果是独立的 CDC 解析程序它读的是主库的 binlog 还是从库的 relay log读主库 binlog 出问题查主库文件和位点读 relay log 出问题先确认这个 relay log 是不是从主库完整拉取的。我遇到过一次从库的relay_log_purge开着IO 线程还在写、SQL 线程还没消费完文件就被清理了SQL 线程再去读就是“文件不存在”。三个问题的答案组合起来基本能锁定故障层。定位不清就动手最常见的错误是把从库的数据不一致当成文件损坏去重建白折腾好几个小时。3.2 用 mysqlbinlog 做分段验证确认要查文件之后mysqlbinlog是唯一靠谱的工具。几个常用组合我整理在下面# 1. 全文件校验看有没有 checksum 失败或长度异常 mysqlbinlog --verify-binlog-checksum /var/lib/mysql/mysql-bin.000123 /dev/null # 2. 只输出指定位置区间的事件用于精确定位坏点 mysqlbinlog --start-position4 --stop-position1048576 \ --base64-outputdecode-rows -vv /var/lib/mysql/mysql-bin.000123 # 3. 按时间窗口切分适合不知道具体位点的场景 mysqlbinlog --start-datetime2024-05-20 02:00:00 \ --stop-datetime2024-05-20 02:10:00 \ --base64-outputdecode-rows -vv /var/lib/mysql/mysql-bin.000123 # 4. 只看事务边界快速判断有没有 BEGIN/COMMIT 不成对 mysqlbinlog --base64-outputdecode-rows -vv /var/lib/mysql/mysql-bin.000123 \ | grep -E ^(BEGIN|COMMIT|# at) | head -100二分法是这里最好用的技巧。文件 1GB 报错先用--stop-position524288000试前半段不报错就把--start-position挪到 524288000 试后半段报错就继续二分。通常在五六轮之内就能把坏点缩到几 KB 的范围再精确到具体事件。这个方法比从头扫一遍快得多尤其是文件放在慢盘上的时候。输出的内容里要重点看三样东西# at N后面的位点是否连续、每个事务的 BEGIN 和 COMMIT 是否成对、Delete_rows 事件里的表名和列数是否正常。表名出现乱码说明偏移错了列数是零或者异常大说明事件体被截断BEGIN 后面直接跟下一个 BEGIN说明中间的事务被吃掉了。注意带-vv参数会输出伪 SQL遇到大字段BLOB、TEXT时输出体积会爆炸重定向到文件时记得挂个| head -c 50000000之类的保护别把磁盘撑爆。另外--base64-outputdecode-rows不能省否则 ROW 事件只输出 BASE64 编码看不出来是什么操作。3.3 核查事务体积与缓存参数定位到坏点之后下一步是搞清楚为什么会坏。绝大多数情况下答案是大事务撞上了缓存上限。需要核对的参数有这几个参数作用常见默认值建议值max_binlog_cache_size单个事务可用的 binlog cache 上限5.7 极大值近似不限8.0 为 4GB按最大事务体积的 1.5 倍设一般 2GB 到 8GBbinlog_row_imageROW 格式下记录哪些列FULL同步链路可评估改 MINIMALbinlog_transaction_compression是否压缩事务OFF8.0.20 以上可开 ONmax_allowed_packet单个网络包上限64MB大事务场景要同步调大binlog_format日志格式ROW保持 ROW估算最大事务体积有个简单公式影响行数 × 单行 binlog 记录大小。单行记录大小约等于行内各列的实际字节数之和再加上每行十几字节的元信息开销。举个例子一张有 30 个字段、平均行宽 300 字节的表一次删 300 万行产生的 binlog 约 300 万 × 300 字节 ≈ 900MB加上前镜像和事务开销实际可能到 1.2GB 以上。如果max_binlog_cache_size只设了 512MB这个事务必然被中止。反过来算也很有用想知道能安全承受多大的事务就拿当前 cache 上限除以单行记录大小。cache 设 2GB、单行 300 字节理论上限大约 700 万行但实际留 30% 余量更稳妥按 500 万行控制。这个数字应该写进数据清理任务的规范里批次大小不允许超过它。这里有个容易被忽略的细节max_binlog_cache_size是会话级参数改全局只影响新连接。而且它只限制事务缓存不限制单个事件的大小。所以调整它解决的是“事务太大写不进去”不是“单个事件太大读不出来”。后者要靠控制单条 SQL 的影响行数来解决方向不同。3.4 位点与 GTID 的核对方法跳过损坏事件之前必须把位点算准。这里有两套坐标系用哪种取决于你的环境开没开 GTID。开 GTID 的环境位点用Executed_Gtid_Set表示。从库的Retrieved_Gtid_Set是从主库拉到了哪些事务Executed_Gtid_Set是执行完成了哪些。两者差集就是还没执行的事务。跳过某个事务就是把这个 GTID 手工塞进gtid_executed里命令是SET GTID_NEXTxxxx:nnn; BEGIN; COMMIT; SET GTID_NEXTAUTOMATIC;。这套操作看起来简单但顺序错了会造成 GTID 空洞后续主从切换时会出大问题务必在测试环境先演练。没开 GTID 的环境位点就是 binlog 文件名加偏移量。跳过的方法有两种一种是用CHANGE MASTER TO MASTER_LOG_FILE..., MASTER_LOG_POS...直接跳到损坏事件之后一种是在从库上STOP SLAVE; SET GLOBAL sql_slave_skip_counter1; START SLAVE;跳过一个事件。后者只能跳事件级别跳不了单个事务大事务场景不够用。核对位点时一定要拿下游实际消费到的位置和文件里事件的真实位置对照不能凭感觉。CDC 程序一般在元数据表里存消费位点从库的位点在SHOW REPLICA STATUS里。拿这两个数去和mysqlbinlog输出里的# at N比对能立刻发现位点是不是正好卡在事件中间。卡在中间就是偏移量不对必须回退到上一个完整事件的起始位置。4. 三套修复方案与取舍4.1 应急跳过把卡住的事件绕过去业务等着恢复的时候跳过是最快的方案代价是这段时间的数据变更会丢失。适用条件是损坏范围明确、只涉及少量事务、丢失的数据可以接受或者能事后补偿。操作路径是这样的先用 3.2 的二分法精确定位到损坏事件的前一个完整事件的结束位置记下这个位点然后在从库上停掉同步用CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE..., SOURCE_LOG_POS...把位点指过去启动同步观察几分钟。如果这个坏点后面还有别的问题会很快再报错说明损坏范围比预期大得换方案。跳过的判断标准要写清楚丢的是哪张表、哪个时间段、大概多少行、业务能不能补。这些信息必须让业务方确认不能运维单方面决定。我吃过一次亏跳过一个看起来只涉及日志表的事务结果里面混着一条主表的状态变更业务侧对账差了三天才发现。CDC 程序侧的跳过逻辑不太一样一般是在消费位点元数据里直接改数值或者配置一个黑名单过滤掉特定的表或事件类型。改之前务必确认这个位点是不是会被其他消费者共用共用的话改一个会影响一片。4.2 重建从全量备份加增量重放数据不一致范围不明、或者损坏的是一大段连续事件跳过就不合适了得走重建。这条路慢但干净是最终兜底方案。流程分三步。第一步做全量用物理备份工具在从库或者新实例上恢复一份基准数据记录下备份对应的一致性位点GTID 或者 binlog 文件加偏移量。这一步的坑在于备份期间主库还在写如果备份工具不支持一致性快照恢复出来的数据本身就是花的后面重放多少增量都补不回来。第二步重放增量从备份位点开始把 binlog 事件重放到新实例上。这里要严格按事务边界重放遇到损坏事件直接报错停住手工确认后跳过。重放工具建议用原生复制而不是 mysqlbinlog 管道因为原生复制有重试和错误记录出问题好追溯。第三步校验用行数统计、校验和比对、关键业务表的抽样比对做三重验证。行数统计只能发现总量差异发现不了同量换位校验和比对要求两端表结构完全一致计算开销大抽样比对最实用按主键区间抽几百条比对关键字段。三种方法组合用能覆盖绝大多数不一致场景。重建的时间成本要提前估算。1TB 的库物理备份恢复加上几个小时的重放通常要 4 到 8 小时具体看 IO 和网络。这段时间业务侧要么接受延迟要么走双写过渡方案得提前和业务对齐。4.3 CDC 侧断点与脏数据处理如果链路是独立的 CDC 程序而不是原生复制处理思路要调整。这类程序的容错能力和原生复制不一样很多组件在遇到解析错误时默认行为是整体退出而不是跳过恢复后从上次提交的位点重来容易陷入“一启动就报错、报错就退出”的死循环。处理这类问题分两步。先修数据源把损坏的 binlog 段处理掉要么让上游重新生成要么在读取时过滤掉这一段。再修消费端把消费位点回退到一个确定完整的位置让程序从头开始解析这个位置之后的事件。回退量要给足退到损坏位置之前的最后一个事务边界宁可多解析一些重复事件也不能从半截开始。重复事件的处理是 CDC 程序的必修课。回退位点必然带来事件重放消费端如果没做幂等就会出现重复写。幂等的做法有两种按主键做 upsert 而不是 insert或者在消费端维护一个已处理位点的记录重复的直接丢弃。前者对删除操作不友好删除是幂等的重复删没问题但插删交错时有顺序问题后者需要额外的存储。我一般建议业务侧的表都带更新时间戳消费端按时间戳做条件更新天然幂等。脏数据的清理容易被漏掉。CDC 程序在崩溃前可能已经写了一部分数据到目标端回退重放时这部分数据会被再写一次。如果目标端是消息队列会多出重复消息如果是数据库可能触发唯一键冲突。清理动作要在位点回退之后、重放开始之前做不然重放会一直卡在冲突上。4.4 参数与规范的长期调整修完当下的问题还得防着下次。参数层面max_binlog_cache_size按最大事务体积的 1.5 倍设置这个数值要定期复核业务量涨了要跟着调。binlog_row_image如果同步链路不需要完整前镜像可以评估改成 MINIMALDELETE 事件只记主键体积能压下来一大截代价是下游拿不到删除前的其他字段值需要在业务侧确认。规范层面的动作更关键。批量操作必须分批任何DELETE或UPDATE都要带LIMIT每批控制在几千行批次之间 sleep 一小会儿给复制链路喘息时间。这条规范要写进代码评审的检查项靠人自觉迟早会出事。DDL 和批量 DML 要错开别在同一时间窗口里既改表结构又跑大批量清理两种操作叠加产生的 binlog 膨胀最难排查。监控也要补上。binlog 文件大小的增长速度、单事务 binlog 体积的最大值、复制延迟的突增、CDC 消费位点的停滞时长这四个指标建了告警大部分问题能在业务方发现之前暴露。其中单事务体积这个指标最好用直接对着max_binlog_cache_size设阈值到 70% 就告警留出处置时间。5. 常见问题速查与避坑5.1 典型报错对照表报错特征大概率原因优先动作Could not execute Delete_rows eventCant find record主从数据不一致目标行不存在比对两端表结构与数据检查是否发生过人工删数Could not execute Delete_rows event 表名乱码读取位点落在事件中间用 mysqlbinlog 回退到上一个完整事件起点Event crc check failed文件被截断或校验和配置不一致核对两端binlog_checksum再做文件校验Wrong event length文件末尾不完整确认磁盘空间定位最后一个完整事务Multi-statement transaction required more than max_binlog_cache_size单事务体积超限调大参数 业务侧拆批Client requested master to start replication from position file size位点越界用SHOW BINARY LOGS核对文件大小修正位点relay log read failurerelay log 损坏停止同步清空 relay log从备份位点重新拉取解析进程启动即退出无明确报错消费位点指向损坏段回退消费位点到已知完整位置这张表是我从历次故障里攒下来的遇到报错先对一遍能省掉大量猜测时间。表里没覆盖的情况按“先文件后执行、先上游后下游”的顺序查基本不会走偏。5.2 我踩过的几个坑坑一只看报错不看上下文。第一次遇到这条报错的时候我直接按“数据不一致”处理去目标端补了那条记录的删除结果重启同步后跑到同一个位点又报错折腾了三轮才想到去看文件本身。后来养成习惯报错出现的第一动作永远是跑一遍--verify-binlog-checksum三十秒的事能省几个小时。坑二跳过事件跳得太大。用sql_slave_skip_counter1跳过的时候跳的单位是“事件”不是“事务”。一个大事务由几十个事件组成跳一次根本不够跳多了又会把后面正常的事务也跳掉。这个参数在 ROW 格式加 GTID 的环境里尤其危险我的做法是能用位点就不用这个参数实在要用先把它背后到底会跳过哪些事件用 mysqlbinlog 验证一遍。坑三忽略字符集和排序规则的差异。有次执行侧报找不到记录查了半天数据确实在最后发现源端和目标端的表排序规则不一样utf8mb4_general_ci和utf8mb4_0900_ai_ci对某些字符的比对结果不同导致按字符串主键匹配失败。这类问题用常规的数据比对工具查不出来得盯SHOW CREATE TABLE的每一行。坑四以为调大参数就万事大吉。max_binlog_cache_size调大能解决写入失败但解决不了读取失败更解决不了执行失败。参数调整只是缓解症状根因是业务侧不加约束的批量操作。我现在的做法是参数调整和业务规范同步推进只调参数不改规范两三个月内必然复发。坑五在从库上直接做修复不记录。手工跳过位点、手工补数据这类操作做完一定要记录清楚什么时间、改了什么、为什么改、影响范围多大。我见过最惨的一次是半年前有人手工跳过一个事务没留记录半年后主从切换新主库缺了那批数据花了两天才定位到原因。变更记录这件事麻烦一时省心半年。坑六备份验证只看文件大小。重建方案里用了备份恢复完发现数据是花的因为备份工具在热备时没锁住一致性位点。验证备份不能只看文件生成成功要实际恢复一个实例出来跑一遍校验查询。备份的价值在于能恢复不在于能生成。坑七把 binlog 当永久归档。binlog 有保留期默认几天到十几天过期就清。遇到过下游消费停滞一周多回头去拉 binlog 发现文件已经没了只能走全量重建。链路上任何一方的消费延迟都要纳入监控延迟超过 binlog 保留期的一半就必须告警。5.3 一套可以直接抄的应急检查单真出事的时候人是慌的按清单走能避免遗漏。我把顺序固定下来确认业务影响范围哪些表、哪些功能受影响先给业务方一个初步判断保存现场把报错日志、SHOW REPLICA STATUS输出、相关 binlog 文件复制一份出来别在原文件上操作跑文件校验mysqlbinlog --verify-binlog-checksum确认文件完整性二分定位圈出损坏事件的精确位点区间核对参数max_binlog_cache_size、binlog_row_image、binlog_checksum两端是否一致判定方案损坏范围小走跳过范围大走重建中间地带先跳过保业务再排期重建执行修复每一步操作前记录当前位点方便回滚验证结果行数、关键字段抽样、下游消费位点跟上三项都过了才算完补充监控把这次的触发条件加成告警规则写复盘根因、处置过程、改进项三部分都要有改进项要落到人和时间。这套检查单不需要多高的技术含量价值在于防止慌乱中的误操作。第 2 步的保存现场尤其重要我见过直接在原文件上做截断操作的把本来还能救的数据彻底毁了。
