17.2.3 サーバーがレプリケーションフィルタリングルールをどのように評価するか

[+/-]

17.2.3.1 データベースレベルレプリケーションオプションおよびバイナリロギングオプションの評価

17.2.3.2 テーブルレベルレプリケーションオプションの評価

17.2.3.3 レプリケーションルールの適用

マスターサーバーがそのバイナリログにステートメントを書き込まない場合は、ステートメントは複製されません。サーバーがステートメントのログを記録すると、ステートメントはすべてのスレーブに送信され、各スレーブはそれを実行するか無視するかを判断します。

マスターでは、--binlog-do-db および --binlog-ignore-db オプションを使用してバイナリロギングを制御することで、どのデータベースが変更ログを記録するかを制御できます。これらのオプションを評価するときにサーバーが使用するルールの詳細は、セクション17.2.3.1「データベースレベルレプリケーションオプションおよびバイナリロギングオプションの評価」を参照してください。複製するデータベースとテーブルを制御するためにこれらのオプションを使用しないでください。代わりに、スレーブ上でフィルタリングを使用してスレーブで実行されるイベントを制御してください。

スレーブ側では、マスターから受け取るステートメントを実行するか無視するかの判断は、スレーブの起動時に使用される --replicate-* オプションに従って行われます。セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。

--replicate-* オプションがないときは (もっとも単純なケース)、スレーブはマスターから受け取るすべてのステートメントを実行します。そうでない場合は、結果は指定された特定のオプションに依存します。

データベースレベルオプション (--replicate-do-db、--replicate-ignore-db) が最初にチェックされます。このプロセスの説明については、セクション17.2.3.1「データベースレベルレプリケーションオプションおよびバイナリロギングオプションの評価」を参照してください。データベースレベルオプションが使用されない場合は、オプションチェックはテーブルレベルオプション (使用されている場合がある) のチェックに進みます (これらの説明については、セクション17.2.3.2「テーブルレベルレプリケーションオプションの評価」を参照してください)。1 つ以上のデータベースレベルオプションが使用されているけれども、一致するものがない場合は、ステートメントは複製されません。

データベースにのみ影響するステートメントの場合 (つまり、CREATE DATABASE、DROP DATABASE、および ALTER DATABASE)、データベースレベルオプションは --replicate-wild-do-table オプションより常に優先されます。つまり、このようなステートメントの場合、適用するデータベースレベルオプションがない場合にかぎり、--replicate-wild-do-table オプションがチェックされます。これは、MySQL の以前のバージョンの動作からの変更です。スレーブが --replicate-do-db=dbx --replicate-wild-do-table=db%.t1 で起動された場合には、ステートメント CREATE DATABASE dbx は複製されませんでした。(Bug #46110)

オプションセットに何が影響するかの判断を簡素化するために、「do」 と 「ignore」 オプション、またはワイルドカードと非ワイルドカードオプションを混在させるのを避けることをお勧めします。

--replicate-rewrite-db オプションが指定された場合、それらは --replicate-* フィルタリングルールがテストされる前に適用されます。

注記

MySQL 5.6 では、すべてのレプリケーションフィルタリングオプションは、lower_case_table_names システム変数の影響を含めて、MySQL サーバー内のほかの場所のデータベースおよびテーブルの名前に適用されるものと同じ、大文字と小文字の区別に関するルールに従います。

これは以前のバージョンの MySQL からの変更点です。(Bug #51639)