MySQL主从复制异常排查与常见原因解析

今天处理了一个典型的主从复制中断案例，SQL线程报错1032。遇到这种情况，先别急着跳过事务——这很可能是MySQL 8.0并行复制与无主键表共同埋下的一个“暗雷”。下面咱们就顺着这条线索，从Binlog机制到Hash冲突，把这个问题彻底讲清楚。

主从复制异常是运维和面试中的常客，而触发异常的场景五花八门。今天遇到的这个，就特别有代表性。

一、异常现象

监控突然告警，提示从库SQL线程停止。执行SHOW SLA VE STATUS，一眼就看到了关键报错：

Worker 1 failed executing transaction ...
Could not execute Update_rows_v1 event on table testdb.tb1;
Can't find record in 'tb1', Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND

典型的1032错误，意思是主库发来一条更新指令，但从库在目标表里怎么也找不到对应的记录。

很多DBA的第一反应是：“数据不一致了，跳过这个事务就行。” 但先别急。如果只是简单地用sql_sla ve_skip_counter跳过，很可能只是掩盖了问题。更值得留意的是，报错的是Worker 1，这说明从库开启了并行复制。在MySQL 8.0的环境里，再结合“无主键表”这个特征，背后往往藏着一个更深层的机制问题。

二、为什么会找不到记录？

1032错误的字面意思虽然是“找不到记录”，但在MySQL 8.0的并行复制场景下，原因远比“数据被误删”要复杂。

1. 直接原因：数据不一致

最直接的可能性，确实是主从数据已经不同步了。比如有人误操作在从库执行了DELETE，或者之前某个事务同步失败，导致这行数据在从库缺失。当主库的UPDATE事件传来时，从库拿着Binlog里记录的“更新前镜像”去表里匹配，自然查无此人。

2. 根本原因：无主键表的“大海捞针”

问题的核心在于，报错的表tb1没有主键。主键是数据库快速、准确定位一行数据的“身份证”。没有它，从库在重放数据变更时，就不得不进行低效且不可靠的“全表扫描”。

在binlog_format=ROW模式下，Binlog会记录行变更的完整前后镜像。

• 有主键时：从库直接通过主键索引定位行，精准又快速。
• 无主键时：从库被迫进行全表扫描，逐行比对所有字段，试图找到与Binlog中“旧值”完全一致的那一行。这个过程不仅慢，在并发环境下还极易出错。

3. 隐形杀手：MySQL 8.0的Hash Scan算法缺陷

这里就涉及到MySQL 8.0的一个“性能优化”带来的副作用。为了改善无主键表在并行复制下的全表扫描性能，MySQL 8.0引入了HASH_SCAN算法。

它的机制是计算表中每一行数据的CRC32校验和，建立哈希映射来加速定位。但风险也随之而来：如果表数据量大且没有主键，就极易发生哈希冲突——即不同的数据算出了相同的CRC32值。一旦冲突，从库的SQL线程就可能“认错行”，要么匹配错误导致误删误改，要么直接判定找不到行，从而抛出1032错误。

三、Binlog参数：是敌是友？

排查时，大家常会问：这和Binlog参数设置有关吗？关系很大。

几个关键参数需要厘清：

• binlog_format=ROW：这常常是“案发现场”的设置，但 ironically，它也是官方推荐的最佳实践。虽然STATEMENT格式不会报1032（因为它重放的是SQL语句），但它更容易导致主从不一致。ROW格式记录了数据的物理变化，对于无主键表，它要求从库必须能精确匹配所有列的值，从而暴露了结构缺陷。
• sla ve_exec_mode：这是一个可以“救火”的参数。默认是STRICT（严格模式），遇到1032就报错。在紧急修复时，可以将其临时设置为IDEMPOTENT（幂等模式）。在该模式下，从库会自动忽略1032（找不到行）和1062（主键冲突）错误。但要注意，这只是在掩盖问题，可能导致从库数据永久性缺失。
• sla ve_parallel_workers：并行复制本身是提升性能的好功能，但它会加剧无主键表的问题。多个Worker线程同时扫描无主键表，不仅消耗巨大资源，还进一步增加了Hash冲突的概率。不过，这并不意味着要关闭它，根源还是在于表结构。

四、如何优雅地填坑？

遇到这种问题，别慌，按照以下步骤来应对：

1. 临时止血（恢复业务）

如果业务不能停，可以先临时恢复同步。

-- 方法A：开启幂等模式（仅建议在 ROW 格式下临时使用）
SET GLOBAL sla ve_exec_mode = 'IDEMPOTENT';
START SLA VE;

-- 方法B：如果是 GTID 模式，精准跳过该事务
STOP SLA VE;
SET GTID_NEXT='1ce64ba5-716d-11ef-8a7f-fa163eeec86c:1196639450';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLA VE;

2. 定位问题

首先确认报错的表是否真的没有主键。

SHOW CREATE TABLE testdb.tb1;

同时，去主库确认一下那条记录是否真实存在，排除单纯的数据不一致可能。

3. 根治方案

答案其实很简单，就一句话：给表加上主键！ 这是解决此类问题的唯一长久之计。

• 方案A（推荐）：添加业务主键或自增主键。

  ALTER TABLE testdb.tb1 ADD COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY;

• 方案B（MySQL 8.0.30+特性）：如果实在不想改动现有表结构，可以尝试开启“不可见主键”功能（通过设置sql_generate_invisible_primary_key=ON），MySQL会自动为无主键表生成一个隐藏的row_id。但需要提醒的是，这个功能在生产环境曾出现过一些问题，使用需谨慎。

4. 数据修复

在加上主键之后，建议重建从库，或者使用pt-table-sync这类工具进行主从数据一致性修复，确保从库不再因为“找不到行”而报错。

五、总结

MySQL 8.0的并行复制大幅提升了性能，但也对基础架构的设计提出了更高要求。1032错误不仅仅是一个数据不一致的信号，更是一个强烈的表结构缺陷警报。在MySQL 8.0中，无主键表几乎就是并行复制链路中的一颗“定时冲击波”。定期检查并清理数据库中的所有无主键表，这或许正是一名DBA专业素养的体现。