MySQL レプリケーション機能は、3 つのスレッド (マスターサーバー上で 1 つ、スレーブ上で 2 つ) を使用して実装されます。
-
Binlog ダンプスレッド マスターは、スレーブが接続したときにバイナリログ内容をスレーブに送信するスレッドを作成します。このスレッドは、マスター上の
SHOW PROCESSLIST
の出力内でBinlog Dump
スレッドとして識別できます。バイナリログダンプスレッドは、スレーブに送信される各イベントを読み取るために、マスターのバイナリログでロックを獲得します。イベントが読み取られるとすぐにロックは解除されます (イベントがスレーブに送信される前でも)。
-
スレーブ I/O スレッド
START SLAVE
ステートメントがスレーブサーバー上で発行されると、スレーブは I/O スレッドを作成し、これがマスターに接続されてそのバイナリログに記録された更新を送信することを要求します。スレーブ I/O スレッドは、マスターの
Binlog Dump
スレッドが送信する更新を読み取って (前の項目を参照)、それらをスレーブのリレーログで構成されるローカルファイルにコピーします。このスレッドの状態は、
SHOW SLAVE STATUS
の出力ではSlave_IO_running
として、SHOW STATUS
の出力ではSlave_running
として表示されます。 スレーブ SQL スレッド スレーブは、スレーブ I/O スレッドによって書き込まれるリレーログを読み取り、それらに含まれるイベントを実行する SQL スレッドを作成します。
マスター/スレーブ接続ごとに 3 つのスレーブがあることをすでに説明しました。複数のスレーブを持つマスターは、現在接続されているスレーブごとに 1 つのバイナリログダンプスレッドを作成し、スレーブごとに独自の I/O および SQL スレッドがあります。
スレーブは 2 つのスレッドを使用して、マスターからの更新を読み取ることとそれらを実行することを、独立タスクに分類します。このようにしても、ステートメント実行が遅い場合でも、ステートメントを読み取るタスクが遅くなることはありません。たとえば、スレーブサーバーがしばらくの間実行されなかった場合、その I/O スレッドはスレーブ起動時にマスターからすべてのバイナリログ内容をすばやくフェッチできます (SQL スレッドがかなり遅れていても)。SQL スレッドがすべてのフェッチ済みステートメントの実行を完了する前にスレーブが停止した場合でも、I/O スレッドは少なくともすべてのものをフェッチしているため、ステートメントの安全なコピーがスレーブのリレーログにローカルに保存されていて、次にスレーブが起動するときに実行できる状態です。これによって、マスターサーバーはそのバイナリログをすぐにパージできます (スレーブがそれらの内容をフェッチするのをそれ以上待機する必要がないため)。
SHOW PROCESSLIST
ステートメントは、レプリケーションに関してマスターおよびスレーブ上で何が起きているかを伝える情報を提供します。マスター状態については、セクション8.12.5.5「レプリケーションマスタースレッドの状態」を参照してください。スレーブ状態については、セクション8.12.5.6「レプリケーションスレーブの I/O スレッド状態」およびセクション8.12.5.7「レプリケーションスレーブ SQL スレッドの状態」を参照してください。
次の例では、3 つのスレッドが SHOW PROCESSLIST
からの出力でどのように表示されるかを示します。
マスターサーバーでは、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
ここで、スレッド 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
State
情報は、スレッド 10 がマスターサーバーと通信している I/O スレッド、スレッド 11 がリレーログに格納された更新を処理している SQL スレッドであることを示しています。SHOW PROCESSLIST
が実行された時点で、両方のスレッドはアイドルで、後続の更新を待機中でした。
Time
カラムの値は、マスターと比較してスレーブがどのくらい遅れているかを示すことができます。セクションA.13「MySQL 5.6 FAQ: レプリケーション」を参照してください。マスター側で Binlog Dump
スレッドの活動がない状態で十分な時間が経過した場合、マスターはスレーブがもう接続されていないと判断します。ほかのクライアント接続に関して、これのタイムアウトは net_write_timeout
および net_retry_count
の値によって異なります。これらの詳細については、セクション5.1.4「サーバーシステム変数」を参照してください。
SHOW SLAVE STATUS
ステートメントは、スレーブサーバー上のレプリケーション処理に関する追加情報を提供します。セクション17.1.5.1「レプリケーションステータスの確認」を参照してください。