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

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「レプリケーションステータスの確認」を参照してください。