Error 1032 是从库执行 UPDATE/DELETE 时找不到对应行，需根据 SHOW SLAVE STATUS 中 Master_Log_File 和 Read_Master_Log_Pos 定位主库 binlog 精确位置，用 mysqlbinlog 解析出 WHERE 条件后补数据，并 SET SQL_LOG_BIN = 0 导入，再 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 推进复制。
Error 1032 不是日志解析失败，而是从库执行 UPDATE 或 DELETE 时，根本查不到那行数据——必须补上缺失记录，否则跳过一次，下次同条件操作还会卡住。
怎么从 SHOW SLAVE STATUS 定位到具体哪条 binlog 事件
只看 Last_Error: Can't find record in 't' 没用，关键字段是：Master_Log_File 和 Read_Master_Log_Pos（不是 Exec_Master_Log_Pos）。这两个值共同指向主库 binlog 中出错事务的精确坐标。
常见误区：
- 误用
Relay_Master_Log_File+Exec_Master_Log_Pos：它们反映的是已执行到的位置，可能已滞后，无法定位当前卡点 - GTID 模式下仍硬套
SQL_SLAVE_SKIP_COUNTER：如果Auto_Position: 1，跳过必须用SET GTID_NEXT，否则会报错或跳错事务 - 没确认
datadir路径就直接拼/var/lib/mysql/mysql-bin.000013：先执行SHOW VARIABLES LIKE 'datadir'，再拼完整路径
如何用 mysqlbinlog 解析出缺失行的 WHERE 条件
拿到 Master_Log_File 和 Read_Master_Log_Pos 后，在主库运行：
mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /path/to/mysql-bin.000013 | grep -A 20 "end_log_pos 440267874"
输出里找以 ### DELETE FROM 或 ### UPDATE 开头的行，后面跟着类似 WHERE @1=12345 AND @2='xxx' 的内容——这就是从库缺失记录的完整定位条件。
注意点：
- 必须加
--base64-output=DECODE-ROWS，否则看到的是 BASE64 编码，无法人工识别 -
@1对应表的第一列，但不一定是主键；得用SHOW CREATE TABLE db.t确认字段顺序和类型 - 无主键表的 WHERE 条件极长，且容易因 JSON 空格、datetime 毫秒等微小差异导致匹配失败
- 如果
grep没结果，优先扩大-A 50范围，再检查 binlog 是否已被 rotate
补数据前必须验证并关闭 binlog 写入
拿到 @1=12345 后，不能直接导出导入。先在主库验证是否存在：
SELECT * FROM db.t WHERE id = 12345;
只有存在才继续。接着导出：
mysqldump --no-create-info --skip-triggers --where="id=12345" db t > missing_row.sql
传到从库后，执行前必须加：
SET SQL_LOG_BIN = 0;
原因很实际：
- GTID 模式下强制要求，否则这条
INSERT会被记入从库 binlog，再同步回主库，引发主键冲突或死循环 - 非 GTID 模式下虽不强制，但若
binlog_format = STATEMENT，SQL_LOG_BIN = 0可能被忽略，务必确认是ROW格式 - 别用
INSERT ... SELECT直插：网络中断会导致半截数据，破坏一致性
补完数据后 SQL thread 仍卡着，必须手动推进
补数据 ≠ 复制自动恢复。SQL thread 还停在原地，得手动跳过当前事件：
STOP SLAVE;<br>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;<br>START SLAVE;
然后立刻检查：
Slave_SQL_Running: Yes-
Seconds_Behind_Master开始下降
如果仍报 1032，说明不止一行缺失——大概率是某张表批量漏同步，建议立刻跑 pt-table-checksum 全量校验。另外，SQL_LOG_BIN = 0 导入的数据不会出现在从库 binlog 中，后续无法靠 binlog 回溯，所以补完后最好查主库 binlog 或业务操作日志，确认漏同步的范围和原因。
