Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.2Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


17.3.8 準同期レプリケーション

MySQL 5.6 は、非同期レプリケーションを内蔵していますが、さらにプラグインによって実装される準同期レプリケーションへのインタフェースをサポートします。このセクションでは、準同期レプリケーションの概要とその動作について説明します。後続のセクションでは、準同期レプリケーションへの管理インタフェース、およびこれをインストール、構成、およびモニターする方法について説明します。

MySQL レプリケーションはデフォルトで非同期です。マスターはイベントをそのバイナリログに書き込みますが、スレーブがそれらを取得して処理したかどうかまたはその日時を認識しません。非同期レプリケーションでは、マスターがクラッシュしても、それがコミットしたトランザクションがスレーブに転送されていない場合があります。つまり、このケースでマスターからスレーブへのフェイルオーバーが発生すると、マスターに関係するトランザクションがないサーバーにフェイルオーバーされる場合があります。

準同期レプリケーションは非同期レプリケーションの代替として使用できます。

  • スレーブは、マスターに接続されるときに準同期対応かどうかを伝えます。

  • 準同期レプリケーションがマスター側で有効であり、準同期スレーブが少なくとも 1 つある場合、マスター上でトランザクションコミットを実行するスレッドは、コミット後にブロックされ、少なくとも 1 つの準同期スレーブがそのトランザクションのすべてのイベントを受け取ったことを通知するか、タイムアウトが発生するまで、待機します。

  • スレーブは、イベントがそのリレーログに書き込まれてディスクにフラッシュされたあとにのみ、トランザクションのイベントを受け取ったことを通知します。

  • スレーブからのトランザクション受け取り通知がない状態でタイムアウトが発生した場合、マスターは非同期レプリケーションに戻ります。少なくとも 1 つの準同期スレーブが追い付いたときに、マスターは準同期レプリケーションに戻ります。

  • 準同期レプリケーションはマスターとスレーブの両方で有効になっている必要があります。準同期レプリケーションがマスターで無効になっている場合、またはマスター上で有効でもスレーブ上でそうなっていない場合は、マスターは非同期レプリケーションを使用します。

マスターは、ブロック中 (コミットを実行したあとにスレーブからの通知を待機中) はトランザクションを実行したセッションに戻りません。ブロックが終了すると、マスターはそのセッションに戻り、ほかのステートメントの実行に進めます。この時点で、トランザクションはマスター側でコミット済みで、そのイベントを受け取ったことが少なくとも 1 つのスレーブから通知されています。

ブロックはバイナリログに書き込まれるロールバック後にも発生し、これは非トランザクションテーブルを変更するトランザクションがロールバックされるときに発生します。ロールバックされるトランザクションは、トランザクションテーブルに影響しない場合を含めて、ログが記録されます。非トランザクションテーブルへの変更はロールバックできず、スレーブに送信される必要があるためです。

トランザクションコンテキストで発生しないステートメントの場合 (つまり、トランザクションが START TRANSACTION または SET autocommit = 0 で起動されなかったとき)、自動コミットが有効になっていて、各ステートメントは暗黙的にコミットされます。準同期レプリケーションでは、明示的なトランザクションコミットと同様に、マスターはこのような各ステートメントをコミットしたあとにブロックされます。

準同期レプリケーションの意味を理解するには、非同期および完全同期レプリケーションと比較してください。

  • 非同期レプリケーションでは、マスターはイベントをそのバイナリログに書き込み、スレーブは準備ができたときにそれらを要求します。イベントがスレーブに必ず到達することは保証されていません。

  • 完全同期レプリケーションでは、マスターがトランザクションをコミットすると、マスターがトランザクションを実行したセッションに戻る前に、すべてのスレーブもトランザクションをコミットします。これの欠点は、トランザクションの完了が大きく遅れる場合があることです。

  • 準同期レプリケーションは、非同期および完全同期レプリケーションの中間です。マスターはコミット後、少なくとも 1 つのスレーブがイベントを受け取ってログを記録するまで待機します。すべてのスレーブが受け取りを通知するのを待機せず、スレーブ側でイベントが完全に実行されてコミットされたことではなく、受け取りのみを要求します。

準同期レプリケーションでは、非同期レプリケーションに比べて、データの完全性が向上します。コミットが成功したことが返されると、データが少なくとも 2 つの場所 (マスター上と少なくとも 1 つのスレーブ上) に存在することがわかります。マスターはコミットしたけれども、マスターがスレーブからの通知を待機中にクラッシュが発生した場合は、トランザクションがスレーブに到達できなかった可能性があります。

準同期レプリケーションは、バイナリログイベントをマスターからスレーブに送信できる速度を制限することで、ビジーセッションに速度制限を設定することもできます。あるユーザーがとてもビジーのときは、これによって速度が遅くなり、一部の配備状況で役立ちます。

準同期レプリケーションは、スレーブを待機する必要性によってコミットが遅くなるため、パフォーマンスに若干影響します。これは、データ完全性の向上とのトレードオフです。速度低下の量は、スレーブにコミットを送信して、スレーブからの受け取りの通知を待機するための、TCP/IP ラウンドトリップ時間以上です。これは、準同期レプリケーションは高速ネットワーク上で通信する近いサーバーに最適で、低速ネットワークで通信する遠いサーバーに最悪であることを意味します。


User Comments
  Posted by Naftali Zakharov on April 30, 2013
There is a useful best practices overview in Ronald Bradford's recent "Replication Techniques in Depth," of which a sample is available here:

http://www.mhprofessional.com/downloads/products/0071791868/186-8_ch03.pdf

This is the place to share an important point he makes in that chapter:

While installing the semisynchronous plugin (in MySQL 5.5 and higher), it is important to monitor the rpl_semi_sync_master_status status variable to disable semisynchronous replication in case of a timeout. The value is OFF if the plugin is not enabled or the master has fallen back to asynchronous replication due to commit acknowledgment timeout.

In the event, the MySQL error log will report the situation, but as a warning, and not an error.

For example:

120617 18:53:09 [Warning] Timeout waiting for reply of binlog (file: alpha-bin.000004, pos: 357), semi-sync up to file , position 0. 120617 18:53:09 [Note] Semi-sync replication switched OFF.
Sign Up Login You must be logged in to post a comment.