MySQL主从同步报错修复：SET GLOBAL跳过事务

MySQL主从同步报错修复：慎用SET GLOBAL跳过错误事务

在处理MySQL主从同步报错时，SET GLOBAL sql_slave_skip_counter = 1命令常被视为“急救措施”。然而，它并非万能解决方案，不当使用可能导致数据一致性出现更严重的问题。

简而言之，SET GLOBAL sql_slave_skip_counter = 1仅对基于语句的复制（SBR）且未启用GTID的模式有效。在GTID模式下执行此命令会报错，此时应改用SET GTID_NEXT配合空事务的方式来跳过错误。

SET GLOBAL sql_slave_skip_counter = 1 有时失效的原因

其根本原因在于复制模式的差异。该命令仅适用于binlog_format=STATEMENT且未启用GTID的复制环境。若MySQL已启用GTID（gtid_mode=ON），执行SET GLOBAL sql_slave_skip_counter = 1将直接返回错误：ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON.在这种情况下，必须通过GTID_NEXT方式注入空事务来跳过错误。

GTID模式下跳过单条错误事务的正确步骤

首先确认从库是否启用了GTID：

SELECT @@gtid_mode, @@enforce_gtid_consistency;

若返回结果为ON，则按以下步骤操作：

• 执行STOP SLAVE;
• 通过SHOW SLAVE STATUS\G查看Retrieved_Gtid_Set和Executed_Gtid_Set，结合Last_SQL_Error定位出错事务的GTID
• 手动设置下一个要执行的GTID（需与出错事务一致）：SET GTID_NEXT = 'e46c9961-5780-11ea-bf2f-000c128a8b6b:12345';（该值来源于Last_IO_Error或Relay_Master_Log_File与Exec_Master_Log_Pos对应的binlog事件）
• 执行空事务：BEGIN; COMMIT;
• 将GTID_NEXT重置为自动模式：SET GTID_NEXT = 'AUTOMATIC';
• 执行START SLAVE;

执行跳过操作前必须检查的三个关键点

盲目执行sql_slave_skip_counter或空事务可能导致主从数据永久不一致。操作前务必确认：

• 错误类型是否确实可跳过：例如Error_code: 1032（记录不存在）或Error_code: 1062（主键冲突）通常可跳过，但如遇Error_code: 1054（字段不存在）则表明表结构不一致，需先修复结构。
• 主库该事务是否已真正提交：若主库因崩溃未持久化事务，而从库已接收到部分binlog，跳过操作会导致从库产生脏数据。
• 是否启用了多线程复制（slave_parallel_workers > 0）：在此设置下，sql_slave_skip_counter的行为可能不可靠，建议先将该参数设为0再操作。

跳过操作后如何验证同步是否真正恢复

执行START SLAVE后，不能仅凭Slave_IO_Running和Slave_SQL_Running状态均为Yes就判断恢复。还需重点检查：

• Seconds_Behind_Master是否持续下降，而非停滞不前。
• Exec_Master_Log_Pos是否持续向前推进，且与主库SHOW MASTER STATUS显示的Position差距不再扩大。
• 可在主库执行一条带有明显特征的INSERT语句进行验证，例如：INSERT INTO test_sync VALUES (UNIX_TIMESTAMP(), 'verify');，随后立即在从库查询该数据是否已同步。

需要明确的是，跳过错误的本质是“暂时规避问题”，而非“根本解决问题”。只要表结构、初始化数据、GTID配置或binlog格式其中任一环节未对齐，跳过操作就只是将故障延迟爆发。因此，操作存在风险，务必谨慎处理。