レプリケーションオプションを評価する場合、レプリカはまず、適用される --replicate-do-db または --replicate-ignore-db オプションがあるかどうかを確認します。 --binlog-do-db または --binlog-ignore-db を使用する場合、プロセスは似ていますが、オプションはソースでチェックされます。
一致がチェックされるデータベースは、処理されるステートメントのバイナリログ形式によって異なります。 ステートメントが行形式を使用してログに記録されている場合、データが変更されるデータベースはチェックされるデータベースです。 ステートメントがステートメントの形式を使用してログに記録されている場合、デフォルトのデータベース (USE ステートメントで指定) がチェックされるデータベースになります。
行形式を使用してログに記録できるのは DML ステートメントのみです。 DDL ステートメントは、binlog_format=ROW の場合でも、常にステートメントとして記録されます。 したがって、すべての DDL ステートメントは、ステートメントベースのレプリケーションのルールに従って常にフィルタ処理されます。 つまり、DDL ステートメントを適用するには、USE ステートメントを使用してデフォルトのデータベースを明示的に選択する必要があります。
レプリケーションの場合、関連するステップは次のとおりです:
-
どのロギング形式が使用されますか。
STATEMENT. デフォルトのデータベースをテストします。
ROW. 変更の影響を受けるデータベースをテストします。
-
--replicate-do-dbオプションはありますか ?-
はい. データベースはこれらのいずれかと一致しますか。
はい. ステップ 4 に進みます。
いいえ. 更新を無視して終了します。
いいえ. 手順 3 に進みます。
-
-
--replicate-ignore-dbオプションはありますか ?-
はい. データベースはこれらのいずれかと一致しますか。
はい. 更新を無視して終了します。
いいえ. 手順 4 に進みます。
いいえ. 手順 4 に進みます。
-
-
テーブルレベルレプリケーションオプションがある場合、それらの検査に進みます。 これらのオプションの検査方法の説明については、セクション17.2.5.2「テーブルレベルレプリケーションオプションの評価」を参照してください。
重要この段階でまだ許可されているステートメントは、実際にはまだ実行されていません。 ステートメントはすべてのテーブルレベルオプション （ある場合） が検査されるまで実行されず、そのプロセスの結果がステートメントの実行を許可します。
バイナリロギングの場合、関連する手順の一覧は次のとおりです。
-
--binlog-do-dbまたは--binlog-ignore-dbオプションはありますか ?はい. 手順 2 に進みます。
いいえ. ステートメントのログを記録して終了します。
-
デフォルトデータベースはありますか (データベースが
USEで選択されていますか) ?はい. 手順 3 に進みます。
いいえ. ステートメントを無視して終了します。
-
デフォルトデータベースがあります。
--binlog-do-dbオプションはありますか ?-
はい. それらのいずれかがデータベースに一致しますか ?
はい. ステートメントのログを記録して終了します。
いいえ. ステートメントを無視して終了します。
いいえ. 手順 4 に進みます。
-
-
--binlog-ignore-dbオプションのいずれかがデータベースに一致しますか ?はい. ステートメントを無視して終了します。
いいえ. ステートメントのログを記録して終了します。
ステートメントベースロギングの場合、CREATE DATABASE、ALTER DATABASE、および DROP DATABASE ステートメントに適用されるルールにだけ例外が作成されています。 これらの場合には、更新のログを記録または無視するかを判断するときに、作成、変更、またはドロップされるデータベースがデフォルトデータベースを置き換えます。
--binlog-do-db は「ほかのデータベースを無視する」ことを意味する場合があります。 たとえば、ステートメントベースロギングを使用するときに、--binlog-do-db=sales だけで動作するサーバーは、デフォルトデータベースが sales ではないバイナリログステートメントに書き込みません。 同じオプションで行ベースロギングを使用するときは、サーバーは sales 内のデータを変更する更新のみのログを記録します。