PDF (US Ltr)
- 36.1Mb
PDF (A4)
- 36.2Mb
このページは機械翻訳したものです。
MySQL 8.0 は、非同期レプリケーションを内蔵していますが、さらにプラグインによって実装される準同期レプリケーションへのインタフェースをサポートします。 このセクションでは、準同期レプリケーションの概要とその動作について説明します。 後続のセクションでは、準同期レプリケーションへの管理インタフェース、およびこれをインストール、構成、およびモニターする方法について説明します。
MySQL レプリケーションはデフォルトで非同期です。 ソースはイベントをバイナリログに書き込み、レプリカは準備ができたらそれらを要求します。 ソースでは、レプリカがトランザクションを取得して処理したかどうか、またはいつ処理したかは認識されず、イベントがレプリカに到達したことは保証されません。 非同期レプリケーションでは、ソースがクラッシュした場合、コミットされたトランザクションがレプリカに送信されていない可能性があります。 この場合、ソースからレプリカにフェイルオーバーすると、ソースに対して相対的なトランザクションが欠落しているサーバーにフェイルオーバーする可能性があります。
完全同期レプリケーションでは、ソースがトランザクションをコミットすると、ソースがトランザクションを実行したセッションに戻る前に、すべてのレプリカもトランザクションをコミットしています。 完全同期レプリケーションは、ソースから任意のレプリカへのフェイルオーバーがいつでも可能であることを意味します。 完全同期レプリケーションの欠点は、トランザクションの完了に多くの遅延が発生する可能性があることです。
準同期レプリケーションは、非同期および完全同期レプリケーションの中間です。 ソースは、少なくとも 1 つのレプリカがイベントを受信してログに記録する (必要な数のレプリカが構成可能) まで待機してから、トランザクションをコミットします。 ソースは、すべてのレプリカが受信を確認するのを待機するわけではなく、レプリカからの確認のみを必要とし、レプリカ側でイベントが完全に実行およびコミットされたことを必要としません。 したがって、準同期レプリケーションでは、ソースがクラッシュした場合、コミットされたすべてのトランザクションが少なくとも 1 つのレプリカに送信されていることが保証されます。
非同期レプリケーションと比較して、準同期レプリケーションではデータ整合性が向上します。コミットが正常に終了すると、データが 2 つ以上の場所に存在することがわかっているためです。 準同期ソースが必要な数のレプリカから確認を受信するまで、トランザクションは保留中でコミットされません。
完全同期レプリケーションと比較すると、準同期レプリケーションは、データ整合性の要件 (トランザクションの受信を確認するレプリカの数) とコミットの速度のバランスをとるように構成できるため、高速です。これは、レプリカを待機する必要があるため、速度が遅くなります。
重要
準同期レプリケーションでは、ソースがクラッシュし、レプリカへのフェイルオーバーが実行された場合、障害が発生したソースはレプリケーションソースとして再利用されないため、破棄するようにしてください。 どのレプリカによっても確認されなかったため、フェイルオーバーの前にコミットされなかったトランザクションがある可能性があります。
すべてのサーバーが同じトランザクションを同じ順序で受信し、クラッシュしたサーバーがグループに再度参加して自動的に最新になるフォルトトレラントレプリケーショントポロジを実装することを目的としている場合は、グループレプリケーションを使用してこれを実現できます。 詳細は、第18章「グループレプリケーション」 を参照してください。
非同期レプリケーションと比較した準同期レプリケーションのパフォーマンスへの影響は、データ整合性を向上させるためのトレードオフです。 速度低下の量は、少なくともレプリカにコミットを送信し、レプリカによる受信確認を待機する TCP/IP ラウンドトリップ時間です。 これは、準同期レプリケーションは高速ネットワーク上で通信する近いサーバーに最適で、低速ネットワークで通信する遠いサーバーに最悪であることを意味します。 準同期レプリケーションでは、バイナリログイベントをソースからレプリカに送信できる速度を制限することによって、ビジーセッションの速度制限も設定されます。 あるユーザーがビジー状態の場合、これにより処理速度が低下するため、一部のデプロイメント状況で役立ちます。
ソースとそのレプリカ間の準同期レプリケーションは、次のように動作します:
レプリカは、ソースへの接続時に準同期対応であるかどうかを示します。
ソース側で準同期レプリケーションが有効になっていて、少なくとも 1 つの準同期レプリカが存在する場合、ソースブロックでトランザクションコミットを実行し、少なくとも 1 つの準同期レプリカがトランザクションのすべてのイベントを受信したことを確認するか、タイムアウトが発生するまで待機するスレッド。
レプリカは、イベントがリレーログに書き込まれてディスクにフラッシュされた後にのみ、トランザクションイベントの受信を確認します。
レプリカがトランザクションを確認せずにタイムアウトが発生した場合、ソースは非同期レプリケーションに戻ります。 少なくとも 1 つの準同期レプリカがキャッチアップすると、ソースは準同期レプリケーションに戻ります。
ソース側とレプリカ側の両方で、準同期レプリケーションを有効にする必要があります。 準同期レプリケーションがソースで無効になっているか、ソースで有効になっているがレプリカで有効になっていない場合、ソースは非同期レプリケーションを使用します。
ソースがブロックしている間 (レプリカからの確認を待機している間)、トランザクションを実行したセッションには戻りません。 ブロックが終了すると、ソースはセッションに戻り、他のステートメントの実行に進むことができます。 この時点で、トランザクションはソース側でコミットされ、そのイベントの受信は少なくとも 1 つのレプリカによって確認されています。 セッションに戻る前にソースがトランザクションごとに受信する必要があるレプリカ確認の数は、rpl_semi_sync_master_wait_for_slave_count システム変数 (デフォルト値は 1) を使用して構成できます。
ブロックはバイナリログに書き込まれるロールバック後にも発生し、これは非トランザクションテーブルを変更するトランザクションがロールバックされるときに発生します。 非トランザクションテーブルへの変更はロールバックできず、レプリカに送信する必要があるため、トランザクションテーブルには影響しませんが、ロールバックされたトランザクションはログに記録されます。
トランザクションコンテキストで発生しないステートメントの場合 (つまり、トランザクションが START TRANSACTION または SET autocommit = 0 で起動されなかったとき)、自動コミットが有効になっていて、各ステートメントは暗黙的にコミットされます。 準同期レプリケーションでは、明示的なトランザクションコミットの場合と同様に、このような各ステートメントのソースブロックが行われます。
rpl_semi_sync_master_wait_point システム変数は、準同期ソースサーバーがトランザクションをコミットしたクライアントにステータスを返す前に、トランザクション受信のレプリカ確認を待機するポイントを制御します。 次の値を使用できます:
AFTER_SYNC(デフォルト): ソースは、各トランザクションをバイナリログとレプリカに書き込み、バイナリログをディスクに同期します。 ソースは、同期後にトランザクション受信のレプリカ確認を待機します。 確認応答を受信すると、ソースはトランザクションをストレージエンジンにコミットし、クライアントに結果を返してから続行できます。AFTER_COMMIT: ソースは、各トランザクションをバイナリログとレプリカに書き込み、バイナリログを同期し、トランザクションをストレージエンジンにコミットします。 ソースは、コミット後にトランザクション受信のレプリカ確認を待機します。 確認を受信すると、ソースは結果をクライアントに返し、クライアントは続行できます。
これらの設定のレプリケーション特性は、次のように異なります:
-
AFTER_SYNCでは、すべてのクライアントが同時にコミットされたトランザクションを確認できます。これは、レプリカによって確認され、ソース上のストレージエンジンにコミットされたあとです。 したがって、すべてのクライアントにソース上の同じデータが表示されます。ソース障害が発生した場合、ソースでコミットされたすべてのトランザクションがレプリカにレプリケートされます (リレーログに保存されます)。 レプリカが最新であるため、ソースの予期しない終了およびレプリカへのフェイルオーバーは失われません。 前述のように、フェイルオーバー後にソースを再利用しないでください。
-
AFTER_COMMITでは、サーバーがストレージエンジンにコミットしてレプリカの確認応答を受信したあとにのみ、トランザクションを発行するクライアントは戻りステータスを取得します。 コミット後およびレプリカの確認前に、他のクライアントはコミット中のクライアントの前にコミット済トランザクションを確認できます。レプリカがトランザクションを処理しないなどの問題が発生した場合は、予期しないソースの終了およびレプリカへのフェイルオーバーが発生したときに、そのようなクライアントがソースで見た内容と比較してデータの損失を確認できる可能性があります。