レプリケーションソースサーバーがステートメントをバイナリログに書き込まない場合、ステートメントはレプリケートされません。 サーバーがステートメントをログに記録する場合、ステートメントはすべてのレプリカに送信され、各レプリカはステートメントを実行するか無視するかを決定します。

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

レプリカ側では、ソースから受け取ったステートメントを実行するか無視するかに関する決定は、レプリカが起動された --replicate-* オプションに従って行われます。 セクション17.1.6「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。 これらのオプションによって制御されるフィルタは、CHANGE REPLICATION FILTER ステートメントを使用して動的に設定することもできます。 このようなフィルタを制御するルールは、--replicate-* オプションを使用して起動時に作成されるか、CHANGE REPLICATION FILTER によってレプリカサーバーが実行されている間に作成されるかに関係なく同じです。 レプリケーションフィルタは、グループレプリケーション用に構成された MySQL サーバーインスタンス上のグループレプリケーション固有のチャネルでは使用できません。これは、一部のサーバーでトランザクションをフィルタすると、グループが一貫性のある状態で承諾に到達できなくなるためです。

最も単純なケースでは、--replicate-* オプションがない場合、レプリカはソースから受信したすべてのステートメントを実行します。 そうでない場合は、結果は指定された特定のオプションに依存します。

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

データベースにのみ影響するステートメントの場合 (つまり、CREATE DATABASE、DROP DATABASE、および ALTER DATABASE)、データベースレベルオプションは --replicate-wild-do-table オプションより常に優先されます。 つまり、このようなステートメントの場合、適用するデータベースレベルオプションがない場合にかぎり、--replicate-wild-do-table オプションがチェックされます。

特定のオプションセットにどのような影響があるかを簡単に判断できるように、do-* オプションと ignore-* オプション、またはワイルドカードを含むオプションとそれ以外のオプションを混在させないことをお薦めします。

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