この3部構成のブログシリーズでは、パートIでMySQLホスティング用の高可用性（HA）フレームワークを紹介し、パートIIでMySQL準同期レプリケーションの詳細について説明しました。パートIIIでは、フレームワークがMySQLの重要な障害シナリオのいくつかを処理し、高可用性を確保するために回復する方法を確認します。
MySQL障害シナリオ
シナリオ1 –マスターMySQLがダウンする
- CorosyncおよびPacemakerフレームワークは、マスターMySQLが使用できなくなったことを検出します。 Pacemakerはマスターリソースを降格し、可能であればMySQLサービスを再起動して回復を試みます。
- この時点で、レプリケーションの準同期の性質により、マスターでコミットされたすべてのトランザクションは、少なくとも1つのスレーブによって受信されています。
- Pacemakerは、受信したすべてのトランザクションがスレーブに適用されるまで待機し、スレーブにプロモーションスコアを報告させます。スコアの計算は、スレーブがマスターと完全に同期している場合はスコアが「0」になり、それ以外の場合は負の数になるように行われます。
- ペースメーカーは、0スコアを報告したスレーブを選択し、書き込みが許可されているマスターMySQLの役割を引き継ぐスレーブをプロモートします。 >
- スレーブプロモーションの後、リソースエージェントはDNS再ルーティングモジュールをトリガーします。このモジュールは、プロキシDNSエントリを新しいマスターのIPアドレスで更新するため、すべてのアプリケーションの書き込みが新しいマスターにリダイレクトされやすくなります。
- ペースメーカーは、この新しいマスターからの複製を開始するために、使用可能なスレーブもセットアップします。
したがって、マスターMySQLがダウンするたびに（MySQLのクラッシュ、OSのクラッシュ、システムの再起動などが原因で）、HAフレームワークがそれを検出し、適切なスレーブをマスターの役割を引き継ぎます。これにより、システムを引き続きアプリケーションで利用できるようになります。
#MySQL高可用性フレームワークの説明–パートIII：障害シナリオクリックしてツイート
シナリオ2 –スレーブMySQLがダウンします
- CorosyncおよびPacemakerフレームワークは、スレーブMySQLが使用できなくなったことを検出します。
- ペースメーカーは、ノードでMySQLを再起動しようとして、リソースを回復しようとします。起動すると、スレーブとして現在のマスターに追加され、レプリケーションが続行されます。
- リカバリが失敗した場合、Pacemakerはそのリソースがダウンしていると報告します–これに基づいてアラートまたは通知を生成できます。必要に応じて、ScaleGridサポートチームがこのノードのリカバリを処理します。
- この場合、MySQLサービスの可用性に影響はありません。
シナリオ3 –ネットワークパーティション–マスターノードとスレーブノード間のネットワーク接続の切断
これは、各ノードが他のノードがダウンしていると見なす分散システムの古典的な問題ですが、実際には、ノード間のネットワーク通信のみが切断されます。このシナリオは、より一般的にはスプリットブレインシナリオとして知られており、適切に処理されない場合、複数のノードがマスターMySQLであると主張し、データの不整合や破損につながる可能性があります。
例を使用して、フレームワークがクラスター内のスプリットブレインシナリオをどのように処理するかを確認しましょう。ネットワークの問題により、クラスターが2つのグループに分割されていると想定します。一方のグループにマスター、もう一方のグループに2つのスレーブがあり、これを[（M）、（S1、S2）]と表記します。
- Corosyncは、マスターノードがスレーブノードと通信できず、スレーブノードが相互に通信できるがマスターとは通信できないことを検出します。
- 準同期レプリケーションは、マスターがコミットする前に少なくとも1つのスレーブからの確認応答を期待するため、マスターノードはトランザクションをコミットできません。同時に、Pacemakerの設定「no-quorum-policy =stop」に基づくクォーラムが不足しているため、PacemakerはマスターノードでMySQLをシャットダウンします。ここでのクォーラムとは、ノードの過半数、または3ノードクラスターセットアップの3つのうち2つを意味します。クラスタのこのパーティションで実行されているマスターノードは1つしかないため、no-quorum-policy設定がトリガーされ、MySQLマスターがシャットダウンします。
- これで、パーティション[（S1）、（S2）]のPacemakerは、クラスターに使用可能なマスターがないことを検出し、プロモーションプロセスを開始します。 S1が（準同期レプリケーションによって保証されているように）マスターに対して最新であると仮定すると、S1は新しいマスターとして昇格されます。
- アプリケーショントラフィックはこの新しいマスターMySQLノードにリダイレクトされ、スレーブS2は新しいマスターからの複製を開始します。
したがって、MySQL HAフレームワークはスプリットブレインシナリオを効果的に処理し、マスターノードとスレーブノード間のネットワーク接続が切断された場合にデータの一貫性と可用性の両方を確保します。
これで、準同期レプリケーションとCorosync plus Pacemakerスタックを使用したMySQL高可用性（HA）フレームワークに関する3部構成のブログシリーズは終了です。 ScaleGridでは、このブログシリーズで説明されている概念に基づいて実装された、AWS上のMySQLおよびAzure上のMySQLの高可用性ホスティングを提供しています。ソリューションの無料トライアルについては、ScaleGridコンソールにアクセスしてください。
