Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.1Mb
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  ...  /  サーバーがレプリケーションフィルタリングルールをどのように評価するか

17.2.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 DATABASEDROP 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)

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

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

注記

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

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


User Comments
  Posted by Paul Appleyard on September 12, 2006
Just a note on replicating QUALIFIED statements.

Because I'm lazy and never select db's before running a query, I use qualified statements for ALL my queries. ie:

Instead of:

USE foofar;
INSERT INTO fling VALUES( 'w00t' );

I do:

INSERT INTO foofar.fling VALUES( 'w00t' );

This was a problem when I went to set up replication. After much research, I found the solution (works with 4 and up):

In your MASTER my.cnf file, DO NOT put any 'binlog-ignore-db' or 'do-db' options. Any db's you wish to not replicate will be handled in the slave conf file ..

In your SLAVE my.cnf file, use a 'replicate-ignore-db=<db>' for all the databases from the master you wish to stop from replicating to the slave.

For all the db's you DO wish to replicate, use a 'replicate-wild-do-table=<db>.%' line.

You end up with a lot of extraneous binlog data for those tables you previously set to ignore in the master conf, but it saves you having to go through all your code and add 'use database' functionality
  Posted by Dewey Gaedcke on July 2, 2008
I believe the comment immediately above ONLY applies to Statement based replication. Row based should work fine with db.qualified queries.
Sign Up Login You must be logged in to post a comment.