MySQL主从同步报1062错误如何处理：跳过冲突SQL或重新同步

为什么SET GLOBAL sql_sla ve_skip_counter = 1现在大多失效了

如果你还在用sql_sla ve_skip_counter这个命令来处理复制错误，很可能会碰一鼻子灰。这可不是你命令输错了，而是游戏规则已经变了。从MySQL 8.0.23版本开始，基于GTID的复制成了默认选项，那个老办法sql_sla ve_skip_counter已经被正式弃用。强行执行？等着你的只会是ERROR 1251: SET GLOBAL sql_sla ve_skip_counter is not supported when @@GLOBAL.GTID_MODE = ON这个报错。

那么，在GTID的世界里，正确的“跳过”姿势是什么？前提很明确：主从都必须开启GTID，并且你得精准定位到是哪个事务卡住了。通常，通过查询performance_schema.replication_applier_status_by_coordinator，从LAST_ERROR_MESSAGE里就能找到那个惹事的GTID值。

• 第一步，先停下复制：STOP REPLICA;
• 第二步，执行“跳过”操作：设置SET GTID_NEXT = ‘xxx-xxx-xxx:nnn’;（这里填入错误中显示的GTID），然后执行一个空事务：BEGIN; COMMIT;
• 第三步，重置GTID设置：SET GTID_NEXT = ‘AUTOMATIC’;
• 最后，重启复制：START REPLICA;

1062 错误本质是主从数据不一致，不是“跳过就完事”

遇到Duplicate entry ‘xxx’ for key ‘PRIMARY’这种1062错误，很多人的第一反应是“跳过去”。但这就好比家里漏水了，你只是拿个盆接住，而不去修水管。这个报错的本质，是主库和从库的数据已经出现了不一致——从库里已经存在某条记录，但主库又发来一条INSERT或REPLACE，自然就撞上了唯一键冲突。

这种不一致的根源，往往在于几个地方：是不是有人在从库上手动写了数据？主库的双写机制关干净了吗？还是历史数据导入时漏了东西？直接跳过，只是把问题暂时掩盖起来，下次它很可能在别的表、别的字段上再次爆发。

所以，正确的处理思路是溯源。必须搞清楚：这条引发冲突的SQL，在主库那边到底该不该执行？是开发同学的误操作，是残留的测试数据，还是应用层的幂等性没做好？

• 去主库查Binlog：用mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | grep -A 10 -B 10 ‘xxx’，看看这条INSERT语句的来龙去脉。
• 对比主从数据：在从库执行SELECT * FROM tbl WHERE id = xxx;，再对比主库的结果，看看到底是谁多了谁少了。
• 如果确认从库多出来的数据不影响业务，那么可以先DELETE FROM tbl WHERE id = xxx;清理掉，然后再START REPLICA;重启复制。

想彻底重新同步，别用 mysqldump + 导入这种“土法炼钢”

当主从差异太大，很多人会想到全量重新同步。但直接使用mysqldump导出再导入，对于数据量大的库来说，风险极高：长时间锁表可能拖垮主库性能，导入过程产生新的延迟，甚至可能因为字符集、时区或SQL_MODE的细微差别，导致难以察觉的隐性数据损坏。

更稳妥的路径，是基于现有从库做数据“克隆”或“快照恢复”。如果一定要用mysqldump，那么关键不在于导出，而在于后续的精细操作。推荐使用mysqldump --single-transaction --master-data=2 --triggers --routines进行导出，但请注意接下来的步骤：

• 导入前，务必先停掉从库的SQL线程。
• 导出时，如果主从已启用GTID模式，务必加上--set-gtid-purged=OFF参数，否则导入很可能失败。
• 导入后，需要手动、精确地重设复制位点。使用CHANGE REPLICATION SOURCE TO命令时，其中的SOURCE_LOG_FILE和SOURCE_LOG_POS必须与dump文件里CHANGE MASTER注释的信息严格对应。
• 最后，一定要做校验。检查SHOW REPLICA STATUS\G中的Retrieved_Gtid_Set和Executed_Gtid_Set是否连续，如有断点，用SELECT GTID_SUBTRACT(...)来核对。整个操作应避开业务高峰期，导入完成后先别急着开复制，确认数据一致后再START REPLICA。

最容易被忽略的坑：从库的 read_only 和 super_read_only

这是很多团队踩过的坑：以为给从库设置了read_only = ON就万事大吉，结果忘了还有super_read_only这一层。导致什么后果呢？拥有SUPER权限的用户（比如root）依然可以在从库进行写入。这种“悄悄”的脏写，就是下一次1062冲突的定时冲击波。这不是配置没生效，而是权限防御漏了一层。

验证方法很简单：执行SELECT @@read_only, @@super_read_only;，两个值都必须为1，从库才算真正进入了只读状态。如果之前已经发生了误写，光打开参数是没用的，必须人工介入，比对、清理数据，然后再做校验。

• 对于已经发生的误写，临时修复步骤是：STOP REPLICA; DELETE FROM tbl WHERE …; START REPLICA;
• 为了长期防护，建议在初始化从库的脚本里，就明确写上这两行：SET PERSIST read_only = ON; 和 SET PERSIST super_read_only = ON;。
• 监控方面也可以加一道保险：定期检查SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND != ‘Sleep’ AND USER != ‘system user’;，异常的活跃连接很可能就是脏写的源头。

以上就是处理MySQL主从同步1062错误的核心思路与操作指南。理清原理，按步骤操作，才能从根本上解决问题，确保复制链路稳定可靠。