パートIでは、MySQLホスティング用の高可用性（HA）フレームワークを紹介し、さまざまなコンポーネントとその機能について説明しました。パートIIでは、MySQLの準同期レプリケーションの詳細と、HAセットアップのデータの冗長性と一貫性を確保するのに役立つ関連する構成設定について説明します。パートIIIに再度チェックインして、発生する可能性のあるさまざまな障害シナリオと、フレームワークがこれらの状態に応答して回復する方法を確認してください。
MySQL準同期レプリケーションとは何ですか？
簡単に言うと、MySQLの準同期レプリケーション構成では、マスターは、少なくとも1つのスレーブから確認応答を受信した後にのみ、トランザクションをストレージエンジンにコミットします。スレーブは、イベントが受信されてリレーログにコピーされ、ディスクにフラッシュされた後にのみ確認応答を提供します。これにより、コミットされてクライアントに返されるすべてのトランザクションについて、データが少なくとも2つのノードに存在することが保証されます。準同期（レプリケーション）での「セミ」という用語は、イベントが受信されてリレーログにフラッシュされるとマスターがトランザクションをコミットするが、必ずしもスレーブ上のデータファイルにコミットされるとは限らないという事実によるものです。これは、セッションがクライアントに戻る前にトランザクションがスレーブとマスターの両方でコミットされる完全同期レプリケーションとは対照的です。
MySQLでネイティブに利用可能な準同期レプリケーションは、HAフレームワークがコミットされたトランザクションのデータの一貫性と冗長性を確保するのに役立ちます。マスターに障害が発生した場合、マスターでコミットされたすべてのトランザクションは、少なくとも1つのスレーブに複製されます（リレーログに保存されます）。その結果、スレーブが最新であるため（スレーブのリレーログが完全に排出された後）、そのスレーブへのフェイルオーバーはロスレスになります。
レプリケーションと準同期関連の設定
フレームワークで高可用性とデータの一貫性を確保するために最適な動作を保証するために使用される主要なMySQL設定のいくつかについて説明しましょう。
スレーブの実行速度の管理
最初の考慮事項は、データが受信され、のI/Oスレッドによってリレーログにフラッシュされることのみを保証する準同期レプリケーションの「semi」動作を処理することです。スレーブですが、必ずしもSQLスレッドによってコミットされるとは限りません。デフォルトでは、MySQLスレーブのSQLスレッドはシングルスレッドであり、マルチスレッドのマスターと歩調を合わせることができません。これの明らかな影響は、マスターに障害が発生した場合、SQLスレッドがリレーログのイベントを処理しているため、スレーブが最新ではないことです。フレームワークは、スレーブが昇格する前に完全に最新であると想定しているため、これによりフェイルオーバープロセスが遅延します。これは、データの一貫性を維持するために必要です。この問題に対処するために、オプションslave_parallel_workersを使用してマルチスレッドスレーブを有効にし、リレーログのイベントを処理する並列SQLスレッドの数を設定します。
さらに、以下の設定を構成して、マスターが存在しなかった状態にスレーブが入らないようにします。
- slave-parallel-type =LOGICAL_CLOCK
- slave_preserve_commit_order =1
これにより、データの一貫性が強化されます。これらの設定を使用すると、スレーブでの並列化と速度を向上させることができますが、並列スレッドが多すぎると、スレッド間の調整に伴うオーバーヘッドも増加し、残念ながらメリットを相殺する可能性があります。
スレーブでの並列実行の効率を上げるために使用できるもう1つの構成は、マスターでbinlog_group_commit_sync_delayを調整することです。これをマスターに設定すると、マスターのバイナリログエントリ、つまりスレーブのリレーログエントリに、SQLスレッドで並列処理できるトランザクションのバッチが含まれるようになります。これについては、J-FGagnéのブログで詳しく説明されており、彼はこの動作を「マスターの速度を落とし、スレーブの速度を上げる」と述べています。 。
ScaleGridコンソールを介してMySQLデプロイメントを管理している場合、スレーブのレプリケーションラグに関するリアルタイムアラートを継続的に監視および受信することができます。また、上記のパラメーターを動的に調整して、スレーブがマスターと連携して動作するようにすることで、フェイルオーバープロセスにかかる時間を最小限に抑えることができます。
MySQL高可用性フレームワークの説明-パートIIクリックしてツイート
重要な準同期レプリケーションオプション
MySQL準同期レプリケーションは、設計上、スレーブ確認応答タイムアウト設定に基づいて、または任意の時点で使用可能な準同期対応スレーブの数に基づいて、非同期モードにフォールバックできます。非同期モードは、定義上、コミットされたトランザクションがスレーブに複製されることを保証するものではないため、マスターが失われると、複製されていないデータが失われることになります。 ScaleGrid HAフレームワークのデフォルトの設計は、非同期モードへのフォールバックを回避することです。この動作に影響を与える構成を確認しましょう。
-
rpl_semi_sync_master_wait_for_slave_count
このオプションは、準同期マスターがトランザクションをコミットする前に確認応答を送信する必要があるスレーブの数を構成するために使用されます。 3ノードのマスタースレーブ構成では、これを1に設定しているため、両方のスレーブからの確認応答の待機に伴うパフォーマンスへの影響を回避しながら、少なくとも1つのスレーブでデータが利用可能であることが常に保証されます。
> -
rpl_semi_sync_master_timeout
このオプションは、準同期マスターがスレーブからの確認応答を待ってから非同期モードに戻る時間を設定するために使用されます。これを比較的高いタイムアウト値に設定したため、非同期モードへのフォールバックはありません。
2つのスレーブで動作しており、rpl_semi_sync_master_wait_for_slave_countが1に設定されているため、少なくとも1つのスレーブが妥当な時間内に確認応答し、マスターが確認することに気付きました。一時的なネットワークの中断中に非同期モードに切り替わることはありません。
-
rpl_semi_sync_master_wait_no_slave
これは、スレーブ数がタイムアウト期間中にrpl_semi_sync_master_wait_for_slave_countによって構成されたスレーブの数より少なくなった場合でも、マスターがrpl_semi_sync_master_timeoutによって構成されたタイムアウト期間が期限切れになるのを待つかどうかを制御します。マスターが非同期レプリケーションにフォールバックしないように、デフォルト値のONを保持します。
すべての準同期スレーブを失うことの影響
上記で見たように、フレームワークは、すべてのスレーブがダウンしたり、マスターから到達できなくなったりした場合に、マスターが非同期レプリケーションに切り替わるのを防ぎます。これの直接的な影響は、サービスの可用性に影響を与えるマスターへの書き込みが停止することです。これは基本的に、分散システムの制限に関するCAP定理で説明されているとおりです。この定理は、ネットワークパーティションが存在する場合、可用性または整合性のいずれかを選択する必要があるが、両方を選択する必要はないと述べています。この場合、ネットワークパーティションは、ダウンしているか到達不能であるため、マスターから切断されたMySQLスレーブと見なすことができます。
一貫性の目標は、コミットされたすべてのトランザクションについて、データが少なくとも2つのノードで利用できるようにすることです。そのような場合の結果として、ScaleGridHAフレームワークは可用性よりも一貫性を優先します。 MySQLマスターは引き続き読み取り要求を処理しますが、それ以上の書き込みはクライアントから受け入れられません。これは、デフォルトの動作として私たちが行った意識的な設計上の決定であり、もちろん、アプリケーションの要件に基づいて構成可能です。
ScaleGridブログを購読して、MySQLHAフレームワークのその他の障害シナリオと回復機能について説明するパートIIIを見逃さないようにしてください。 。しばらくお待ちください!!
