Skip navigation links
4.11.4 レプリケーションのセットアップ方法 »
Section Navigation      [Toggle]

4.11.3. レプリケーションの実装の詳細

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

注意: マスタには、接続しているスレーブサーバ 1 つにつき、1 つのスレッドがあります。

SHOW PROCESSLIST を使用すれば、レプリケーションに関するマスタおよびスレーブでの処理内容を確認できます。

以下の例で、3 つのスレッドが SHOW PROCESSLIST でどのように表示されるか示します。出力形式は、MySQL バージョン 4.0.15 の SHOW PROCESSLIST のものです。旧バージョンに比べて State カラムの内容が充実しています。

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

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

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

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 2 がマスタです。スレッド Id 10 はスレーブの I/O スレッドです。スレッド Id 11 はスレーブの SQL スレッドです。Time カラムの値により、スレーブがマスタと比較してどれくらい遅れているかわかります（see 項4.11.9. 「レプリケーション FAQ」）。

以下の一覧は、マスタの Binlog Dump スレッドの State カラムに表示される一般的な状態をまとめたものです。このスレッドがマスタサーバになければ、レプリケーションは実行されていないということです。

  • Sending binlog event to slave

    バイナリログはイベントで構成される。通常、イベントとは、クエリとその他の情報が組み合わさったものである。このステータスは、スレッドが、バイナリからイベントを読み取り、それをスレーブに送信中ということである。

  • Finished reading one binlog; switching to next binlog

    スレッドは 1 つのバイナリログファイルの読み取りを完了し、スレーブに送信するために次のファイルを開いている途中である。

  • Has sent all binlog to slave; waiting for binlog to be updated

    スレッドはすべてのバイナリログファイルの読み取りを完了し、アイドル状態である。スレッドは、マスタで実行される新しい更新クエリの結果として、バイナリログに新しいイベントが書き込まれるのを待っている。

  • Waiting to finalize termination

    スレッド停止中に瞬間的に発生する状態。

以下は、スレーブサーバの I/O スレッドの State カラムに表示される一般的な状態です。MySQL 4.1.1 以降、この状態は SHOW SLAVE STATUS 出力の Slave_IO_State カラムにも表示されます。そのため、SHOW SLAVE STATUS を使用するだけで現状を把握できます。

  • Connecting to master

    スレッドは、マスタへの接続を試行中である。

  • Checking master version

    マスタへの接続が確立した直後、瞬間的に発生する状態。

  • Registering slave on master

    マスタへの接続が確立した直後、瞬間的に発生する状態。

  • Requesting binlog dump

    マスタへの接続が確立した直後、瞬間的に発生する状態。スレッドは、バイナリログの内容をマスタに要求する。バイナリログファイルの名前と場所が最初にマスタに送信される。

  • Waiting to reconnect after a failed binlog dump request

    バイナリログダンプ要求が失敗した（接続切断によって）場合、スレッドはスリープ中この状態になる。スレッドは再試行する前に、master-connect-retry 秒間スリープ状態となる。

  • Reconnecting after a failed binlog dump request

    次に、スレッドはマスタへの再接続を試行する。

  • Waiting for master to send event

    スレッドは接続を完了し、バイナリログイベントの到着を待っている。マスタがアイドル状態であれば、この状態が長く続く場合がある。待機が slave_read_timeout 秒間続くと、タイムアウトが発生する。その時点でスレッドは接続が切断したと見なし、再接続を試行する。

  • Queueing master event to the relay log

    スレッドがイベントの読み取りを完了し、SQL スレッドがそのイベントを処理できるようにリレーログにコピー中である。

  • Waiting to reconnect after a failed master event read

    読み取り中にエラーが発生した（接続切断のため）。スレッドは接続を再試行する前に、master-connect-retry 秒間スリープ状態になる。

  • Reconnecting after a failed master event read

    次に、スレッドは再接続を試行する。接続が再度確立すると、状態は Waiting for master to send event になる。

  • Waiting for the slave SQL thread to free enough relay log space

    relay_log_space_limit の値が 0 以外に設定されているが、リレーログが大きくなりすぎて、その合計サイズがこの値を超えた。SQL スレッドがリレーログの内容を処理してリレーログファイルを削除し、領域に余裕ができるのを I/O スレッドは待っている。

  • Waiting for slave mutex on exit

    スレッド停止中に瞬間的に発生する状態。

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

  • Reading event from the relay log

    スレッドは、イベントを処理するため、リレーログからイベントを読み取っている。

  • Has read all relay log; waiting for the slave I/O thread to update it

    スレッドは、リレーログファイルのイベントをすべて処理し、I/O スレッドがリレーログに新しいイベントを書き込むのを待っている。

  • Waiting for slave mutex on exit

    スレッド停止中に瞬間的に発生する状態。

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

MySQL 4.0.2 より前は、スレーブの I/O スレッドと SQL スレッドは 1 つのスレッドにまとめられており、リレーログファイルは使用されていませんでした。 2 つのスレッドを使用する利点は、クエリの読み取りとクエリの実行を 2 つの独立したタスクに分けられることです。そのため、クエリ実行が遅くてもクエリ読み取りが遅くなることはありません。たとえば、スレーブサーバがしばらくの間実行していなかった場合でも、スレーブが起動すると、I/O スレッドがバイナリログのすべての内容をすばやく読み出します。SQL スレッドがかなり遅れていて、追いつくのに数時間かかるとしても影響を受けません。SQL スレッドが読み出したクエリをすべて実行する前にスレーブが停止しても、少なくとも I/O スレッドがクエリの読み出しを完了しているので、クエリのコピーはスレーブのリレーログにローカルで安全に保存されており、次回スレーブが起動したときに実行することができます。このため、マスタからはバイナリログを削除できます。スレーブがその内容を読み出するのを待つ必要はないからです。

デフォルトでは、リレーログの名前は host_name-relay-bin.nnn 形式になります。ここで、host_name はスレーブサーバのホスト名、nnn はシーケンス番号です。 連続したリレーログファイルでは、シーケンス番号は 001 から始まる連続した番号になります。 スレーブは、現在使用中のリレーログの記録をインデックスファイルに保持します。デフォルトのリレーログインデックスファイル名は host_name-relay-bin.index です。 デフォルトでは、これらのファイルはスレーブのデータディレクトリに作成されます。デフォルトのファイル名は、--relay-log および --relay-log-index の各サーバオプションで上書きできます。

リレーログはバイナリログと同じ形式なので、mysqlbinlog で読み取ることができます。リレーログは必要がなくなると（そのイベントがすべて実行されたら）、SQL スレッドによって自動的に削除されます。SQL スレッドが自動的に行うため、リレーログを削除するコマンドはありません。ただし、MySQL 4.0.14 からは FLUSH LOGS がリレーログをローテートするため、SQL が削除するタイミングに影響します。

新しいリレーログは、以下の条件で作成されます。

  • スレーブサーバの起動後、最初に I/O スレッドが開始されたとき（MySQL 5.0 では、最初の I/O スレッド開始時だけでなく、I/O スレッドが開始されるたびに新規リレーログが作成される）。

  • FLUSH LOGS ステートメントの実行時（4.0.14 以降）。

  • 現在のリレーログファイルのサイズが大きくなりすぎたとき。``大きすぎる'' かどうかは以下の変数で決定される。

    • max_relay_log_size（max_relay_log_size > 0 の場合）

    • max_binlog_size（max_relay_log_size = 0 または MySQL バージョンが 4.0.14 よりも古い場合）

スレーブレプリケーションサーバは、2 つの小さなファイルをデータディレクトリに作成します。これらのファイルの名前はデフォルトで、master.info および relay-log.info になります。これらのファイルには、SHOW SLAVE STATUS ステートメント（このコマンドの説明については、see 項4.11.8. 「スレーブサーバを制御する SQL ステートメント」）の出力に含まれるような情報が保存されます。ディスクファイルとして、スレーブがシャットダウンしても保持されます。次回スレーブが起動したとき、マスタからのバイナリログ読み取りとリレーログの処理がどこまで進んでいるかの情報を、スレーブはこれらのファイルから読み取ることができます。

master.info ファイルは I/O スレッドによって更新されます。このファイル内の行と SHOW SLAVE STATUS の出力結果内のカラムとの対応は以下のとおりです。

行 説明
1 Master_Log_File
2 Read_Master_Log_Pos
3 Master_Host
4 Master_User
5 パスワード（SHOW SLAVE STATUS では表示されない）
6 Master_Port
7 Connect_Retry

relay-log.info ファイルは SQL スレッドによって更新されます。ファイル内の行と SHOW SLAVE STATUS の出力結果内のカラムとの対応は以下のとおりです。

行 説明
1 Relay_Log_File
2 Relay_Log_Pos
3 Relay_Master_Log_File
4 Exec_Master_Log_Pos

スレーブのデータをバックアップするとき、リレーログファイルとともにこれら 2 つの小さなファイルもバックアップしてください。スレーブのデータをリストア後、レプリケーションを再会するのに必要となります。リレーログを失った場合でも relay-log.info ファイルがあれば、SQL スレッドがマスタバイナリログをどこまで実行したか調べることができます。そうすれば、CHANGE MASTER TO を MASTER_RELAY_LOG オプションおよび MASTER_RELAY_POS オプションとともに使用して、その箇所からバイナリログを再読み取りするようにスレーブに指示できます。これはもちろん、バイナリログがまだマスタサーバに存在することが前提となります。

スレーブが、LOAD DATA INFILE ステートメントもレプリケーションしなくてはならない場合、SQL_LOAD-* ファイルもバックアップしてください。このファイルは、この目的でスレーブが使用するディレクトリ内にあります。LOAD DATA INFILE ステートメントが中断されていた場合、レプリケーションを再開するためにスレーブはこれらのファイルを必要とします。ディレクトリの場所は、--slave-load-tmpdir オプションを使用して指定します。指定しなければ、デフォルト値は tmpdir 変数の値となります。

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.