如何排查MySQL主从复制过程中发生的1032数据丢失错误？-mysql教程-PHP中文网

1032错误需定位具体丢失行：从show slave status中提取master_log_file与read_master_log_pos，用mysqlbinlog解析对应binlog位置，找到delete/update的where条件（如@1=12345），在主库验证后导出该行数据，从库set sql_log_bin=0导入，再跳过当前事件恢复同步。

如何排查mysql主从复制过程中发生的1032数据丢失错误？

1032错误不是日志坏了，而是从库真没那条数据——必须定位到具体哪一行、在哪条binlog里丢了，才能修复。

怎么从`Last_Error`里挖出关键定位信息

只看Last_Error: Can't find record in 'db.t'毫无用处。真正要抓的是：Master_Log_File: mysql-bin.000013 和 Read_Master_Log_Pos: 440267874（或end_log_pos 440267874）。这两个值共同锁定了出错的binlog文件和精确位置。

别信Relay_Master_Log_File和Exec_Master_Log_Pos——它们可能已滞后，得用Master_Log_File + Read_Master_Log_Pos
如果启用了GTID，Retrieved_Gtid_Set末尾那个事务号才是真实执行位点，Read_Master_Log_Pos可能不准
在GTID模式下，SHOW SLAVE STATUS\G里Auto_Position: 1表示走GTID同步，此时跳过事务必须用SET GTID_NEXT方式，不能用SQL_SLAVE_SKIP_COUNTER

如何用`mysqlbinlog`反查丢失行的WHERE条件

拿到mysql-bin.000013和end_log_pos 440267874后，在主库上执行：

mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000013 | grep -A 20 "end_log_pos 440267874"

输出中找以### DELETE FROM或### UPDATE开头的行，后面跟着类似WHERE @1=12345 AND @2='xxx'的内容——这就是从库缺失记录的完整定位条件。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

@1通常对应表的第一列（很可能是主键），但不绝对；必须结合SHOW CREATE TABLE确认字段顺序
如果表没有主键，@1~@N是整行所有字段的镜像，WHERE条件会非常长，且容易因字段值微小差异（如JSON空格、datetime毫秒）导致匹配失败
--base64-output=DECODE-ROWS必须加，否则看到的是BASE64编码，无法人工识别条件

为什么导出再导入时`SET SQL_LOG_BIN = 0`不能省

在从库导入缺失数据前，必须执行SET SQL_LOG_BIN = 0（GTID模式下强制要求），否则这条INSERT会被记入从库binlog，并同步回主库，引发主键冲突或循环写入。

非GTID模式下，SQL_LOG_BIN关闭后导入的数据不会进入binlog，但需确保binlog_format = ROW（否则可能被忽略）
导入命令必须用mysql db_name ，不能用<code>source，否则SQL_LOG_BIN = 0对source无效
如果从库开了slave_exec_mode = IDEMPOTENT，UPDATE/DELETE失败会自动转为INSERT，但仅适用于测试环境，生产慎用

补完数据后为什么`START SLAVE`还是卡住

补数据只是解决了“行不存在”，但SQL线程仍停在原错误位置，必须手动推进一次事件才能继续执行后续binlog。

先确认该行已在从库存在：SELECT * FROM db.t WHERE id = 12345（务必用实际条件）
执行STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;——这是最通用做法
GTID模式下必须改用：STOP SLAVE; SET @@SESSION.GTID_NEXT = 'xxx:yyy'; BEGIN; COMMIT; SET SESSION GTID_NEXT = AUTOMATIC; START SLAVE;
推进后立刻检查Seconds_Behind_Master是否开始下降，而不是只看Slave_SQL_Running: Yes

最容易被跳过的动作是：补完数据后只验证主键存在，却没比对整行字段值。时间戳精度、JSON格式、TEXT末尾换行符这些肉眼难辨的差异，会在下一次UPDATE时再次触发1032——必须在主从库分别执行SELECT * FROM db.t WHERE id = 12345，逐字段比对。