GTID が使用されている場合 (gtid_mode が ON)、コミットされたトランザクションの GTID は、トランザクションの内容がフィルタで除外されてもレプリカに保持されます。 この機能により、GTID 自動配置を使用してソースに再接続したときに、レプリカが以前にフィルタ処理されたトランザクションを取得できなくなります。 また、障害が発生したトランザクションのかわりに空のトランザクションをコミットすることで、レプリカ上のトランザクションをスキップするためにも使用できます。

このトランザクションのスキップ方法は、CHANGE REPLICATION SOURCE TO ステートメントの ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS オプションを使用してレプリケーションチャネルで GTID 割当てを有効にした場合には適していません。

失敗したトランザクションによってワーカースレッドでエラーが生成された場合は、「パフォーマンススキーマ」テーブル replication_applier_status_by_worker の LAST_SEEN_TRANSACTION フィールドから GTID を直接取得できます。 トランザクションの内容を確認するには、レプリカまたはソース上の SHOW BINLOG EVENTS で SHOW RELAYLOG EVENTS を発行し、その GTID で始まるトランザクションの出力を検索します。

前述の他の適切なアクション (セキュリティ上の考慮事項など) の失敗したトランザクションを評価した場合、スキップするには、失敗したトランザクションと同じ GTID を持つレプリカで空のトランザクションをコミットします。 例:

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

レプリカ上にこの空のトランザクションが存在するということは、レプリケーションを再開するために START REPLICA | SLAVE ステートメントを発行すると、その GTID を持つトランザクションがすでに適用されていることがわかっているため、レプリカは自動スキップ機能を使用して失敗したトランザクションを無視することを意味します。 レプリカがマルチソースレプリカの場合、空のトランザクションのコミット時にチャネル名を指定する必要はありませんが、START REPLICA | SLAVE の発行時にチャネル名を指定する必要があります。

バイナリロギングがこのレプリカで使用されている場合、レプリカが将来ソースまたはプライマリになると、空のトランザクションがレプリケーションストリームに入ります。 この可能性を回避する必要がある場合は、次の例のようにレプリカバイナリログをフラッシュおよびパージすることを検討してください:

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

空のトランザクションの GTID は永続化されますが、トランザクション自体はバイナリログファイルをパージすることによって削除されます。

GTID が使用されていないか、段階的に導入されている (gtid_mode が OFF、OFF_PERMISSIVE または ON_PERMISSIVE) 場合に失敗したトランザクションをスキップするには、SET GLOBAL sql_slave_skip_counter ステートメントを発行して、指定した数のイベントをスキップできます。 または、CHANGE MASTER TO ステートメントを発行してソースバイナリログの位置を前方に移動することによって、イベントを過ぎてスキップすることもできます。

これらの方法は、CHANGE REPLICATION SOURCE TO ステートメントの ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS オプションを使用してレプリケーションチャネルで GTID 割当てを有効にした場合にも適しています。

これらの方法を使用する場合は、前述の GTID ベースの方法の場合と同様に、完全なトランザクションをスキップする必要はないことを理解することが重要です。 GTID ベース以外のこれらの方法では、そのようなトランザクションは認識されませんが、かわりにイベントを操作します。 バイナリログはイベントグループと呼ばれる一連のグループとして編成され、各イベントグループは一連のイベントで構成されます。

1 つのトランザクションに、トランザクションテーブルと非トランザクションテーブルの両方の変更を含めることができます。

SET GLOBAL sql_slave_skip_counter ステートメントを使用してイベントをスキップし、結果の位置がイベントグループの途中にある場合、レプリカはグループの最後に達するまでイベントをスキップし続けます。 そのあと、次のイベントグループから実行が開始されます。 CHANGE MASTER TO ステートメントにはこの機能がないため、イベントグループの開始時にレプリケーションを再開する正しい場所を特定するように注意する必要があります。 ただし、CHANGE MASTER TO を使用すると、SET GLOBAL sql_slave_skip_counter と同様にスキップする必要があるイベントをカウントする必要がなく、かわりに再起動する場所を指定できます。

SET GLOBAL sql_slave_skip_counter = N

CHANGE MASTER TO MASTER_LOG_FILE='source_log_name', MASTER_LOG_POS=source_log_pos;

CHANGE MASTER TO MASTER_AUTO_POSITION=0, MASTER_LOG_FILE='binlog.000145', MASTER_LOG_POS=235;
CHANGE MASTER TO MASTER_AUTO_POSITION=1;