レプリカは、次の 2 つの条件のいずれかに該当する場合にのみ、テーブルオプションをチェックして評価します:
一致するデータベースオプションが見つからなかった。
1 つ以上のデータベースオプションが見つかり、前のセクションで説明したルール (セクション17.2.5.1「データベースレベルレプリケーションオプションおよびバイナリロギングオプションの評価」を参照) に従って、「実行」条件に達していると評価された。
まず、予備的な状態として、レプリカはステートメントベースのレプリケーションが有効かどうかをチェックします。 その場合、ステートメントがストアドファンクション内で発生すると、レプリカはステートメントを実行して終了します。 行ベースレプリケーションが有効になっている場合、レプリカはソースのストアドファンクション内でステートメントが発生したかどうかを認識しないため、この条件は適用されません。
ステートメントベースレプリケーションの場合、レプリケーションイベントがステートメントを表現します (あるイベントを構成するすべての変更が単一 SQL ステートメントに関連付けられています)。行ベースレプリケーションの場合、各イベントが単一テーブル行内の変更を表現します (このため、UPDATE mytable SET mycol = 1 などの単一ステートメントが多くの行ベースイベントを生成する場合があります)。 イベントの観点から見ると、テーブルオプションを検査するプロセスは行ベースおよびステートメントベースレプリケーションの両方について同じです。
この時点に到達すると、テーブルオプションがない場合、レプリカは単にすべてのイベントを実行します。 --replicate-do-table または --replicate-wild-do-table オプションがある場合は、それが実行すべきイベントの場合、イベントはこれらのいずれかに一致する必要があります。そうでない場合、無視されます。 --replicate-ignore-table または --replicate-wild-ignore-table オプションがある場合、これらのオプションのいずれかに一致するものを除いてすべてのイベントが実行されます。
次のステップでは、この評価について詳しく説明します。 開始ポイントは、セクション17.2.5.1「データベースレベルレプリケーションオプションおよびバイナリロギングオプションの評価」 で説明されているように、データベースレベルのオプションの評価の最後です。
-
テーブルレプリケーションオプションはありますか。
はい. 手順 2 に進みます。
いいえ. 更新を実行して終了します。
-
どのロギング形式が使用されますか。
STATEMENT. 更新を実行するステートメントごとに残りのステップを実行します。
ROW. テーブルの行を更新するたびに残りのステップを実行します。
-
--replicate-do-tableオプションはありますか ?-
はい. テーブルはそれらのいずれかに一致しますか ?
はい. 更新を実行して終了します。
いいえ. 手順 4 に進みます。
いいえ. 手順 4 に進みます。
-
-
--replicate-ignore-tableオプションはありますか ?-
はい. テーブルはそれらのいずれかに一致しますか ?
はい. 更新を無視して終了します。
いいえ. 手順 5 に進みます。
いいえ. 手順 5 に進みます。
-
-
--replicate-wild-do-tableオプションはありますか ?-
はい. テーブルはそれらのいずれかに一致しますか ?
はい. 更新を実行して終了します。
いいえ. 手順 6 に進みます。
いいえ. 手順 6 に進みます。
-
-
--replicate-wild-ignore-tableオプションはありますか ?-
はい. テーブルはそれらのいずれかに一致しますか ?
はい. 更新を無視して終了します。
いいえ. 手順 7 に進みます。
いいえ. 手順 7 に進みます。
-
-
テストする別のテーブルがありますか。
はい. ステップ 3 に戻ります。
いいえ. 手順 8 に進みます。
-
--replicate-do-tableまたは--replicate-wild-do-tableオプションはありますか ?はい. 更新を無視して終了します。
いいえ. 更新を実行して終了します。
単一の SQL ステートメントが --replicate-do-table または --replicate-wild-do-table オプションに含まれるテーブルと、--replicate-ignore-table または --replicate-wild-ignore-table オプションで無視される別のテーブルの両方で動作する場合、ステートメントベースのレプリケーションは停止します。 レプリカは、(レプリケーションイベントを形成する) 完全なステートメントを実行または無視する必要があり、論理的にはこれを実行できません。 DDL ステートメントは常に有効なロギング形式に関係なくステートメントとして記録されるため、これは DDL ステートメントの行ベースのレプリケーションにも適用されます。 インクルードされたテーブルと無視されたテーブルの両方を更新でき、正常にレプリケートされる唯一のタイプのステートメントは、binlog_format=ROW でログに記録された DML ステートメントです。