主键冲突（ERROR 1062）需通过SHOW SLAVE STATUS定位错误及日志位置，用mysqlbinlog解析确认冲突SQL；若数据冗余则DELETE修复，GTID模式下用SET GTID_NEXT+空事务跳过；严禁长期启用slave-skip-errors。
主键冲突（ERROR 1062）怎么快速定位和修复
主键或唯一键冲突是最常见的复制中断原因，典型错误是 ERROR 1062 (23000): Duplicate entry '1001' for key 'PRIMARY'。它说明从库试图插入一条主库已存在、且从库本地也已存在的记录——通常是因为人为在从库执行过 INSERT，或双主配置下自增ID未错开。
定位时直接看 SHOW SLAVE STATUS\G 中的 Last_SQL_Error 和 Relay_Log_File+Relay_Log_Pos，再用 mysqlbinlog --base64-output=DECODE-ROWS -v 解析中继日志，确认那条“撞车”的 INSERT 是什么内容。
- 若该行确实不该存在（比如测试数据），直接在从库
DELETE FROM table_name WHERE id = 1001，再START SLAVE - 若想保留从库数据、跳过冲突事件：启用 GTID 时用
SET GTID_NEXT='xxx:yyy'; BEGIN; COMMIT;；非 GTID 模式用SET GLOBAL sql_slave_skip_counter = 1（仅跳一个事件） - 严禁在生产环境长期开启
slave-skip-errors = 1062，它会掩盖问题，导致主从静默不一致
记录不存在（ERROR 1032）为什么比主键冲突更危险
ERROR 1032 (HY000): Can't find record in 't_user' 表示主库执行了 UPDATE 或 DELETE，但从库找不到对应行。表面看只是“跳过”，实则暴露了更深层的数据漂移：可能从库被删过数据、或主库之前没同步成功就跳过了、甚至 binlog 被截断过。
这类错误不能简单跳过，否则后续依赖该行的变更（如级联更新、触发器逻辑）全会失效。
- 先查
Exec_Master_Log_Pos对应的主库 binlog，确认原始 SQL 是什么；再查从库是否真缺失这行（SELECT * FROM t_user WHERE id = xxx） - 若确认缺失且业务允许，可从主库导出该行：
mysqldump --where="id=xxx" db table > row.sql，再导入从库 -
工具推荐
pt-slave-repair：它会自动解析 binlog，对DELETE直接跳过，对UPDATE则转成REPLACE INTO反向修复——但要求binlog_format = ROW且binlog_row_image = FULL
GTID 模式下跳过事务为什么必须用空事务注入
启用了 gtid_mode=ON 后，sql_slave_skip_counter 就失效了，因为 GTID 复制靠事务 ID 推进，不是靠日志位置计数。强行设 skip counter 会导致 GTID 集合错乱，后续同步彻底失败。
正确做法是“伪造已执行”：把报错事务的 GTID（见 Retrieved_Gtid_Set 或 Executed_Gtid_Set 中带错误的那个）赋给 GTID_NEXT，再提交一个空事务。
- 操作顺序必须严格：
STOP SLAVE→SET GTID_NEXT='uuid:12345'→BEGIN; COMMIT;→SET GTID_NEXT='AUTOMATIC'→START SLAVE - 注意：如果
GTID_NEXT值写错（比如少一位、大小写混），会报ERROR 1840，必须重试 - 不要在多线程复制（
slave_parallel_workers > 0）时注入，先SET GLOBAL slave_parallel_workers = 0再操作
read_only 和 super_read_only 哪个才真正防住误写
read_only = ON 只阻止普通用户写入，但拥有 SUPER 权限的账号（如运维账号、监控账号、备份工具）仍能绕过。一旦这类账号连上从库执行了 DML，冲突就埋下了。
真正有效的防护是 super_read_only = ON（MySQL 5.7.8+），它连 SUPER 权限都限制了——除非先关掉它，否则任何写操作都会报 ERROR 1290。
- 配置后务必验证：
mysql -uadmin -p -e "INSERT INTO test.t VALUES(1)"应失败；再用SET GLOBAL super_read_only = OFF测试是否可临时放开 - 别忘了在 my.cnf 里持久化：
super_read_only = ON，避免重启后失效 - 如果应用本身有高权限连接池，建议同时回收其
SUPER权限，只留SELECT, REPLICATION CLIENT等必要权限
最常被忽略的一点：冲突处理不是“修完就完”，而是要反推根源。比如一次 1062 错误背后，可能是中间件路由错误、应用配置漏切读写分离、或是 DBA 手动修复时没走标准流程。修复动作本身越快，越要花时间确认“为什么这里会写从库”。
