この章は、MySQL サーバのレプリケーションを完全に行うためのセットアップについて説明します。レプリケーションのセットアップには様々な方法があり、レプリケーションをどのようにセットアップするか、そしてマスタのデータベースにデータがすでに存在するかどうかにより、その方法が変わります。

すべてのレプリケーション セットアップに必要とされる一般的なタスクは次の通りです。

ここまでの基本的なオプションを設定後、次に示すレプリケーション セットアップの手順に従います。これにはいくつかの方法があります。

MySQL レプリケーション セットアップの管理者は、この節を十分に読み、項12.6.1. 「マスタ サーバをコントロールする SQL ステートメント」 および 項12.6.2. 「スレーブ サーバをコントロールする SQL ステートメント」 のすべてのステートメントを試行してください。項5.1.3. 「レプリケーションのオプションと変数」 に示すレプリケーションのスタートアップ オプションに関しても十分な理解が必要です。

mysql> GRANT REPLICATION SLAVE ON *.*
    -> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';

[mysqld]
log-bin=mysql-bin
server-id=1

[mysqld]
server-id=2

shell> mysql -h master < fulldb.dump

Warning: You should set server-id to a non-0 value if master_host
is set; we will force server id to 2, but this MySQL server will
not act as a slave.

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master_host_name',
    ->     MASTER_USER='replication_user_name',
    ->     MASTER_PASSWORD='replication_password',
    ->     MASTER_LOG_FILE='recorded_log_file_name',
    ->     MASTER_LOG_POS=recorded_log_position;

バイナリ ログに書き込まれたイベントをマスタが読み込み、スレーブで処理することでレプリケーションが成り立ちます。このイベントは記録されるイベントに従って様々なフォーマットで記録されます。このフォーマットは次の通りです。

MySQL 5.1.12 から、ミックス ベース レプリケーション (MBR) がデフォルト フォーマットで、指定のない限り、すべてのレプリケーション環境に対応します。

ステートメント ベースと行ベースのレプリケーション比較で、それぞれのメリット、デメリットを確認できます。詳細は 項5.1.2.3. 「ステートメント ベースと行ベースのレプリケーション比較」 を参照してください。

MySQL クラスタ レプリケーション (MySQL Cluster Replication) は行ベース レプリケーションに最適です。詳細は 項14.10. 「MySQL Cluster レプリケーション」 を参照してください。

MySQL の典型的なステートメント ベース レプリケーションには、格納ルーチンやトリガを複製するときに問題が生じる可能性があります。これらの問題は、MySQL の行ベース レプリケーションを代用して回避できます。問題に関する詳細は 項17.4. 「ストアドルーチンとトリガのバイナリログ」 を参照してください。

MySQL をソースから構築した場合、 --without-row-based-replication オプションで configure を 呼び出さない限り、行ベース レプリケーションはデフォルトで使用できます。

mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 1;

mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 2;

mysql> SET GLOBAL binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 3;

mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';

ここでは、スレーブ レプリケーション サーバに使用するオプションを説明します。これらのオプションはコマンド ラインまたはオプション ファイルで指定します。

マスタとスレーブ (複数) では、server-id オプションを使用して、ユニークなレプリケーション ID を設置します。それぞれのサーバには、 1 から 2³² ? 1 までの範囲のユニークな正整数を使用します。それぞれの ID は別の ID と重複しないようにしてください。例：server-id=3

バイナリ ロギングをコントロールするためにマスタ サーバに使用できるオプションは 項4.11.4. 「バイナリ ログ」 を参照してください。

スレーブ サーバ レプリケーション オプションのいくつかは、特別の方法で扱います。それぞれが無視される、という意味においては、スレーブの起動時に master.info ファイルが存在し、オプションの値を含む場合です。次のオプションはこのように扱います。

MySQL 5.1 の master.info ファイル フォーマットには、SSL オプションに対応する値を含みます。さらに、ファイルフォーマットは、その最初のラインとしてラインの数をファイルに含みます。(項5.5.5. 「レプリケーション リレーとステータス ファイル」 参照) 古いバージョン (MySQL 4.1.1以前) から新しいバージョンにアップグレードする場合は、新しいサーバは master.info ファイルを新しいフォーマットへ起動とともに自動的にアップグレードします。しかし、新しいサーバを古いバージョンにダウングレード (格下げ) する場合には、古いサーバを起動させる前に、まず手動で最初のラインを取り除く必要があります。

master.info ファイルが存在しない状態でスレーブ サーバを起動する場合には、オプション ファイルまたはコマンド ラインで指定されたルールの値が適用されます。これは、一番最初にレプリケーション スレーブとしてサーバを起動するとき、または RESET SLAVE の実行後にスレーブをシャットダウンし再起動した場合などに起こります。

master.info ファイルがスレーブ起動時に存在する場合は、サーバはそのファイル内にあるものを使用し、ファイルにリストされた値に呼応するオプションを無視します。このため、master.info の値に呼応するスタートアップ オプションとは異なる値でスレーブ サーバを起動する場合には、その異なる値が影響を与えることはありません。つまりサーバは master.info ファイルを使用し続けるということです。異なる値を使用するには、master.info ファイルを取り除いてから再起動するか、または CHANGE MASTER TO ステートメントを使用して、スレーブ実行中に値をリセットすることをお勧めします。

my.cnf ファイルで次のルールを指定したとします。

[mysqld]
master-host=some_host

レプリケーション スレーブとして初めてサーバを起動するとき、そのサーバは my.cnf ファイルからのオプションを読み込み、使用します。そして、master.info ファイルの値を記録します。そして、この次にサーバを起動するときには、master.info ファイルからの値をマスタ ホスト値として読み込み、オプション ファイルの値は無視されます。my.cnf ファイルを修正する場合に、some_other_host で別のサーバ ホストを指定するときには、この変更は反映されません。よって、CHANGE MASTER TO を使用します。

サーバが、記述したばかりのスタートアップ オプションよりも、既存 master.info ファイルを優先するため、これらの値をスタートアップ オプションに使用するよりも、CHANGE MASTER TO ステートメントを使用して値を指定する方が賢明です。詳細は、項12.6.2.1. 「CHANGE MASTER TO 構文」 を参照してください。

以下は、スレーブ サーバを設定するときのスタートアップ オプションを拡大的にしようした場合の例です。

[mysqld]
server-id=2
master-host=db-master.mycompany.com
master-port=3306
master-user=pertinax
master-password=freitag
master-connect-retry=60
report-host=db-slave.mycompany.com

次のリストは、レプリケーションをコントロールするオプションと変数について説明します。これらのオプションの多くは、CHANGE MASTER TO ステートメントを使用してサーバ実行中にリセットできます。しかし、--replicate-* のようなオプションは、スレーブ サーバが起動するときにだけセットできます。

レプリケーション開始後は、管理者側のタスクをあまり必要としない実行になります。レプリケーション環境にもよりますが、定期的、日常的、またはできる限り、それぞれのスレーブのレプリケーション ステータスをチェックすることをお勧めします。

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: master1
                Master_User: root
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000004
        Read_Master_Log_Pos: 931
             Relay_Log_File: slave1-relay-bin.000056
              Relay_Log_Pos: 950
      Relay_Master_Log_File: mysql-bin.000004
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        Replicate_Ignore_DB: 
         Replicate_Do_Table: 
     Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 0
                 Last_Error: 
               Skip_Counter: 0
        Exec_Master_Log_Pos: 931
            Relay_Log_Space: 1365
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
            Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: 0
1 row in set (0.01 sec)

mysql> SHOW PROCESSLIST \G;
*************************** 4. row ***************************
     Id: 10
   User: root
   Host: slave1:58371
     db: NULL
Command: Binlog Dump
   Time: 777
  State: Has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL

mysql> SHOW SLAVE HOSTS;
+-----------+--------+------+-------------------+-----------+
| Server_id | Host   | Port | Rpl_recovery_rank | Master_id |
+-----------+--------+------+-------------------+-----------+
|        10 | slave1 | 3306 |                 0 |         1 | 
+-----------+--------+------+-------------------+-----------+
1 row in set (0.00 sec)

mysql> STOP SLAVE;

mysql> STOP SLAVE IO_THREAD;

mysql> START SLAVE;

Replication with a single slave

図 5.1. Replication with a single slave

Replication with multiple slaves

図 5.2. Replication with multiple slaves

Replication with multiple masters

図 5.3. Replication with twin masters

Multiple masters

It is safe to connect servers in a circular master/slave relationship if you use the --log-slave-updates option. That means that you can create a setup as shown in 図?5.5. 「Replication with multiple masters in a chain topology」.

図 5.4. Replication with multiple masters in a circular topology

However, many statements do not work correctly in this kind of setup unless your client code is written to take care of the potential problems that can occur from updates that occur in different sequence on different servers.

Server IDs are encoded in binary log events, so server A knows when an event that it reads was originally created by itself and does not execute the event (unless server A was started with the --replicate-same-server-id option, which is meaningful only in rare cases). Thus, there are no infinite loops. This type of circular setup works only if you perform no conflicting updates between the tables. In other words, if you insert data in both A and C, you should never insert a row in A that may have a key that conflicts with a row inserted in C. You should also not update the same rows on two servers if the order in which the updates are applied is significant.

TODO

図 5.5. Replication with multiple masters in a chain topology

レプリケーションは、バックアップ ソリューションとして、マスタからスレーブへデータを複製してデータ スレーブをバックアップできます。スレーブはマスタで稼動しているオペレーションに影響を与えることなく、一時停止やシステム終了ができるため、通常はマスタ データベースのシャツとダウンしなければならない、ライブデータのスナップショットを効率的に生成できます。

データベースをどのようにバックアップするかは、データベースのサイズに依存します。また、データだけをバックアップするのか、予期していないイベントが発生したときにスレーブを立て直すためにデータとレプリケーション スレーブの状態をバックアップするのかなどによって異なります。これには、2 つの選択肢があります。

マスタのデータをバックアップするようにするソリューションとしてレプリケーションを利用する場合には、データベースのサイズが超過している場合は、mysqldump ツールを使うことをお勧めします。詳細は 項5.3.1.1. 「mysqldump を使用したバックアップ」 を参照してください。

mysqldump が実用的ではない大型のデータベースには、生データのファイルをバックアップできます。生データ ファイルのオプションを使用するということは、スレーブ障害のイベントでスレーブを再生できるバイナリ ログとリレー ログをバックアップするということです。詳細は 項5.3.1.2. 「生データのバックアップ」 を参照してください。

レプリケーション プロセスは、マスタのソース テーブルとマスタの複製テーブルが異なるエンジンを使用しているかどうかを重視しません。実際には、システム変数 storage_engine と table_type は複製されません。

このレプリケーション プロセスでの優位性を異なるエンジン タイプでのレプリケーション シナリオに役立てることができます。たとえば、スケール アウトのシナリオ (項5.3.3. 「スケールアウトのレプリケーション」 参照) では、通常、トランザクション機能をマスタの InnoDB テーブルに使いますが、データがリード オンリーということから、トランザクション サポートを必要としないスレーブの MyISAM を使用できます。データ ロギングの環境でレプリケーションの場合には、スレーブの Archive ストレージ エンジンを使うことも可能です。

イニシャル レプリケーション プロセスをどのように設定するかによって、マスタとスレーブでエンジンが異なる場合の設定は異なります。

レプリケーション ソリューションをすでに実行している場合に既存のテーブルを別のエンジン タイプに変更するには、次のステップに従います。

storage_engine と table_type 変数は複製されませんが、エンジンの仕様を含む CREATE TABLE および ALTER TABLE ステートメントはスレーブに正確に複製されます。CSV テーブルがある場合には次を実行します。

mysql> ALTER TABLE csvtable Engine='MyISAM';

例示のステートメントはスレーブに複製され、そのスレーブのエンジン タイプは MyISAM になります。CSV のほかに、スレーブのテーブル型をエンジンにすでに変更していた場合も同様です。 マスタとスレーブでエンジンに違いを付ける場合に、新たなテーブルを作成するときは、マスタの storage_engine 変数を扱うときには十分に注意してください。

mysql> CREATE TABLE tablea (columna int) Engine=MyISAM;

次のフォーマットを使用します。

mysql> SET storage_engine=MyISAM;
mysql> CREATE TABLE tablea (columna int);

複製後、storage_engine 変数は無視され、CREATE TABLE ステートメントはスレーブのデフォルト エンジン タイプで実行になります。

スケールアウト ソリューションとしてレプリケーションを使用できるため、データベース クエリ負荷を複数のデータベース サーバに分けることができす。ただし、これには一定の制約があります。

レプリケーションは、ひとつのマスタから複数のスレーブに分散できるため、読み込み頻度が高く、書き込みと更新の頻度が低い場合でのスケールアウトに最適です。ウェブサイトなどはこのカテゴリに該当し、ユーザによるウェブサイトの閲覧、情報取得または入力、製品の検索などに対応します。

書き込みが必要な場合に、ウェブ サーバがレプリケーション マスタと通信する一方で、レプリケーション スレーブが読み込み分を担当します。 このシナリオでのレプリケーション レイアウトのサンプルは 図?5.6. 「スケールアウト レプリケーションのパフォーマンス向上の概略図」 を参照してください。

図 5.6. スケールアウト レプリケーションのパフォーマンス向上の概略図

データベース アクセスを担うコードの一部を適当にモジュール化するときは、それを複製したセットアップで実行するよう変換すると、スムーズかつ簡単です。マスタにすべての書き込み分を、そしてマスタまたはスレーブに読み込み分を送るには、データベース アクセスの実装を変更します。 コードでこのレベルの抽出を確保できない場合は、クリーン アップなどのモチベーション向上にもなるので、複製システムをセットアップすることをお勧めします。 次の関数を実装してラッパー ライブラリまたはモジュールを作成することから始めます。

関数名safe_ の safe_ は、関数がすべてのエラー条件を処理することを意味します。 ここでは、読み取りのための接続、書き込みのための接続、読み取り実行、書き込み実行で統合インタフェースを持つことが重要です。

次に、ラッパー ライブラリを使用するようにクライアントコードを変換します。このプロセスは困難ですが、長期的に見ると有意義です。 ここで説明したアプローチを使用するアプリケーションはすべて、マスタ・スレーブ構成の利点を活用できます。 このコードは保守が非常に簡単で、トラブルシューティング オプションの追加にも手間がかかりません。 つまり、1 つか 2 つの関数を修正するだけで、各クエリに所要時間をログしたり、どのクエリがエラーの原因になったかを特定できます。

コード作成の経験が豊かであれば、MySQL の標準ディストリビューションに含まれている replace ユーティリティを使用して変換タスクを自動化することも可能です。または独自の変換スクリプトを作成することもできますが、その際にはプログラミング コードが一貫して認識できるスタイルが理想的です。そうでない場合は、書き換えることをお勧めしますが、少なくとも 一貫したスタイルに整えてください。

単一のマスタで異なるデータベースを異なるスレーブに複製する場合には、たとえば、異なる販売データを別の部署へ配布すときにはデータ分析の負荷を低減することになります。このレイアウトは 図?5.7. 「別々の DB を複数のホストに複製するレプリケーション概略図」 を参照してください。

図 5.7. 別々の DB を複数のホストに複製するレプリケーション概略図

マスタとスレーブを普通に構成し、セパーレションを行い、replicate-wild-do-table コンフィギュレーションをそれぞれのスレーブに使用して、それぞれのスレーブが処理するバイナリ ログ ステートメントを制限します。

たとえば、図?5.7. 「別々の DB を複数のホストに複製するレプリケーション概略図」 で示すようにセぱレーションをサポートするには、START SLAVEを使用して複製を可能にする前に、次のようにそれぞれのスレーブを構成します。

レプリケーションを開始する前にスレーブ’と同期しなければならないデータがある場合は、いくつかのオプションがあります。

このコンフィギュレーションのスレーブは、マスタからのバイナリ ログ全体へ転送しますが、構成したデータベースとテーブルに適用する範囲のバイナリ ログのイベントだけを実行します。

マスタに接続したスレーブの数が増えると、若干の負荷も同様に増え、それぞれのスレーブがマスタへのクライアント コネクションを使い切ります。さらに、それぞれのスレーブはマスタのバイナリ ログの完全なコピーを受け取る必要があるめ、マスタのネットワーク負荷も同様に増え、ボトルネックを生成しシステム全体の性能が低下します。

スケール アウト ソリューションなどで、マスタに接続しているスレーブの数が多いときは、それに対応してマスタでの処理量は膨大になるため、レプリケーション プロセスのパフォーマンスを改善することをお勧めします。

レプリケーション プロセスのパフォーマンスを改善する方法の一つには、よりディープなレプリケーション ストラクチャを構築することがあります。これは、マスタが一つのスレーブにだけ複製を行い、ほかのスレーブは個別のレプリケーション要求に対応するプライマリ スレーブに接続するという方法です。このストラクチャのサンプルは 図?5.8. 「追加のレプリケーション ホストでパフォーマンス改善」 を参照してください。

図 5.8. 追加のレプリケーション ホストでパフォーマンス改善

これを実現するには、MySQL インスタンスを次のように設定します。

このソリューションは、プライマリ マスタのクライアント負荷だけでなくネットワーク インターフェイス負荷を減らすことができ、プライマリ マスタのパフォーマンス全体を改善するダイレクト データベース ソリューションとして活用できます。

マスタのレプリケーション プロセスに追いつくことに支障をきたしているスレーブがある場合には、次のオプションで対応します。

障害が発生した場合にマスタとスレーブ間でのフェイルオーバに対応する正式なソリューションは現在の段階ではありません。現在利用可能な機能内では、マスタとスレーブ (または複数のスレーブ) をセットアップし、状況を把握するためにマスタを監視するスクリプトを作成することが挙げられます。そのときには、アプリケーションとスレーブに障害を認識した場合にマスタを変更するよう指示します。

CHANGE MASTER TO ステートメントを使用して、いつでもスレーブにマスタを変えるように指示することが重要です。スレーブはマスタのデータベースがスレーブとの互換性を保持しているかどうかを確認することができないため、新しいマスタが指定するログと場所からイベントを実行し始めます。フェイルオーバの状況で、グループ内すべてのサーバが同一のバイナリ ログからの同一のイベントを実行しています。そのため、イベント元の変更がデータベース ストラクチャまたは整合性に影響することのないように慎重に扱う必要があります。

スレーブを --log-bin はあるけれども --log-slave-updates はないという組み合わせで実行します。この方法では、スレーブで RESET MASTER と CHANGE MASTER TO を実行し、別のスレーブで STOP SLAVE を実行すると同時に、スレーブがマスタになる準備ができます。図?5.9. 「レプリケーションを活用した冗長性、初期ストラクチャ」 のストラクチャで例示を参照してください。

図 5.9. レプリケーションを活用した冗長性、初期ストラクチャ

この図では、MySQL Master にはマスタ データベースがあり、MySQL Slave のコンピュータはレプリケーション スレーブ、そして Web Client マシンは読み書き込みをするデータベースという関係になります。通常スレーブに接続していて読み込みだけを行うウェブ クライアントは、障害イベントで新しいサーバへは切り替わらないため、図には含まれていません。読み書き込みのスケールアウト ソリューション ストラクチャに関しては、項5.3.3. 「スケールアウトのレプリケーション」 を参照してください。

MySQL Slave のそれぞれ (Slave 1、Slave 2、Slave 3) は、 --log-slave-updates を伴わずに、--log-bin だけで実行しているスレーブです。--log-slave-updates の指定がなければマスタからスレーブが受信したアップデートがバイナリ ログに記録されないため、それぞれのスレーブのバイナリ ログは最初から空です。 何らかの原因により MySQL Master が利用不可になる場合、複数あるスレーブの中から新しいマスタを選ぶことができます。たとえば、Slave 1 を選択する場合、すべての Web Clients を Slave 1 にリダイレクトして、そこのバイナリ ログ にアップデートを記録します。つまり、Slave 2 と Slave 3 は Slave 1 から複製することになります。

--log-slave-updates なしで実行するという理由には、複数のスレーブの中から一つが新たなマスタに切り替わるときに、アップデートを 2 度受信しないようにするためです。たとえば、Slave 1 は --log-slave-updates するようになると、Master から受信するアップデートを自分のバイナリ ログに書き込みます。Slave 2 が Master から Slave 1 に切り替わった場合は、Master からアップデートをすでに受信しているにも関わらず、Slave 1 から再度、アップデートを受信するという結果になります。

すべてのスレーブがリレー ログ内のクエリを処理したかどうかを確認してください。それぞれのスレーブでは、STOP SLAVE IO_THREAD を発行して、Has read all relay log を確認できまるまで、SHOW PROCESSLIST の出力をチェックします。 すべてのスレーブでこれが確認できたら、これらを新たな設定として構成できます。マスタに昇格した Slave 1 のスレーブでは、STOP SLAVE と RESET MASTER を発行します。

別のスレーブ Slave 2 と Slave 3 では、STOP SLAVE とCHANGE MASTER TO MASTER_HOST='Slave1' を使います。 ('Slave 1' が、Slave1 の実際のホスト名を表示する場合).CHANGE MASTER には、Slave 2 または Slave 3 から Slave 1 へのどのようにするかに関するすべての情報を付加します。(user、password、port など) CHANGE MASTER では、Slave 1 のバイナリ ログ名や読み込み先のバイナリ ログ位置を指定する必要はありません。CHANGE MASTER のデフォルトでは、一番初めのバイナリ ログ、そして位置は 4 です。そして最後に、Slave 2 と Slave 3 で START SLAVE を使用します。

新たなレプリケーションを整えた後に、Web Client が Slave 1 へクエリを送信するよう指示します。この時点から、Web Client が Slave 1 へ送信したすべてのアップデート クエリが Slave 1 のバイナリ ログに書き込まれ、すでに Master は機能していないため、Slave 1 へ送信したすべてのアップデート クエリが含まれることになります。

サーバ ストラクチャの結果は 図?5.10. 「レプリケーションを活用した冗長性、マスタ障害後」 に示す通りです。

図 5.10. レプリケーションを活用した冗長性、マスタ障害後

Master マスタの再稼動するときは、Slave 2 と Slave 3 に発行した通りに、同様の CHANGE MASTER を発行してください。これにより、Master はスレーブの S1 になり、ダウン後に実行された Web Client の書き込みをすべてピック アップします。

たとえば、マスタが最もパワフルなマシンであるなど物理的な理由で、Master をマスタへ戻すには、Slave 1 を利用不可の状態、Master が新たなマスタになる、というようにそれぞれの立場を逆にしてこの手順を繰り返します。 この手順では、Slave 1、Slave 2 そして Slave 3 を Master のスレーブにする前に、Master に RESET MASTER を実行することを忘れないでください。これをしないと、Master が動かなくなる前の古い Web Client 書き込みをピック アップすることになります。

複数スレーブとマスタは同期していません。スレーブのいくつかは他のスレーブよりも前に出ていることがあります。つまり、前述の例で示したコンセプトが機能しない可能性があるということです。しかし、実情では、複数スレーブのリレー ログがマスタからそれほど遅れをとらないので、この方法が適用できるとの考えに基づいています。そのため、この方法が確証できるものではないことに留意してください。

動的な DNS エントリをマスタに持たせると、マスタの位置に応じてアプリケーションを調節することをお勧めします。bind で、 DNS を動的に更新するnsupdate を使います。

クライアントとサーバの SSL と同様に　SSL 接続を使用してレプリケーションをセットアップします。マスタに使用する適切なセキュリティ証明書、ならびに同類の証明書を同一の認証機関から、それぞれのサーバ用に取得します。

レプリケーションに必要なバイナリ ログの暗号化トランスファに SSL を使用するには、まず最初に SSL ネットワークをサポートするようにマスタをセットアップします。SSL 用にコンパイルしていない、あるいは構成していないなどの理由で、マスタが SSL 接続をサポートしない場合は、SSL 接続を介してレプリケーションを行うことはできません。

サーバとクライアントの SSL 接続 をセットアップに関する詳細は、項4.8.7.2. 「SSL接続」 を参照してください。

SSL をマスタで利用可能にするには、適切な証明書を用意して、次に示すコンフィギュレーション オプションを mysqld セクション内にあるマスタのコンフィギュレーションに付加します。

ssl-ca=cacert.pem
ssl-cert=server-cert.pem
ssl-key=server-key.pem

オプションは次の通りです。

スレーブでは、SSL 情報の設定に 2 つのオプションがあります。スレーブの証明書をスレーブのコンフィギュレーション ファイルの client セクションに付加するか、もしくは CHANGE MASTER ステートメント を使って SSL 情報を明確に指定します。

前述のオプションを使用して、次の文字列をスレーブのコンフィギュレーション ファイルの client セクションに付加します。

[client]
ssl-ca=cacert.pem
ssl-cert=server-cert.pem
ssl-key=server-key.pem

スレーブ サーバ を再稼動し、--skip-slave をスレーブがマスタへ接続しないようにします。CHANGE MASTER を使用して、マスタのコンフィギュレーションを指定し、master_ssl オプションを使用して、SSL 接続ができるようにします。

mysql> CHANGE MASTER TO \
    MASTER_HOST='master_hostname', \
    MASTER_USER='replicate', \
    MASTER_PASSWORD='password', \
    MASTER_SSL=1;

CHANGE MASTER コマンドで、SSL 証明ルールを指定するには、SSL ルールを付加します。

CHANGE MASTER TO \
      MASTER_HOST='master_hostname', \
      MASTER_USER='replicate', \
      MASTER_PASSWORD='password', \
      MASTER_SSL=1, \
      MASTER_SSL_CA = 'ca_file_name', \
      MASTER_SSL_CAPATH = 'ca_directory_name', \
      MASTER_SSL_CERT = 'cert_file_name', \
      MASTER_SSL_KEY = 'key_file_name';

マスタの情報が更新されたら、スレーブのレプリケーション プロセスを開始します。

mysql> START SLAVE;

SHOW SLAVE STATUS を使用して、SSL 接続が完了したかどうかを確認します。

CHANGE MASTER TO 構文に関する詳細は項12.6.2.1. 「CHANGE MASTER TO 構文」 を参照してください。

レプリケーション中に使用する SSL 接続 を強化する場合は、REPLICATION SLAVE 権限でユーザを作成し、そのユーザ に REQUIRE_SSL ルールを使用します。

mysql> GRANT REPLICATION SLAVE ON *.*
    -> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass' REQUIRE SSL;

SQL レベルでのレプリケーション互換性では通常、マスタおよびスレーブの両方のサーバでサポートする機能を必要とします。マスタ サーバの機能がMySQLのバージョン内で使用可能である場合は、古いバージョンのスレーブに複製することはできません。このような非互換はシリーズ間で起こる可能性が高いため、MySQL 5.1 から 5.0 への複製はできません。しかし、非互換はシリーズ内でのレプリケーションでも発生する可能性があります。例: SLEEP() 機能は、MySQL 5.0.12 以降のバージョンでのみ使用できます。そのため、マスタ サーバでこの機能を使用する場合に、サーバが MySQL 5.0.12 以前のバージョンの場合には複製できません。

5.1 とこれより古いバージョンの MySQL でレプリケーションを行う場合は、その古いバージョンの MySQL レファレンス マニュアルで複製機能に関する情報を確認してから、実行してください。

以下のセクションでは、なにがサポートされているか、そしてなにがサポートされていないかを説明するとともに、複製中に起こる可能性のある問題と状況について説明します。レプリケーションのInnoDBに特化した情報に関しては、項13.5.6.5. 「InnoDB と MySQL 複製」を参照してください。

既存の MySQL でのステートメント ベースの複製に関しては、保存したルーチンとトリガの複製で問題が発生する可能性があります。この問題は、MySQL の行ベースの複製を行うことで回避できます。この問題に関する詳細は、項17.4. 「ストアドルーチンとトリガのバイナリログ」 を参照してください。行ベース レプリケーションに関する詳細は、項5.1.2. 「レプリケーション フォーマット」を参照してください。

CREATE TABLE t2 LIKE t1;
ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY;
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;

DROP t1;
ALTER TABLE t2 RENAME t1;

INSERT INTO t VALUES(UUID());

SET @my_uuid = UUID();
INSERT INTO t VALUES(@my_uuid);

SET @my_uuid1 = UUID(); @my_uuid2 = UUID();
INSERT INTO t VALUES(@my_uuid1),(@my_uuid2);

INSERT INTO t2 SELECT UUID(), * FROM t1;

MySQL 5.1 に実装したバイナリ ログ形式は、以前のバージョンで使用していたものとは大きく異なり、キャラクタ セットの処理、LOAD DATA INFILE、タイム ゾーンに関しては特に異なります。

一般的なルールとしては、マスタとスレーブを同じバージョンで実行しているときにレプリケーションを設定してください。(MySQL 5.1, 5.0 または 4.1 など)異なるバージョン間でレプリケーションを実行する必要がある場合は、クライアントにマスタと同等またはそれ以上のバージョンを使用していることを確認してください。(例: マスタで 4.1.23、スレーブで 5.0.24)

レプリケーションはMySQL 5.0 および 5.1 のマスタとサーバであれば、コンビネーションに関係なく、正確にできます。マスタとスレーブで異なるグローバル キャラクタ セットの変数を使用している場合や、マスタとスレーブで異なるグローバル タイム ゾーンの変数を使用している場合でも同様です。これはマスタとスレーブのどちらか、もしくはその両方がMySQL 4.1 以前を使用している場合には該当しません。

レプリケーションの互換性は継続的に向上するため、最新の MySQL バージョンを使用することをお勧めします。マスタとスレーブで同一のバージョンを使用することも効果的です。アルファまたはベータ バージョンをマスタとスレーブで使用している場合には、プロダクション バージョンにアップグレードすることをお勧めします。マスタで使用中のものが新しく、スレーブで使用中のものが古い場合にレプリケーションを行うと失敗するケースが多分にあります。一般的には、MySQL 5.1.x を実行しているスレーブは、マスタで使用しているバージョンが古い (MySQL 3.23、4.0 または 4.1) でも使用できますが、その逆の場合はできません。

前項の情報はプロトコル レベルでのレプリケーション互換に関連します。しかし、SQL レベルでの互換性問題など、他にも制限があります。たとえば、複製したステートメントが5.0ではなく 5.1 で利用可能なSQLの機能を使用している場合は、5.1 のマスタは、5.0 のスレーブに複製できません。その問題に関しては、項5.4.1. 「レプリケーション機能と既知問題」を参照してください。

レプリケーション セットアップに関連するサーバをアップグレードする場合、アップグレード手順は使用中のサーバのバージョンおよびアップグレードしようとしているバージョンによって異なります。

この項は、MySQL 3.23、4.0 または 4.1 から MySQL 5.1 へのレプリケーションをアップグレードするときに該当します。4.0 のサーバは 4.0.3 以降である必要があります。

マスタを初期の MySQL リリース シリーズから 5.1 にアップグレードする場合、そのマスタのすべてのスレーブで同一の5.1.x リリースを使用していることを確認してください。そうでない場合は、まずスレーブをアップグレードしてください。それぞれのスレーブをアップグレードするには、まずスレーブらをシャットダウンし、それぞれを適切な 5.1.x にアップグレードし、再起動させ、複製を再開します。5.1 のスレーブは、アップグレード前に書き込まれたリレー ログを読み込むことができ、そこに含まれているステートメントを実行することができます。アップグレードが行われた後にスレーブによって作成されたリレーログは、5.1 形式です。

スレーブをアップグレードした後は、マスタをシャットダウンし、スレーブと同様にマスタを同一の 5.1.x リリースでアップグレードし、再起動します。5.1 のマスタは、アップグレード前に書き込まれたリレー ログを読み込むことができ、それらを 5.1 のスレーブに送信することができます。スレーブは、古い形式を認識し、それに応じて正確に処理します。アップグレード後にマスタによって作成されたバイナリ ログは、5.1 形式です。これも同様に、5.1 スレーブが認識します。

言い換えれば、MySQL 5.1 へアップグレードする際には特に注意することはありません。ただし、マスタを 5.1 にアップグレード可能な状態にする前に、スレーブが MySQL 5.1 である必要があります。ノート：5.1 から古いバージョンへダウングレード (格下げ) することはできません。5.1 のバイナリ ログまたはリレー ログでの処理が完了したことを確認してから、ダウングレードで先に進む前に、それらを削除してください。

レプリケーション セットアップを以前のバージョンにダウングレードすることは、ステートメント ベースから行ベースのレプリケーションに変更した後、あるいは最初に行ベースのステートメントが binlog に書き込まれた後にはできません。詳細は 項5.1.2. 「レプリケーション フォーマット」 を参照してください。

Questions

Questions and Answers

6.4.4.1: スレーブは常にマスタに接続している必要がありますか。

いいえ、その必要はありません。スレーブは何時間でも、あるいは何日間でもシャットダウンしておいたり、非接続にしておいても、再接続してマスタの更新に追いつくことができます。たとえば、マスタとスレーブの関係をダイヤルアップ リンクでセットアップし、リンクアップを散発的かつ短時間に設定できます。この場合、任意の時点でスレーブがマスタと同期している保証がないため、これに対応する特別な対策を投じてください。

この対策としては、スレーブに情報が複製されていない場合は、マスタからバイナリ ログを削除しないでください。非同期のレプリケーションは、スレーブが最後に読み込んだレプリケーション ステートメントのバイナリ ログを読み込みできる場合に限ります。

6.4.4.2: マスタをネットワーク化しなければ、レプリケーションを実行できませんか。

はい。マスタのネットワーク化してください。ネットワーク化できない場合は、スレーブがマスタに接続してバイナリ ログを転送することができません。skip-networking ルールがコンフィギュレーション ファイルで実行可能になっているかどうかを確認してください。

6.4.4.3: スレーブがマスタと比較してどれだけ遅れているかを知る方法はありますか。または、スレーブによって複製が行われた最後のクエリ日を知る方法はありますか。

SHOW SLAVE STATUS の Seconds_Behind_Master カラムを参考にしてください。詳細は 項5.5.1. 「レプリケーション実装の詳細」 を参照してください。

スレーブの SQL スレッドでマスタから読み込んだイベントを実行する場合、このスレッドは自らのタイムをイベントのタイムスタンプに修正します。ノート:　TIMESTAMP が十分に複製される理由はここにあります。SHOW PROCESSLIST 出力の Time カラムに表示される数字は、スレーブ SQL スレッドに対する秒数であり、　最後に複製したイベントのタイムスタンプとスレーブ マシンの実際の時刻の差です。これを使用して、最後に複製したイベントの日付を特定できます。注意: スレーブがマスタから切断してから 1 時間後に再接続した場合、SHOW PROCESSLIST の Time カラムでスレーブ SQL スレッドが 3600 の値を表示する場合があります。これは、スレーブは 1 時間遅れたクエリを実行しているためです。(タイムスタンプから 1 時間経過している)

6.4.4.4: スレーブが追いつくまでマスタの更新をブロックする方法はありますか。

次の手順を使用します。

6.4.4.5: 二方向レプリケーションをセットアップするときに注意する点はありますか。

MySQL レプリケーションでは、現在のところ、分散 （サーバ間の） 更新の原子性を保証するマスタとスレーブ間のロッキング プロトコルをサポートしていません。つまり、クライアント A が co-master 1 に更新を行い、それを co-master 2 に伝播する前に、クライアント B が co-master 2 に更新を行う場合、クライアント A の更新が co-master 1 で更新したものとは異なった更新になる可能性があります。この場合、co-master 2 からの更新すべてが伝播した後であっても、クライアント A の更新が co-master 2 に伝わるとき、co-master 1 とは異なるテーブルが生成されます。このため、どのような順序でも更新が安全に行われるという確証がある場合またはクライアントコードで更新順序の不正に対処できる場合以外では、二方向レプリケーションで 2 つのサーバをチェーン状に設定しないでください。

更新については、二方向レプリケーションは、それほどあるいはまったく、パフォーマンス向上には役立ちません。1 つのサーバで更新を行うときと同様に、どのサーバでも同等量での更新を行う必要があります。別のサーバから発生した更新が 1 つのスレーブ スレッドでシリアル化されるため、ロックの競合が少なくなる、という違いがあります。この利点も、ネットワーク遅延によっては相殺されてしまう可能性があります。

6.4.4.6: レプリケーションを使用してシステムのパフォーマンスを改善する方法はありますか。

1 つのサーバをマスタとしてセットアップし、書き込みのすべてをそこで直接行います。そして割当量とスペースが許容する限り多くのスレーブで構成し、マスタと複数のスレーブで読み取りを分散します。スレーブ側での速度を向上するには、--skip-innodb、--low-priority-updates および --delay-key-write=ALL でスレーブを起動することもできます。この場合、スレーブは InnoDB テーブルの代わりに非トランザクションの MyISAM テーブルを使用して、トランザクション オーバーヘッドを取り除きながら、速度を上げます。

6.4.4.7: パフォーマンス改善レプリケーションを用いたアプリケーションを作成するときに、クライアントコードはどのように準備しますか。

スケール アウト ソリューションとしてレプリケーションを使用するためのガイドは、項5.3.3. 「スケールアウトのレプリケーション」 を参照してください。

6.4.4.8: MySQL のレプリケーションで、どれくらいのシステム パフォーマンスの向上が期待できますか、そしてそれはいつ行うものですか。

MySQL レプリケーションは、読み取りが頻繁に行われ、書き込みはそれほどでもないシステムに最も適しています。理論的には、単一のマスタや複数のスレーブのセットアップを使用することで、システムを拡張することができます。つまりネットワーク帯域幅を超えるか、更新負荷がマスタで処理しきれないポイントに到達するまでは、スレーブの数をシステムに追加できます。

追加する利点がなくなるまでいくつのスレーブを追加できるか、あるいはサイトのパフォーマンスをどれだけ向上できるかを判断するには、クエリ パターンを知る必要があります。そして読み取りには毎秒ごとの読み取り、または reads、書き取りには writes で、マスタとスレーブの通常のスループットの関係をベンチマークして、実証的に決定します。ここでは、例として、仮想システムのレプリケーションでの単純化した計算を示します。

システム負荷が 10% の書き込みと 90% の読み取りで構成され、reads が 1200 ? 2 × writes であると仮定します。つまり、書き込みがなければシステムは毎秒 1,200 の読み取りを実行します。書き込みの平均は読み取り平均の 2 倍かかります。この関係はリニア (直線的) です。マスタとそれぞれスレーブの能力は同じで、1 マスタと N スレーブがあると想定します。それぞれのサーバ （マスタまたはスレーブ） は次のようになります。

reads = 1200 ? 2 × writes

reads = 9 × writes / (N + 1) (読み取りは分散、書き込みはすべてのサーバへ)

9 × writes / (N + 1) + 2 × writes = 1200

writes = 1200 / (2 + 9/(N+1))

最後の数式は、N スレーブ毎の最大数を示し、 ここでは、毎分 1,200 の可能な最大読み込み割合と書き込みあたり 9 の読み込み割合と仮定しています。

この分析は、次の結論を導き出します。

注意: この計算ではシステム帯域を無限として想定しています。そのため、実際のシステムでは重要であるファクタを無視している可能性があります。多くの場合、N アプリケーション スレーブを追加した場合の結果を正確に予測するために、上記と同様の計算を行うことは適していません。このため、レプリケーションによってシステムのパフォーマンスが改善するかどうか、またどの程度改善するか、以下の質問の答えを参照して判断してください。

6.4.4.9: 冗長性と高可用性を実現するために、レプリケーションをどのように使用すればよいですか。

どのように冗長性を向上するかは、使用しているアプリケーションと状況により異なります。(自動フェールオーバを伴う) 高可用性ソリューションは、アクティブなモニタリングに加え、オリジナルのMySQL サーバからそのスレーブへのフェールオーバを行うためのカスタム スクリプトまたはサード パーティのツールのいずれかを必要とします。

この処理を手動で行うには、失敗したスレーブから事前構成のスレーブに移行できることを確認してください。(失敗時にアプリケーションとスレーブにマスタの変更を指示するスクリプトを作成する)。これを行うには、新たなサーバと通信するアプリケーションで代替するか、または、失敗したサーバから新たなサーバに MySQL サーバの DNS を調節します。

詳細とソリューション例に関しては 項5.3.6. 「フェイルオーバでのマスタ切り替え」 を参照してください。

6.4.4.10: マスタ サーバのロギング形式が、ステートメント ベースまたは行ベースのどちらであるかを確かる方法はありますか。

binlog_format システム変数の値を確認します。

mysql> SHOW VARIABLES LIKE 'binlog_format';

その値は STATEMENT または ROW のどちらかを示します。

6.4.4.11: スレーブが行ベースのレプリケーションを使用するように設定する方法はありますか。

スレーブは自動的にどちらの形式を使用するかを認識します。

6.4.4.12: スレーブのマシンへの複製で、GRANT および REVOKE のステートメントを抑制する方法はありますか。

サーバを --replicate-wild-ignore-table=mysql.% オプションで起動します。.

6.4.4.13: 混在のオペレーティング システムでレプリケーションを実行できますか。(例：マスタが Linux、スレーブが Mac OS X と Windows の場合)

はい、できます。

6.4.4.14: 混在のハードウェア アーキテクチャでレプリケーションを実行できますか。(マスタが 64-bit、スレーブが32-bit のマシンの場合など)

はい、できます。

指示に従って設定して、レプリケーションを設定しても機能しない場合は、エラー ログのメッセージをまず調べてください。多くの問題は、ログを調べることにより解決します。

エラー ログから問題の発生源が特定できない場合は、次の事柄を確かめます。

ユーザによるエラーではないことが確認でき、レプリケーションが全く機能しないまたは不安定である場合は、バグとして報告してください。バグ問題を解決するには、より多くの情報を必要とします。そのため、バグ報告を行う際には、時間をかけて、できるだけ詳細な情報を送信してください。

そのバグを実証する再現可能なテスト ケースがある場合には、項1.7. 「質問またはバグの報告」 を参照して、それをバグ用のデータベースに入れてください。「phantom」 問題 (説明できない問題など) の場合は、次の手順に従ってください。

問題からの証拠を収集した後は、まず全く別のテスト ケースとして、それを隔離してください。そして、より多くの情報とともに、バグ用のデータベースに入れてください。詳細は 項1.7. 「質問またはバグの報告」 で参照してください。

MySQL レプリケーションには 3 つのスレッドが関連しています。マスタには 1 スレッド、スレーブでは2つのスレッドがあります。START SLAVE ステートメントが発行されると、I/O スレッドがスレーブに作成されます。このスレッドはマスタに接続し、マスタのバイナリ ログに記録されているクエリの送信を要求します。そして、マスタが、そのバイナリ ログを送信するために、スレッドを作成します。このスレッドは、マスタの SHOW PROCESSLIST 出力で Binlog Dump として確認できます。スレーブの I/O スレッドは、マスタの Binlog Dump スレッドが送信するアップデートを読み取り、それをスレーブのデータ ディレクトリにあるrelay logs と呼ばれるローカル ファイルにコピーします。そして、スレーブがリレー ログを読み取りそれに含まれるクエリを実行するために、3 つ目の スレッドである SQL スレッドを作成します。

マスタとスレーブ間の 1 接続につき、3 つのスレッドがあります。つまり、マスタには複数のスレーブがあり、マスタは接続したスレーブごとにスレッドを作成します。そして、このスレーブには I/O スレッドおよび SQL スレッドの両方が存在します。

スレーブは2つのスレッドを使い、マスタからのアップデートを読み取りと実行を 2 つの独立したタスクに区切ります。これにより、クエリの実行が遅い場合でも、クエリの読み取りというタスクが遅くなることはありません。たとえば、スレーブ サーバが一時的に稼動していない場合に、SQL スレッドが遅れていたとしても、スレーブが起動するときに は、I/O スレッドがマスタのすべてのバイナリ ログ内容をすばやく取り出します。つまり、SQL スレッドが取り出したクエリのすべてを実行し終える前にスレーブが停止する場合でも、I/O スレッドの方ですべてを取り出しているため、クエリのコピーがスレーブのリレー ログで安全に格納されていることになり、スレーブが起動するときには、そのクエリを実行する準備ができているということです。このため、マスタはスレーブの読み出しを待つ必要がなくなり、マスタサーバがマスタ元のバイナリ ログをより早く削除することを可能にします。

SHOW PROCESSLIST ステートメントを使用すると、レプリケーションに関するマスタ側およびスレーブ側での処理内容を確認できます。以下で、SHOW PROCESSLIST. の出力で、この 3 つのスレッドがどのように表示されるかを例示します。

マスタサーバでは、SHOW PROCESSLIST の出力は以下のようになります。

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 2
   User: root
   Host: localhost:32931
     db: NULL
Command: Binlog Dump
   Time: 94
  State: Has sent all binlog to slave; waiting for binlog to
         be updated
   Info: NULL

ここで、スレッド Id 2 は 接続したスレーブの Binlog Dump レプリケーション スレッドです。State の情報は、すべてのアップデート (更新情報) がスレーブに送信されたことを示し、マスタは次の更新情報を待機している状態です。マスタサーバの Binlog Dump スレッドが表示されない場合は、このレプリケーションは実行されていないことを意味します。?つまり、この時点でスレーブが接続されていないということです。

スレーブ サーバでは、SHOW PROCESSLIST の出力は以下のようになります。

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 10
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 11
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Has read all relay log; waiting for the slave I/O
         thread to update it
   Info: NULL

この情報は、 スレッド Id 10 が I/O スレッドであり、マスタサーバと通信していることを示し、スレッド Id 11 は SQL スレッドであり、 リレー ログ に格納されたアップデートを処理中であることを示します。SHOW PROCESSLIST が実行された場合、スレッドの両方がアイドル状態であり、次のアップデートを待機しています。

Time カラムの値は、マスタと比較した場合に、スレーブがどれくらい遅れているかを示します。詳しくは 項5.4.4. 「レプリケーション FAQ」 を参照してください。

以下の一覧は、マスタの Binlog Dump スレッドの State カラムに表示される一般的な状態です。Binlog Dump スレッドがマスタサーバに表示されない場合、このレプリケーションは実行されていないことを意味します。? つまり、この時点でスレーブは接続していないということです。

以下の一覧は、スレーブの I/O スレッドの State カラムに表示される一般的な状態です。これは、SHOW SLAVE STATUS 出力の Slave_IO_State カラムにも表示され、このステートメントを使用して現状を把握できます。

以下の一覧は、スレーブの SQL スレッドの State カラムに表示される一般的な状態です。

I/O スレッドの State カラムはクエリ文字列を表示する場合があります。これは、スレッドがリレー ログからイベントを読み取り、クエリを抽出して、そのクエリを実行中であることを示します。

レプリケーション中にMySQL サーバは、マスタからリレーされたバイナリ ログの保持に使うファイルをいくつか作成し、リレーされたログ内からステータスと位置に関する情報を記録します。このプロセスでは 3 種類のファイル タイプを使用します。

以下は、この 3 種類のファイルとレプリケーション プロセスの関係です。master.info ファイルは、マスタ バイナリ ログ内のポイントを保持し、このログはマスタからの読み込みです。そのリレー ログにこの読み出されたイベントを記憶します。relay.info ファイルは、リレー ログ内にあるクエリの位置を記録し、このクエリは実行済みです。

マスタサーバ がバイナリ ログにステートメント (クエリ) を記憶しない場合、ステートメントは複製されません。サーバがステートメント (クエリ) をログする場合、そのステートメントはすべてのスレーブに送信されます。そして、それぞれのスレーブ (受信側) が受信したステートメントを実行するかどうかを決めます。

ノート：バイナリへのログをコントロールするには、--binlog-do-db および --binlog-ignore-db のオプションを使用して、どのデータベースがバイナリ ログにイベントを書き込むかをマスタでコントロールできます。これらのオプションを評価する際にサーバが使用するルールの詳細は、項4.11.4. 「バイナリ ログ」 を参照してください。注意：スレーブで実行しているイベントをコントロールするには、スレーブにフィルターを使います。複製されたデータベースおよびテーブルをコントロールする目的で、これらのオプションを使用しないでください。

スレーブ側では、マスタから受信したクエリを実行するかどうかの決定は、スレーブ起点の --replicate-* オプション (ルール) に従って行われます。（項5.1.3. 「レプリケーションのオプションと変数」を参照してください。）以下の手順に従い、スレーブはこれらのオプションを評価します。最初に、データベース レベルのオプションを比較し、続いてテーブル レベルのオプションを比較します。

--replicate-* オプションがないなど、ルールが単純な場合は、この手順により、スレーブがマスタから受信するすべてのクエリを実行するという結果を生成します。それ以外には、この結果は設定オプションに依存します。ノート：「do」 および 「ignore」 のオプション、またはワイルド カードなどのオプションの混在を避けることで、ルール セットの設定効果を決定する作業が簡素化します。

ステージ 1. データベース オプションの評価

このステップでは、データベース設定を特定する--replicate-do-db または --replicate-ignore-db ルールがあるかどうかを、スレーブが確認します。

このステージでは、後続のオプション確認するという目的で、クエリを許可または無視するようになります。そのため、クエリは許可されますが、実際にはまだ実行されません。後続のステージで、テーブル オプションを比較するステップへ進みます。

ステージ 2. テーブル オプションの評価

最初に、前段階として、スレーブ側でクエリ ベースのレプリケーションが可能かどうかをテストします。それが可能であり、格納された機能内でクエリが発生する場合、そのクエリを実行して、終了します。メモ： 行ベースのレプリケーションを可能にした場合、スレーブ側はマスタ内の格納機能でクエリが発生したことを知らないため、その条件は有効になりません。

次に、スレーブ側でテーブル オプションをテストし、それらを評価します。サーバがこのポイントに達する際に、テーブルにオプションがない場合、サーバはすべてのクエリを実行します。テーブルに 「do」 ルールが複数ある場合には、実行するクエリはそのテーブルのルールのうち １ つと一致する必要があります。一致しない場合は、無視されます。「ignore」 ルールが複数ある場合、 「ignore」 ルールに一致するものを除き、すべてのクエリが実行されます。以下のステップで、この評価の手順を説明します。

例：