复制报 1062 是什么
从库重放主库日志时插入记录撞上已有主键或唯一键，复制线程停止并报错 1062（重复条目）。常见原因是有人直接写从库、双向复制产生冲突，或人工拼接数据留下重复记录。处理原则是先判断该保留哪一份数据，跳过事务只是最后手段。
基本信息
| 错误码 | 1062，Duplicate entry，主键或唯一键冲突 |
|---|---|
| 查看位置 | SHOW REPLICA STATUS 里的最后错误字段 |
| 线程影响 | 复制处理线程停止，拉取线程仍在运行 |
| 前置动作 | 先停止处理线程，避免错误持续累积 |
| 恢复方式 | 修正数据后重启线程，或在事务模式下跳过该事务 |
典型使用场景
- 从库被误写：运维直接在从库执行了插入，主库重放时撞键
- 双向或多源复制冲突：两个写入源同时插入同一业务键
- 数据导入留下重复：人工修复数据后与主库变更产生冲突
- 分库合并：多库合并到同一套表时出现重复主键
- 演练与测试：在测试环境复现冲突并验证跳过流程是否安全
定位与处理
定位与处理
-- 看具体冲突的键与语句
SHOW REPLICA STATUS\G
-- 查冲突数据，判断保留哪一份
SELECT * FROM appdb.users WHERE id = 12345;
-- 先停处理线程，避免错误持续累积
STOP REPLICA SQL_THREAD;
-- 修正数据后重启
START REPLICA SQL_THREAD;
-- 确实需要跳过该事务（GTID 环境）：
SET GTID_NEXT = '3a7f1e3b-1111-1111-1111-111111111111:4711';
BEGIN; COMMIT;
SET GTID_NEXT = 'AUTOMATIC';
START REPLICA SQL_THREAD;处理方式对照
| 方式 | 适用 | 代价 |
|---|---|---|
| 修正从库数据后重试 | 能判断主库版本正确 | 改动小，推荐优先 |
| 跳过该事务 | 冲突数据来自误写且影响可评估 | 从库永久缺少这次变更 |
| 重建从库 | 冲突反复出现或数据已漂移 | 耗时较长但结果干净 |
| 改造为幂等写入 | 业务侧可控制 | 需发版，长期收益最大 |
冲突反复出现说明拓扑中存在第二个写入点：先把写入源找出来并关掉，比反复跳过有效得多。
每次跳过都会让从库永久少一次变更，若后续需要以从库为准做切换，会暴露数据缺失。