CityMob では、主要な永続データ ストレージとして MySQL データベースを使用しています。 弊社では、さまざまなサービスや目的に合わせていくつかのデータベース クラスターを用意しています。

マスターが常に利用できるかどうかは、システム全体とその個々の部分のパフォーマンスを示す重要な指標です。 マスター障害が発生した場合のクラスターの自動回復により、インシデント対応時間とシステムのダウンタイムが大幅に短縮されます。 この記事では、以下に基づいた MySQL クラスターの高可用性 (HA) 設計について説明します。 MySQL オーケストレーター および仮想 IP アドレス (VIP)。

VIPベースのHAソリューション

まず、データストレージシステムがどのようなものかを簡単に説明します。

XNUMX つの書き込みアクセス可能なマスターと複数の読み取り専用レプリカを備えた古典的なレプリケーション スキームを使用します。 クラスターには、中間マスター (レプリカであり、他のノードのマスターでもあるノード) を含めることができます。 クライアントは HAProxy を介してレプリカにアクセスするため、均等な負荷分散と簡単なスケーリングが可能になります。 HAProxy の使用は歴史的な理由によるものであり、現在 ProxySQL への移行過程にあります。

レプリケーションは、以下に基づいて準同期モードで実行されます。 GTID。 これは、トランザクションが成功したとみなされる前に、少なくとも XNUMX つのレプリカがトランザクションをログに記録する必要があることを意味します。 このレプリケーション モードは、マスター ノードに障害が発生した場合のパフォーマンスとデータの安全性の間で最適なバランスを提供します。 基本的にすべての変更は、次を使用してマスターからレプリカに転送されます。 Row Based Replication (RBR)、ただし、一部のノードでは mixed binlog format.

オーケストレーターはクラスター トポロジの状態を定期的に更新し、受け取った情報を分析し、問題が発生した場合は自動回復手順を開始します。 開発者は手順自体に責任を負います。これは、VIP、DNS、サービス検出サービスの使用、または自作のメカニズムの使用など、さまざまな方法で実装できるためです。

マスターに障害が発生した場合にマスターを復元する簡単な方法の XNUMX つは、フローティング VIP アドレスを使用することです。

次に進む前に、このソリューションについて知っておくべきこと:

• VIP は、特定の物理ネットワーク インターフェイスに関連付けられていない IP アドレスです。 ノードに障害が発生した場合、または定期メンテナンス中に、最小限のダウンタイムで VIP を別のリソースに切り替えることができます。
• 仮想 IP アドレスの解放と発行は、低コストで高速な操作です。
• VIP を使用するには、SSH 経由でサーバーにアクセスするか、次のような特別なユーティリティを使用する必要があります。 keepalived.

ウィザードで考えられる問題を見て、自動回復メカニズムがどのように機能するかを想像してみましょう。

マスターへのネットワーク接続が失われたか、ハードウェア レベルで問題が発生し、サーバーが使用できなくなりました

1. オーケストレーターはクラスター トポロジを更新し、各レプリカはマスターが使用できないことを報告します。 オーケストレーターは、新しいマスターの役割に適したレプリカを選択するプロセスを開始し、リカバリを開始します。
2. 古いマスターから VIP を削除しようとしていますが、成功しません。
3. レプリカはマスターの役割に切り替わります。 トポロジが再構築されています。
4. VIP を使用した新しいネットワーク インターフェイスを追加します。 VIP を削除できなかったため、バックグラウンドで定期的にリクエストの送信を開始します 無償ARP。 このタイプの要求/応答により、接続されたスイッチ上の IP アドレスと MAC アドレスのマッピング テーブルを更新でき、それによって VIP が移動したことを通知できます。 これにより可能性が最小限に抑えられます split brain 古いマスターを返すとき。
5. すべての新しい接続はすぐに新しいマスターにリダイレクトされます。 古い接続は失敗し、アプリケーション レベルでデータベースへの呼び出しが繰り返し行われます。

サーバーは通常モードで動作していますが、DBMS レベルで障害が発生しました

アルゴリズムは前のケースと似ており、トポロジを更新して回復プロセスを開始します。 サーバーが使用可能なため、古いマスター上の VIP が正常に解放され、新しいマスターに転送され、いくつかの ARP リクエストが送信されます。 古いマスターが戻ってくる可能性があっても、再構築されたクラスターとアプリケーションの動作に影響を与えることはありません。

その他の問題

レプリカまたは中間マスターの障害 導かない 自動アクションに依存せず、手動介入が必要です。

仮想ネットワーク インターフェイスは常に一時的に追加されます。つまり、サーバーの再起動後、VIP は自動的に割り当てられません。 各データベース インスタンスはデフォルトで読み取り専用モードで起動し、オーケストレーターは自動的に新しいマスターを書き込み用に切り替えてインストールを試行します。 read only 古いマスターについて。 これらの措置は、可能性を減らすことを目的としています。 split brain.

回復プロセス中に問題が発生する可能性があります。その場合は、標準の監視ツールに加えてオーケストレーター UI を通じて通知する必要もあります。 この機能を追加することで REST API を拡張しました (PR 現在検討中です）。

HA ソリューションの全体図を以下に示します。

新しいマスターの選択

オーケストレーターは十分に賢く、選択しようとします 最適なレプリカ 次の基準に従って新しいマスターとして登録されます。

• レプリカはマスターより遅れています。
• マスターとレプリカの MySQL バージョン。
• レプリケーション タイプ (RBR、SBR、または混合)。
• 同じまたは異なるデータセンターに設置されます。
• 可用性 errant GTID — レプリカ上で実行され、マスター上では実行されないトランザクション。
• カスタム選択ルールも考慮されます。

すべてのキューがマスターの理想的な候補であるわけではありません。 たとえば、レプリカをデータのバックアップに使用したり、サーバーのハードウェア構成が弱い場合があります。 オーケストレーター サポートする 手動ルールを使用すると、候補の選択設定を最も優先されるものから無視されるものまでカスタマイズできます。

応答と回復時間

インシデントが発生した場合は、システムのダウンタイムを最小限に抑えることが重要です。そのため、オーケストレーターによるクラスター トポロジの作成と更新に影響を与える MySQL パラメーターを考慮してみましょう。

• slave_net_timeout — 接続が失われたと認識されて再接続されるまでに、レプリカがマスターからの新しいデータまたはハートビート信号の到着を待機する秒数。 値が低いほど、レプリカはマスターとの通信が切断されたことをより速く判断できます。 この値を 5 秒に設定します。
• MASTER_CONNECT_RETRY — 再接続試行間の秒数。 ネットワークに問題が発生した場合、このパラメーターの値を低くすると、迅速な再接続が可能になり、クラスターの回復プロセスが開始されなくなります。 推奨値は 1 秒です。
• MASTER_RETRY_COUNT — 再接続試行の最大数。
• MASTER_HEARTBEAT_PERIOD — マスターがハートビート信号を送信するまでの秒単位の間隔。 デフォルトは値の半分です slave_net_timeout.

オーケストレーターのオプション:

• DelayMasterPromotionIfSQLThreadNotUpToDate - 等しい場合 trueの場合、レプリカの SQL スレッドがリレー ログからの未適用のトランザクションをすべて完了するまで、マスター ロールは候補レプリカに適用されません。 このオプションは、すべての候補レプリカが遅れた場合にトランザクションが失われないようにするために使用します。
• InstancePollSeconds — トポロジの構築と更新の頻度。
• RecoveryPollSeconds — トポロジー分析の頻度。 問題が検出された場合は、トポロジの回復が開始されます。 これ 定数、1秒に相当します。

各クラスター ノードは、オーケストレーターによって毎に XNUMX 回ポーリングされます。 InstancePollSeconds 秒問題が検出されると、クラスターの状態が強制されます。 更新しました、その後、リカバリを実行するかどうかの最終決定が行われます。 さまざまなデータベースとオーケストレーターのパラメーターを試してみることで、応答時間と回復時間を 30 秒に短縮することができました。

テストスタンド

ローカルの開発により HA スキームのテストを開始しました。 テストベンチ さらに、テスト環境と運用環境での実装も可能です。 ローカル スタンドは Docker に基づいて完全に自動化されており、オーケストレーターとネットワークの構成を試したり、クラスターを 2 ～ 3 台のサーバーから数十台に拡張したり、安全な環境で演習を実施したりできます。

演習では、問題のエミュレーション方法の XNUMX つを選択します。次の方法を使用してマスターを瞬時に撮影します。 kill -9、プロセスをソフト終了し、サーバーを停止します(docker-compose stop)、次を使用してネットワークの問題をシミュレートします。 iptables -j REJECT または iptables -j DROP。 次のような結果が期待されます。

• オーケストレーターはマスターの問題を検出し、10 秒以内にトポロジを更新します。
• 回復手順が自動的に開始されます。ネットワーク構成が変更され、マスターの役割がレプリカに渡され、トポロジが再構築されます。
• 新しいマスターは書き込み可能になり、ライブレプリカは再構築プロセス中に失われません。
• データは新しいマスターに書き込まれ、複製され始めます。
• 合計回復時間は 30 秒以内です。

ご存知のとおり、ハードウェアとネットワークの構成、合成負荷と実際の負荷の違いなどにより、システムの動作はテスト環境と実稼働環境で異なる場合があります。 そのため、実際の状況で定期的に演習を実施し、ネットワーク接続が失われたり、個々の部品が劣化したときにシステムがどのように動作するかを確認します。 将来的には、両方の環境に完全に同一のインフラストラクチャを構築し、そのテストを自動化したいと考えています。

所見

メイン ストレージ システム ノードの健全性は、SRE および運用チームの主要なタスクの XNUMX つです。 VIP に基づくオーケストレーターと HA ソリューションの実装により、次の結果を達成することができました。

• データベースクラスターのトポロジーの問題を確実に検出します。
• マスター関連のインシデントに自動的かつ迅速に対応し、システムのダウンタイムを削減します。

ただし、このソリューションには次のような制限と欠点があります。

• HA スキームを複数のデータセンターに拡張するには、それらの間に単一の L2 ネットワークが必要になります。
• 新しいマスターに VIP を割り当てる前に、古いマスターで VIP を解放する必要があります。 このプロセスは順次行われるため、回復時間が長くなります。
• VIP を解放するには、サーバーへの SSH アクセス、またはリモート プロシージャを呼び出すその他の方法が必要です。 サーバーまたはデータベースで回復プロセスの原因となった問題が発生しているため、VIP の削除が正常に完了するかどうかはわかりません。 これにより、同じ仮想 IP アドレスを持つ XNUMX つのサーバーが出現し、問題が発生する可能性があります。 split brain.

避けるために split brain、メソッドを使用できます ストーニス (「Shoot The Other Node In The Head」)、問題のあるノードを完全に隔離または無効化します。 クラスターの高可用性を実装するには、他にも方法があります。VIP と DNS の組み合わせ、サービス検出とプロキシ サービス、同期レプリケーション、およびそれぞれに欠点と利点があるその他の方法です。

MySQL フェイルオーバー クラスターを作成するためのアプローチについて説明しました。 実装は簡単で、現在の状況では許容可能なレベルの信頼性を提供します。 一般にシステム全体、特にインフラストラクチャが発展するにつれて、このアプローチは間違いなく進化します。

出所： habr.com