MySQL主从同步报错1062怎么解决？使用set global sql_slave_skip_counter跳过错误可行吗

MySQL主从同步报错1062通常表示从库在执行中继日志中的事件时，遇到了主键或唯一键重复的记录，导致复制SQL线程中断。这个问题在人工直接写从库、主库异常切换或数据迁移不完整时比较常见。遇到该错误，部分人会直接使用set global sql_slave_skip_counter来跳过一个事务，但这种做法需要谨慎。

一、什么是报错1062

报错1062的全称是Duplicate entry，意思是插入或更新操作违反了唯一约束。在从库上，复制线程试图执行一条在主库已经成功、但在从库已存在相同主键的SQL，就会报出类似下面的错误：

Last_SQL_Error: Could not execute Write_rows event on table test.user;
Duplicate entry '1001' for key 'PRIMARY', Error_code: 1062;

二、set global sql_slave_skip_counter能做什么

sql_slave_skip_counter是一个全局变量，用来告诉从库在启动复制时跳过指定数量的事务事件。它通常用于临时跳过造成复制停止的一个错误事务。

使用方式如下：

-- 停止从库复制线程
STOP SLAVE;

-- 跳过1个事件（对于基于语句或混合模式，通常1代表一个事务）
SET GLOBAL sql_slave_skip_counter = 1;

-- 重新启动复制
START SLAVE;

需要注意，sql_slave_skip_counter在GTID模式（gtid_mode=ON）下是不支持的，执行会报错。只有在传统基于文件位置的复制中才能使用。

三、使用跳过命令的风险

直接跳过错误虽然能让同步继续，但被跳过的事务不会在从库执行，可能造成主从数据不一致。如果冲突数据重要，后续查询从库就会拿到错误结果。

• 仅适合确认冲突行无关紧要或已在从库手动补齐的场景
• 不建议在核心业务从库上频繁使用该方式
• 跳过后应通过pt-table-checksum等工具校验一致性

四、更安全的处理方案

1. 手动修复冲突数据

先查看从库已有记录和主库对应记录，确认哪边正确。若从库数据多余或错误，可删除从库冲突行后再启动复制：

STOP SLAVE;
-- 删除从库冲突主键记录
DELETE FROM test.user WHERE id = 1001;
START SLAVE;

2. GTID模式下跳过事务

若使用GTID复制，应通过注入空事务跳过，而非sql_slave_skip_counter：

STOP SLAVE;
SET GTID_NEXT='aaa-bbb-ccc:123';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;

3. 重建从库

当不一致较多时，最稳妥的方式是从主库重新导出数据并重建从库。

五、总结

MySQL主从同步报错1062可以使用set global sql_slave_skip_counter跳过，但仅限非GTID模式且确认安全风险可控时临时使用。日常运维中应优先排查并修复数据冲突，保障主从一致。

MySQL主从同步sql_slave_skip_counter报错1062修改时间：2026-07-30 03:21:19