當使用 GTID 時（gtid_mode 為 ON），即使交易內容被過濾掉，已提交交易的 GTID 也會保存在副本上。此功能可防止副本在使用 GTID 自動定位重新連線至來源時，擷取先前過濾的交易。它也可以用來跳過副本上的交易，方法是提交一個空交易來取代失敗的交易。

如果您使用 CHANGE REPLICATION SOURCE TO 陳述式的 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 時（gtid_mode 為 OFF、OFF_PERMISSIVE 或 ON_PERMISSIVE）跳過失敗的交易，您可以透過執行 SET GLOBAL sql_replica_skip_counter 來跳過指定數量的事件。或者，您可以執行 CHANGE REPLICATION SOURCE TO 陳述式來跳過一個或多個事件，將來源二進位日誌位置向前移動。

當您使用 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;