マスタサーバ がバイナリ ログにステートメント (クエリ) を記憶しない場合、ステートメントは複製されません。サーバがステートメント (クエリ) をログする場合、そのステートメントはすべてのスレーブに送信されます。そして、それぞれのスレーブ (受信側) が受信したステートメントを実行するかどうかを決めます。
ノート：バイナリへのログをコントロールするには、--binlog-do-db
および --binlog-ignore-db
のオプションを使用して、どのデータベースがバイナリ
ログにイベントを書き込むかをマスタでコントロールできます。これらのオプションを評価する際にサーバが使用するルールの詳細は、項4.11.4. 「バイナリ ログ」
を参照してください。注意：スレーブで実行しているイベントをコントロールするには、スレーブにフィルターを使います。複製されたデータベースおよびテーブルをコントロールする目的で、これらのオプションを使用しないでください。
スレーブ側では、マスタから受信したクエリを実行するかどうかの決定は、スレーブ起点の
--replicate-* オプション (ルール)
に従って行われます。（項5.1.3. 「レプリケーションのオプションと変数」を参照してください。）以下の手順に従い、スレーブはこれらのオプションを評価します。最初に、データベース
レベルのオプションを比較し、続いてテーブル
レベルのオプションを比較します。
--replicate-*
オプションがないなど、ルールが単純な場合は、この手順により、スレーブがマスタから受信するすべてのクエリを実行するという結果を生成します。それ以外には、この結果は設定オプションに依存します。ノート：「do」
および 「ignore」
のオプション、またはワイルド
カードなどのオプションの混在を避けることで、ルール
セットの設定効果を決定する作業が簡素化します。
ステージ 1. データベース オプションの評価
このステップでは、データベース設定を特定する--replicate-do-db
または --replicate-ignore-db
ルールがあるかどうかを、スレーブが確認します。
No:クエリを許可して、テーブル比較のステップへ進む。
-
Yes:クエリを許可もしくは無視する決定を行うために、
--binlog-do-dbおよび--binlog-ignore-dbのオプションと同様のルールを使用して、オプションをテストする。(以下の選択をするために) テスト結果を確認する。Permit:すぐには実行しない。決定を保留して、テーブル比較ステップに進む。
Ignore:クエリを無視して終了する。
このステージでは、後続のオプション確認するという目的で、クエリを許可または無視するようになります。そのため、クエリは許可されますが、実際にはまだ実行されません。後続のステージで、テーブル オプションを比較するステップへ進みます。
ステージ 2. テーブル オプションの評価
最初に、前段階として、スレーブ側でクエリ ベースのレプリケーションが可能かどうかをテストします。それが可能であり、格納された機能内でクエリが発生する場合、そのクエリを実行して、終了します。メモ： 行ベースのレプリケーションを可能にした場合、スレーブ側はマスタ内の格納機能でクエリが発生したことを知らないため、その条件は有効になりません。
次に、スレーブ側でテーブル オプションをテストし、それらを評価します。サーバがこのポイントに達する際に、テーブルにオプションがない場合、サーバはすべてのクエリを実行します。テーブルに 「do」 ルールが複数ある場合には、実行するクエリはそのテーブルのルールのうち １ つと一致する必要があります。一致しない場合は、無視されます。「ignore」 ルールが複数ある場合、 「ignore」 ルールに一致するものを除き、すべてのクエリが実行されます。以下のステップで、この評価の手順を説明します。
-
--replicate-*-tableルールはあるかNo:テーブルに制限がない。すべてのクエリが一致する。クエリを実行して、終了する。
-
Yes:テーブルに制限がある。更新対象のテーブルと既存ルールを比較する。複数のテーブルを更新する可能性がある。次のステップで、それぞれのテーブルに一致するルールを探す。ノート：この場合、クエリ ベースまたは行ベースのどちらでレプリケーションが可能になるかによって、その後の動作は左右されます。
クエリ ベースのレプリケーション:次のステップに進み、表示された順序でテーブル ルールの評価を開始する。 (注意：最初にノン ワイルド、続いて、ワイルド)更新対象のテーブルだけがルールと比較される。(例： クエリが
INSERT INTO sales SELECT * FROM pricesの場合、salesだけがルールとの比較対照)複数のテーブル (マルチ テーブルのクエリ) が更新対象の場合、「do」 または 「ignore」 で一致する最初のテーブルが比較される。つまり、サーバ側は、最初のテーブルをルールと比較する。その比較で、決定できない場合は、2番目のテーブルがルールとの照合になる。-
行ベースのレプリケーション:テーブル行すべての変更は別々にフィルタにかかる。対象テーブルが複数の場合、それぞれのテーブルが別々に、ルールに従ってフィルタにかかる。ルールと変更内容をよっては、更新が実行される部分と実行しない部分がある。行ベースのレプリケーションでは、クエリ ベースのレプリケーションで正確に複製されないケースを正確に処理する。以下は、
fooデータベースのテーブルを複製する必要があると仮定した場合の例。mysql>
USE bar;mysql>INSERT INTO foo.sometable VALUES (1);
-
--replicate-do-tableルールはあるかNo:次のステップへ進む。
-
Yes:テーブルはどれかと一致するか。
No:次のステップへ進む。
Yes:クエリを実行して、終了する。
-
--replicate-ignore-tableルールはあるか。No:次のステップへ進む。
-
Yes:テーブルはどれかと一致するか。
No:次のステップへ進む。
Yes:クエリを無視して、終了する。
-
--replicate-wild-do-tableルールはあるか。No:次のステップへ進む。
-
Yes:テーブルはどれかと一致するか。
No:次のステップへ進む。
Yes:クエリを実行して、終了する。
-
--replicate-wild-ignore-tableルールはあるか。No:次のステップへ進む。
-
Yes:テーブルはどれかと一致するか。
No:次のステップへ進む。
Yes:クエリを無視して、終了する。
-
--replicate-*-tableルールはどれにも一致しなかった。これらのルールでテストするテーブルはほかにあるか。-
No:すべての対象テーブルをテストしたが、どのルールにも一致しない。
--replicate-do-tableまたは--replicate-wild-do-tableルールはあるかNo:テーブルの 「do」 ルールがない。ゆえに 「do」 との明確な一致は不要。クエリを実行して、終了する。
Yes:テーブルに 「do」 ルールがある。それと明確に一致したものだけでクエリを実行。クエリを無視して、終了する。
Yes:ループする。
-
例：
-
--replicate-*ルールがまったくない。スレーブは、マスタから受信するすべてのクエリを実行する。
-
--replicate-*-dbルールはあるが、テーブル ルールがない。スレーブはデータベースのルールを使用して、クエリを許可または無視する。そしてテーブルでの制限がないので、スレーブはデータベースのルールによって許可したすべてのクエリを実行する。
-
--replicate-*-tableルールはあるが、データベース ルールがないデータベースに条件がないため、すべてのクエリがデータベース比較の段階で許可される。スレーブは、テーブルのルールを基にすべてのクエリを実行または無視する。.
-
データベースとテーブルのルールが混在する場合。
スレーブはデータベースのルールを使用して、クエリを許可または無視する。そして、テーブルのルールに従って、スレーブはデータベースのルールで許可したすべてのクエリを実行する。場合によって、このプロセスは直感に反する結果のようなものを生成する可能性があります。その場合、以下のルール セットを検討する。
[mysqld] replicate-do-db = db1 replicate-do-table = db2.mytbl2
db1がデフォルトのデータベースであり、スレーブがクエリを受信する場合。INSERT INTO mytbl1 VALUES(1,2,3);
このデータベース
db1は、データベース比較の段階で、--replicate-do-dbルールに一致します。よって、アルゴリズムはテーブル比較の段階でプロセスされます。テーブルのルールがない場合、クエリは実行されます。ルールには 「do」 のテーブル ルールが含まれるため、クエリを実行する場合は、そのクエリが一致するものである必要があります。この場合のクエリは、一致しないため、無視されます。db1のどのテーブルでも同様の場合があります。
