このページは機械翻訳したものです。

17.2.5.3 レプリケーションフィルタリングオプション間の相互作用

データベースレベルとテーブルレベルのレプリケーションフィルタリングオプションの組合せを使用する場合、レプリカは最初にデータベースオプションを使用してイベントを受け入れるか無視し、次にテーブルオプションに従ってそれらのオプションで許可されるすべてのイベントを評価します。 これにより、結果が直感的に印刷される場合があります。 また、ステートメントベースと行ベースのどちらのバイナリロギング形式を使用して操作をログに記録するかによって結果が異なることにも注意してください。 レプリケーションフィルタがバイナリロギング形式とは独立して常に同じ方法で動作するようにする場合は、特に混合バイナリロギング形式を使用する場合に重要です。このトピックのガイダンスに従ってください。

レプリケーションフィルタリングオプションの効果は、データベース名が識別される方法のため、バイナリロギング形式によって異なります。 ステートメントベースの形式では、DML ステートメントは、USE ステートメントステートメントで指定された現行のデータベースに基づいて処理されます。 行ベースの形式では、DML ステートメントは、変更されたテーブルが存在するデータベースに基づいて処理されます。 DDL ステートメントは、バイナリロギング形式に関係なく、常に USE ステートメントで指定された現在のデータベースに基づいてフィルタ処理されます。

複数のテーブルを含む操作は、バイナリロギング形式に応じて、レプリケーションフィルタリングオプションの影響を受けることもあります。 監視する操作には、複数テーブルの UPDATE ステートメント、トリガー、外部キーのカスケード、複数のテーブルを更新するストアドファンクション、および 1 つ以上のテーブルを更新するストアドファンクションを起動する DML ステートメントが含まれます。 これらの操作によってフィルタ処理されたテーブルとフィルタ処理されたテーブルの両方が更新される場合、結果はバイナリロギング形式によって異なる可能性があります。

特に混合バイナリロギング形式 (binlog_format=MIXED) を使用している場合、レプリケーションフィルタがバイナリロギング形式に関係なく一貫して動作することを保証する必要がある場合は、テーブルレベルのレプリケーションフィルタリングオプションのみを使用し、データベースレベルのレプリケーションフィルタリングオプションは使用しないでください。 また、フィルタ処理されたテーブルとフィルタ処理されたテーブルの両方を更新する複数テーブル DML ステートメントは使用しないでください。

データベースレベルとテーブルレベルのレプリケーションフィルタの組合せを使用する必要があり、これらを可能なかぎり一貫して動作させる場合は、次のいずれかの方法を選択します:

1. DDL ステートメントに行ベースのバイナリロギング形式 (binlog_format=ROW) を使用する場合は、USE ステートメントを使用してデータベースを設定し、データベース名を指定しないでください。 レプリケーションフィルタリングとの一貫性を向上させるために、行ベースのバイナリロギング形式に変更することを検討できます。 バイナリロギング形式の変更に適用される条件については、セクション5.4.4.2「バイナリログ形式の設定」 を参照してください。

2. ステートメントベースまたは混合バイナリロギング形式 (binlog_format=STATEMENT または MIXED) を DML ステートメントと DDL ステートメントの両方に使用する場合は、USE ステートメントに依存し、データベース名は使用しません。 また、フィルタ処理されたテーブルとフィルタ処理されたテーブルの両方を更新する複数テーブル DML ステートメントは使用しないでください。

例 17.7 --replicate-ignore-db オプションおよび --replicate-do-table オプション

レプリケーションソースサーバーでは、次のステートメントが発行されます:

USE db1;
CREATE TABLE t2 LIKE t1;
INSERT INTO db2.t3 VALUES (1);

レプリカには、次のレプリケーションフィルタリングオプションが設定されています:

replicate-ignore-db = db1
replicate-do-table = db2.t3

DDL ステートメント CREATE TABLE は、前述の USE ステートメントで指定されているように、db1 にテーブルを作成します。 db1 が現在のデータベースであるため、レプリカは --replicate-ignore-db = db1 オプションに従ってこのステートメントを除外します。 この結果は、レプリケーションソースサーバー上のバイナリロギング形式と同じです。 ただし、DML INSERT ステートメントの結果は、バイナリロギング形式によって異なります:

• 行ベースのバイナリロギング形式がソース (binlog_format=ROW) で使用されている場合、レプリカは、db2 という名前のテーブルが存在するデータベースを使用して INSERT 操作を評価します。 最初に評価されるデータベースレベルのオプション --replicate-ignore-db = db1 は適用されません。 テーブルレベルのオプション --replicate-do-table = db2.t3 は適用されるため、レプリカはテーブル t3 に変更を適用します。

• ステートメントベースのバイナリロギング形式がソース (binlog_format=STATEMENT) で使用されている場合、レプリカは、USE ステートメントによって db1 に設定され、変更されていないデフォルトのデータベースを使用して INSERT 操作を評価します。 したがって、データベースレベルの --replicate-ignore-db = db1 オプションによると、操作は無視され、変更はテーブル t3 に適用されません。 ステートメントがすでにデータベースレベルのオプションと一致し、無視されたため、テーブルレベルのオプション --replicate-do-table = db2.t3 はチェックされません。

レプリカで --replicate-ignore-db = db1 オプションが必要であり、ソースでステートメントベース (または混在) のバイナリロギング形式を使用する必要もある場合は、次のように INSERT ステートメントからデータベース名を省略し、代わりに USE ステートメントに依存することで、結果を整合させることができます:

USE db1;
CREATE TABLE t2 LIKE t1;
USE db2;
INSERT INTO t3 VALUES (1);

この場合、レプリカは常にデータベース db2 に基づいて INSERT ステートメントを評価します。 操作がステートメントベースまたは行ベースのバイナリ形式のどちらで記録されているかにかかわらず、結果は同じままです。