MySQL主从架构凭借读写分离与容灾能力被大量业务采用，但在长期运行里，从库复制进程偶尔会抛出执行报错并中止同步。这类故障常表现为Slave_SQL_Running变为No，且Last_Error中提示某条事务无法应用。面对这种情形，不少新手会直接重启服务，结果错误依旧。我们需要先读懂错误本质，再决定是否用SET GLOBAL方式跳过，以及跳过之后还要做哪些修补动作。
一、主从同步报错的常见根源与诊断方法
从库在执行中继日志中的事务时失败，根源大致分为几类。其一是主库执行了不符合从库约束的操作，例如主库某表使用了从库不存在的字符集或存储引擎；其二是数据本身不一致，比如从库比主库多出一列，导致更新语句字段不匹配；其三是重复键冲突，主库重放binlog时试图插入从库已存在的唯一索引记录。通过SHOW SLAVE STATUSG可以观察到Last_Errno、Last_Error以及Exec_Master_Log_Pos等关键字段，它们直接指出出错的事务偏移量。
诊断时不能只看错误信息就动手，还应比对主库对应位置的binlog内容。利用mysqlbinlog工具解析主库二进制日志，能够还原出引发故障的SQL语句。例如错误代码1062代表Duplicate entry，说明从库已有相同主键；错误代码1032代表Can't find record，意味着从库缺失被更新的行。明确类型后才能判断该事务是否可安全忽略，若属于从库多余数据引发的冲突，跳过相对安全，若是主库核心写入丢失，则必须先补数据。
除了即时报错，还要关注Seconds_Behind_Master是否持续增大。一旦SQL线程停止，延迟不再增长但数据已断层。此时应在业务低峰期处理，避免跳过事务后引发读写分离接口返回陈旧甚至错误数据。建立定期pt-table-checksum校验习惯，可在报错前发现不一致趋势，降低突发中断概率。
二、使用SET GLOBAL sql_slave_skip_counter安全跳过事务
当确认报错事务无关紧要或属可忽略冲突时，MySQL提供了SET GLOBAL sql_slave_skip_counter=N来通知从库SQL线程跳过接下来N个事件。注意该变量仅在停止SQL线程后设置才生效，且它是全局级别，会影响整个复制链路。标准流程是先STOP SLAVE SQL_THREAD;，再执行设置语句，最后START SLAVE SQL_THREAD;。若错误仅涉及单个事件，N填1即可，不可盲目设大值，否则可能跨过正常事务。
下面是一段典型的修复操作代码，展示如何在从库跳过一次错误事务：
-- 查看当前从库状态，确认报错位置 SHOW SLAVE STATUSG -- 停止从库的SQL应用线程 STOP SLAVE SQL_THREAD; -- 设置跳过1个复制事件（对应一个出错事务） SET GLOBAL sql_slave_skip_counter = 1; -- 重新启动SQL线程 START SLAVE SQL_THREAD; -- 再次检查状态，确认Slave_SQL_Running为Yes且错误消失 SHOW SLAVE STATUSG
需要强调的是，sql_slave_skip_counter在基于GTID的复制模式中不再适用。若主从启用了GTID（gtid_mode=ON），必须改用注入空事务的方式：在从库执行SET GTID_NEXT='出错事务的GTID'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';来完成跳过。这是因为GTID机制要求事务标识全局唯一，计数器跳过会破坏一致性协议，强行使用将被拒绝。
跳过之后务必观察后续同步是否平稳。如果连续多次报同类错误，说明两库数据已存在结构性偏差，单靠跳过只会让从库变成“部分数据”镜像。此时应结合pt-table-sync等工具，以主库为基准修复从库分歧行，而不是无限制地跳过。
三、跳过后的数据一致性保障与长期防护
使用SET GLOBAL跳过错误事务只是应急手段，并非治本方案。跳过的瞬间从库就丢失了该事务的修改，若业务依赖此数据，则读写分离查询将返回偏差结果。因此在生产环境，应在跳过前评估涉及表是否参与核心交易。对于用户余额、订单状态类表，建议先在主库补造相同效果的数据，再在从库跳过，使得最终状态收敛。
长期防护方面，首要任务是规范主库变更流程。所有DDL应通过审核工具发布，确保从库提前具备兼容结构；避免直接在从库做写入，防止主键冲突。可以配置slave_skip_errors参数来自动忽略指定错误码，但该方式过于宽泛，仅建议临时救急。更优做法是开启半同步复制，让主库提交时至少收到一个从库ACK，降低日志丢失引起的断层。
另外，建立监控告警能缩短故障发现时间。当Slave_SQL_Running为No时，通过脚本推送通知，运维人员可依据上述诊断步骤快速介入。定期用percona工具做全量一致性校验，并将差异报告归档，能清晰掌握主从健康度。只有将跳过事务作为偶发补救，配合严谨的数据校验，MySQL主从同步才能真正稳定支撑业务。
MySQL主从同步SET_GLOBAL跳过错误事务修改时间：2026-08-19 03:06:28