このページは機械翻訳したものです。

17.2.3 レプリケーションスレッド

17.2.3.1 レプリケーションメインスレッドの監視

17.2.3.2 レプリケーションアプライアンスワーカースレッドの監視

MySQL レプリケーション機能は、3 つのメインスレッド (ソースサーバー上のスレッドとレプリカ上のスレッド) を使用して実装されます:

• バイナリログダンプスレッド.  ソースは、レプリカの接続時にバイナリログの内容をレプリカに送信するスレッドを作成します。 このスレッドは、ソース上の SHOW PROCESSLIST の出力で Binlog Dump スレッドとして識別できます。

  バイナリログダンプスレッドは、レプリカに送信される各イベントを読み取るために、ソースバイナリログのロックを取得します。 イベントが読み取られるとすぐに、イベントがレプリカに送信される前でもロックが解除されます。

• レプリケーション I/O スレッド.  レプリカサーバーで START REPLICA | SLAVE ステートメントが発行されると、レプリカは I/O スレッドを作成します。このスレッドはソースに接続し、バイナリログに記録された更新を送信するように要求します。

  レプリケーション I/O スレッドは、ソース Binlog Dump スレッドが送信した更新を読み取り (前の項目を参照)、レプリカリレーログを構成するローカルファイルにコピーします。

  このスレッドの状態は、SHOW SLAVE STATUS の出力に Slave_IO_running として表示されます。

• レプリケーション SQL スレッド.  レプリカは、レプリケーション I/O スレッドによって書き込まれるリレーログを読み取り、そこに含まれるトランザクションを実行する SQL スレッドを作成します。

ソース/レプリカ接続ごとに 3 つのメインスレッドがあります。 複数のレプリカを持つソースは、現在接続されているレプリカごとに 1 つのバイナリログダンプスレッドを作成し、各レプリカには独自のレプリケーション I/O および SQL スレッドがあります。

レプリカは 2 つのスレッドを使用して、読取り更新をソースから分離し、独立したタスクに実行します。 したがって、トランザクションの適用プロセスが遅い場合、トランザクションの読取りタスクは遅くなりません。 たとえば、レプリカサーバーがしばらく実行されていない場合、その I/O スレッドは、SQL スレッドが遠く遅れていても、レプリカの起動時にソースからすべてのバイナリログコンテンツをすばやくフェッチできます。 SQL スレッドがフェッチされたすべてのステートメントを実行する前にレプリカが停止した場合、I/O スレッドは少なくともすべてをフェッチして、トランザクションの安全なコピーがレプリカリレーログにローカルに格納され、レプリカの次回の起動時に実行できるようにします。

slave_parallel_workers システム変数を 0 (デフォルト) より大きい値に設定することで、レプリカのタスクに対してさらにパラレル化を有効にできます。 このシステム変数を設定すると、レプリカは、トランザクションを適用するために指定された数のワーカースレッドと、それらを管理するためのコーディネータスレッドを作成します。 複数のレプリケーションチャネルを使用している場合、各チャネルにはこの数のスレッドがあります。 slave_parallel_workers が 0 より大きい値に設定されたレプリカは、マルチスレッドレプリカと呼ばれます。 この設定では、失敗したトランザクションを再試行できます。

注記

マルチスレッドレプリカは現在 NDB Cluster でサポートされていないため、この変数の設定は暗黙的に無視されます。 詳しくはセクション23.6.3「NDB Cluster レプリケーションの既知の問題」をご覧ください。