跳过事务是什么
复制中断时，跳过报错事务是危险但必要的能力。GTID 模式下的做法是造一个空事务占位：把下一个待执行事务的 GTID 赋给 GTID_NEXT，然后执行一个空的 BEGIN 与 COMMIT，让从库「假装已经执行过」。非 GTID 模式使用 sql_replica_skip_counter（8.0.23 之前叫 sql_slave_skip_counter），它一次跳过的事件数并不确定，因此必须一次只跳一个、逐步推进。
基本信息
| GTID 模式 | SET GTID_NEXT 后执行空事务占位 |
|---|---|
| 非 GTID 模式 | SET GLOBAL sql_replica_skip_counter = 1 |
| 作用范围 | 需要先单独停止 SQL 线程 |
| 操作原则 | 一次只跳一个事务，跳完立刻核对 |
| 记录要求 | 写下事务号、原因与后续补偿动作 |
典型使用场景
- 从库因唯一键冲突导致复制中断
- 主库执行了涉及从库不存在对象的操作
- DDL 在从库上重复执行报错
- 临时恢复复制链路，先让业务可用
- 演练中验证跳错流程与记录的完整性
两种跳过方式
两种跳过方式
-- GTID 模式
STOP REPLICA SQL_THREAD;
-- 从 Last_SQL_Error 附近找到下一个待执行的 GTID
SET GTID_NEXT = '3a7f1e3b-1111-2222-3333-444455556666:4711';
BEGIN;
COMMIT;
SET GTID_NEXT = 'AUTOMATIC';
START REPLICA SQL_THREAD;
-- 非 GTID 模式（一次跳一个）
STOP REPLICA SQL_THREAD;
SET GLOBAL sql_replica_skip_counter = 1;
START REPLICA SQL_THREAD;方式与风险
| 方式 | 适用与风险 | 注意事项 |
|---|---|---|
| GTID_NEXT 空事务 | GTID 模式下的标准做法 | 填错 GTID 会把后续事务也一起跳过 |
| skip_counter | 非 GTID 模式 | 一次跳过的实际事件数并不确定 |
| STOP SQL_THREAD | 两种方式的前置动作 | 只停 IO 线程无法完成跳过 |
| 记录事务号 | 事后核对与补偿 | 不记录就无法判断影响范围 |
| 重放校验 | 跳过之后的必做动作 | 跳过即意味着接受不一致 |
跳过事务等于接受主从数据不一致：必须记录事务号、原因与后续补偿动作，并在业务低峰核对受影响的数据，否则差异会长期留在系统里。
GTID 模式下 skip_counter 被禁用，用了会直接报错。不要两种方式混着用，先确认实例到底运行在哪种模式下再动手。
被跳过的 GTID 在从库是永久缺失的：如果该从库将来被提升为主，这部分数据必须从旧主单独核对并补齐，否则丢失会一直传递下去。