当使用 GTID 时（gtid_mode 为 ON），即使事务内容被过滤掉，已提交事务的 GTID 也会保存在副本上。此功能可防止副本在使用 GTID 自动定位重新连接到源时检索到之前已过滤的事务。它还可以用于跳过副本上的事务，方法是在失败的事务位置提交一个空事务。

当您使用 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项在复制通道上启用 GTID 分配时，这种跳过事务的方法不适合。

如果失败的事务在工作线程中生成了错误，您可以直接从 Performance Schema 表 replication_applier_status_by_worker 中的 APPLYING_TRANSACTION 字段获取其 GTID。要查看事务是什么，请在副本上执行 SHOW RELAYLOG EVENTS 或在源上执行 SHOW BINLOG EVENTS，并在输出中搜索由该 GTID 之前的那个事务。

当您评估了失败事务的任何其他适当操作（如安全注意事项）后，要跳过它，请在副本上提交一个与失败事务具有相同 GTID 的空事务。例如

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';

副本上存在此空事务意味着，当您发出 START REPLICA 语句来重新启动复制时，副本使用自动跳过功能来忽略失败的事务，因为它看到具有该 GTID 的事务已应用。如果副本是多源副本，则在提交空事务时不需要指定通道名称，但在发出 START REPLICA 时需要指定通道名称。

请注意，如果在此副本上使用了二进制日志记录，如果副本将来成为源或主服务器，空事务将进入复制流。如果您需要避免这种情况，请考虑刷新和清除副本的二进制日志，例如

FLUSH LOGS;
PURGE BINARY LOGS TO 'binlog.000146';

空事务的 GTID 会持久化，但事务本身会通过清除二进制日志文件而被删除。

要跳过 GTID 未使用或正在逐步引入时的失败事务（gtid_mode 为 OFF、OFF_PERMISSIVE 或 ON_PERMISSIVE），您可以通过发出 SET GLOBAL sql_replica_skip_counter 来跳过指定数量的事件。或者，您可以通过发出 CHANGE REPLICATION SOURCE TO 语句来向前移动源二进制日志位置，跳过事件或事件。

当您使用 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项在复制通道上启用 GTID 分配时，这些方法也适用。

当您使用这些方法时，重要的是要了解，您并不一定会跳过一个完整的事务，正如之前描述的基于 GTID 的方法总是那样。这些基于非 GTID 的方法并不了解事务本身，而是对事件进行操作。二进制日志被组织为一系列称为事件组的组，每个事件组包含一系列事件。

一个事务可以包含对事务表和非事务表的更改。

当您使用 SET GLOBAL sql_replica_skip_counter 语句来跳过事件，并且结果位置位于事件组的中间时，副本会继续跳过事件，直到到达该组的末尾。然后从下一个事件组开始执行。 CHANGE REPLICATION SOURCE TO 语句没有此功能，因此您必须小心地识别正确的位置，以便在事件组的开头重新启动复制。但是，使用 CHANGE REPLICATION SOURCE TO 意味着您不必像使用 SET GLOBAL sql_replica_skip_counter 那样计算需要跳过的事件，而是可以只指定要重新启动的位置。

SET GLOBAL sql_replica_skip_counter = N

CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='source_log_name', SOURCE_LOG_POS=source_log_pos;

CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION=0, SOURCE_LOG_FILE='binlog.000145', SOURCE_LOG_POS=235;
CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION=1;