GTID复制架构主备切换后从库触发Error 1062主键重复故障咨询

先结合你排查的所有信息，把逻辑链条理清楚，排除干扰项：

• 首先澄清认知误区：你提到的“报错涉及的utilBINLog-bin.000029不存在于从库本地BINLOG列表”不是故障诱因。从库本地BINLOG记录的是它自身作为主节点运行阶段生成的事件流，序号从000001到000005是它自己的文件滚动规则；而报错里的BINLOG名称是当前接入主库的源事件标识，和从库本地的BINLOG序号没有任何关联，这部分属于正常现象。
• 核心诱因是两周前硬切换遗留的GTID位点错位+结构/字符集偏差导致的虚假冲突：
  1. 从你给出的两个节点的GTID集合对比可以看到，原主库（现已转为从库）上，UUID为77818f20-e21a-11ea-b443-005056af4111的事务位点已经执行到9605354，而当前主库同UUID的位点仅到9585630——接近2万的GTID差值，是硬切换发生时，原主在宕机前已经本地提交、但未同步到当时从库（现主库）的事务。
  2. 硬切换完成后，业务流量切到新主库运行期间，因为新主库不知道原主未同步的事务内容，对同主键的行做了重新写入；待原主恢复并配置为新主的从库后，SQL线程重放新主发来的这些写入事件时，就会出现主键冲突。
  3. 你在主、从库都检索不到报错里的主键记录，本质是错误日志中的键值是被截断、转义后的十六进制显示值：如果主从表的字符集、列类型存在细微偏差（比如主键列一边是utf8mb4一边是latin1、或者varchar长度不一致），会导致从库在做写入校验时，把其他列的值算进主键比对逻辑，触发虚假的1062报错，自然按报错显示的乱码值检索不到匹配记录。

全程不需要盲目跳事务，也不会打破GTID的连续一致性，按步骤执行即可：

1. 精确定位报错对应的事务GTID，不需要预判涉及事务数量

• 先在从库执行STOP SLAVE SQL_THREAD;，保持IO线程正常拉取事件，不要全量停止复制。
• 通过SHOW SLAVE STATUS \G获取当前SQL线程的停止位置，也就是Relay_Log_File和Relay_Log_Pos对应的参数值。
• 用mysqlbinlog工具解析对应relay log文件，定位到Relay_Log_Pos的位置，向上回溯找到最近的GTID_EVENT，就是本次1062报错对应的精确事务GTID。如果后续重放时还会连续碰到其他冲突事务，重复这个定位流程即可。

2. 验证冲突的真实属性

• 用mysqlbinlog解析对应relay log中该GTID覆盖的所有Write_rows事件，提取事件中写入的真实列值，不要直接拿错误日志里的转义键值做检索。
• 拿提取出的真实列值，到从库对应表上逐行匹配：
  • 如果匹配到记录：对比该记录和事件中的列值是否完全一致。如果完全一致，说明这个事务是硬切换时的重复提交，本地已经有相同内容的变更，不需要重复应用；如果不一致，说明存在真实数据分叉，需要先把主库该表的对应行数据同步到从库，补全差异后再继续应用。
  • 如果匹配不到记录：逐字对比主、从同一张表的建表语句，检查字符集、列类型、主键定义的差异，修正从库的表结构偏差后再启动SQL线程。

3. 按验证结果做精准处理

• 确认本地已存在完全一致的变更内容后，执行空事务注入标记该GTID为已处理：

  STOP SLAVE;
  -- 替换为之前定位到的实际冲突GTID值
  SET GTID_NEXT = '对应冲突的GTID';
  BEGIN;
  COMMIT;
  SET GTID_NEXT = 'AUTOMATIC';
  START SLAVE;
  

  这种方式和直接跳事务有本质区别：空事务是严格匹配GTID标识标记为已处理，不会跳过任何其他未执行的GTID，完全符合GTID复制的原子性要求，不会漏数据、也不会打破位点连续性。
• 如果发现真实数据分叉，不要用空事务或者skip counter，直接逐表做全量数据校验，把差异从主库同步到从库，校验完成后再启动SQL线程即可。

• 不建议执行stop slave; reset slave; start slave：根据MySQL官方逻辑，reset slave只会清除本地relay log、主库连接配置文件，完全不会修改从库的Executed_Gtid_Set值，在自动定位模式下重启复制后，还是会拉取到之前的冲突点，根本解决不了问题。
• 严禁用SET GLOBAL sql_slave_skip_counter = N跳过错误：这个参数仅适配传统位点复制，在GTID模式下会打乱连续的GTID序列，极容易导致后续复制因为位点不连续出现更多数据不一致，严重时需要重建从库。

后续硬切换的预防建议：原主节点恢复上线准备作为从库接入新主前，必须先对比双方的Executed_Gtid_Set差值，把原主上超前的事务导出做冲突校验，同时逐表校验主从的表结构一致性，从根源避免这类冲突。

内容的提问来源于stack exchange，提问作者AnonymeJohnDoe