Orchestrator for MySQL: Orchestrator for MySQL なしではフォールト トレラントなプロジェクトを構築できない理由

大規模なプロジェクトは、必ず XNUMX 台のサーバーから始まります。 最初は DB サーバーが XNUMX つあり、その後、読み取り値をスケールするためにそれにスレーブが追加されました。 そしてそして - やめて！ マスターは XNUMX 人ですが、スレーブは多数います。 スレーブの XNUMX つが離れるとすべてがうまくいきますが、マスターが離れると状況は悪くなります。ダウンタイムが発生し、管理者はサーバーを上げようとしています。 何をするか？ マスターを予約します。 私の同僚のPavelはすでにこのことについて書いています статью、繰り返しません。 その代わりに、Orchestrator for MySQL が絶対に必要な理由を説明します。

主要な質問から始めましょう: 「マスターが去ったときにコードを新しいマシンにどのように切り替えるか?」

• 私は VIP (仮想 IP) を使用したスキームが最も気に入っています。これについては以下で説明します。 これは最も単純で明白ですが、明らかな制限があります。予約するマスターは新しいマシンの L2 セグメントに存在する必要があります。つまり、2 番目の DC については無視できます。 そして、友好的な方法で、大規模な L2 は悪であるというルールに従う場合、L3 はラックごとにのみ存在し、LXNUMX はラック間に存在し、そのようなスキームにはさらに多くの制限があるためです。
• コードに DNS 名を記述し、/etc/hosts を通じて解決できます。 実際には、解決策は何もないでしょう。 この方式の利点: 最初の方法に特有の制限がない、つまり、クロス DC を構成することが可能です。 しかし、明らかな疑問が生じます。Puppet-Ansible を介して /etc/hosts に変更をどれくらい早く配信できるでしょうか?
• 60 番目の方法を少し変更することができます。すべての Web サーバーにキャッシュ DNS をインストールし、それを通じてコードがマスター データベースに送信されます。 DNS でこのエントリに TTL XNUMX を設定できます。 正しく実装できれば、この方法は優れているようです。
• サービス検出を伴うスキーム。Consul および etcd の使用を意味します。
• 興味深いオプション プロキシSQL。 すべてのトラフィックを ProxySQL 経由で MySQL にルーティングする必要があります。ProxySQL 自体が誰がマスターであるかを決定できます。 ちなみに、この製品を使用するためのオプションの XNUMX つについては、私の記事で読むことができます。 статье.

Orchestrator の作成者は Github で作業しており、最初に VIP を使用して最初のスキームを実装し、次にそれを consul を使用するスキームに変換しました。

一般的なインフラストラクチャのレイアウト:

考慮する必要がある明らかな状況についてすぐに説明します。

• VIP アドレスは、どのサーバーの構成にも登録しないでください。 状況を想像してみましょう。マスターが再起動し、ロード中に Orchestrator がフェイルオーバー モードになり、スレーブの XNUMX つがマスターになりました。 その後、古いマスターが立ち上がって、今ではVIPがXNUMX台の車に乗っています。 これは悪いです。
• オーケストレーターの場合は、古いマスターと新しいマスターを呼び出すためのスクリプトを作成する必要があります。 古いマスターでは ifdown を実行する必要があり、新しいマスターでは ifup vip を実行する必要があります。 このスクリプトには、フェールオーバーが発生した場合、スプリットブレインを回避するために古いマスターのスイッチのポートが単にオフになることも含めるとよいでしょう。
• Orchestrator がスクリプトを呼び出して最初に VIP を削除したり、スイッチ上のポートを消滅させたりした後、新しいマスター上で VIP を上げるスクリプトを呼び出した後、arping コマンドを使用して新しい VIP が開始されたことを全員に通知することを忘れないでください。ここ。
• すべてのスレーブは read_only=1 である必要があり、スレーブをマスターに昇格するとすぐに read_only=0 になるはずです。
• このために選択したスレーブはどれもマスターになれることを忘れないでください (オーケストレーターには、最初にどのスレーブを新しいマスターの候補として考慮するか、次にどのスレーブを検討するか、どのスレーブを選択するかについての全体的な優先メカニズムがあります)いかなる状況においても選択されることはありませんマスター）。 スレーブがマスターになると、スレーブの負荷がスレーブに残り、マスターの負荷が追加されるため、これを考慮する必要があります。

Orchestrator をお持ちでないのに、なぜ Orchestrator が必要なのでしょうか?

• Orchestrator には、トポロジ全体を表示する非常に使いやすいグラフィカル インターフェイスが備わっています (下のスクリーンショットを参照)。
• Orchestrator は、どのスレーブが遅れているか、およびレプリケーションが一般的に失敗している場所を追跡できます (SMS を送信するためのスクリプトが Orchestrator に添付されています)。
• Orchestrator は、GTID に誤りがあるスレーブを通知します。

オーケストレーター インターフェイス:

GTID エラーとは何ですか?

Orchestrator が動作するには、主に XNUMX つの要件があります。

• MySQL クラスター内のすべてのマシンで擬似 GTID が有効になっている必要があります。GTID は有効になっています。
• どこにでも XNUMX 種類の binlog が存在する必要があり、ステートメントを使用できます。 マスターとほとんどのスレーブに Row があり、歴史的に XNUMX つが混合モードのままである構成がありました。 その結果、Orchestrator は単にこれらのスレーブを新しいマスターに接続したくありませんでした。

本番スレーブで最も重要なことは、マスターとの一貫性であることを忘れないでください。 マスターとスレーブの両方でグローバル トランザクション ID (GTID) が有効になっている場合は、gtid_subset 関数を使用して、同じデータ変更リクエストがこれらのマシンで実際に実行されたかどうかを確認できます。 これについて詳しく読むことができます ここで.

したがって、Orchestrator は GTID エラーを通じて、マスター上にないトランザクションがスレーブ上に存在することを示します。 なぜこうなった？

• Read_only=1 はスレーブで有効になっていません。誰かが接続してデータ変更リクエストを完了しました。
• Super_read_only=1 がスレーブで有効になっていないため、管理者はサーバーを混乱させて、そこでリクエストを実行しました。
• 前述の両方の点を考慮した場合、もう 5.7.25 つのトリックがあります。MySQL では、バイナリ ログをフラッシュするリクエストもバイナリ ログに送信されるため、最初のフラッシュ時にマスターとすべてのスレーブで GTID エラーが表示されます。 これを回避するにはどうすればよいでしょうか? Perona-28-1 では、binlog_skip_flush_commands=XNUMX 設定が導入され、binlog へのフラッシュの書き込みが禁止されます。 mysql.com Web サイトに確立されたものがあります。 虫.

以上をまとめてみましょう。 Orchestrator をまだフェールオーバー モードで使用したくない場合は、監視モードにします。 そうすれば、MySQL マシンの相互作用のマップと、各マシンでのレプリケーションの種類、スレーブの遅れの有無、そして最も重要なことに、マスターとの一貫性の程度に関する視覚的な情報が常に目の前に表示されます。

明らかな疑問は、「Orchestrator はどのように機能するべきですか?」ということです。 現在のスレーブから新しいマスターを選択し、すべてのスレーブをそれに再接続する必要があります (これには GTID が必要です。binlog_name と binlog_pos で古いメカニズムを使用している場合は、スレーブを現在のマスターから新しいマスターに切り替える必要があります)まったく不可能です!)。 Orchestrator が登場する前は、これらすべてを手動で行わなければならなかったことがあります。 古いマスターはバグのある Adaptec コントローラーが原因でハングしており、約 10 個のスレーブがありました。 VIP をマスターからスレーブの 3 つに転送し、他のすべてのスレーブをそれに再接続する必要がありました。 コンソールを何台開かなければならなかったのか、同時にいくつのコマンドを入力したのか...午前XNUMX時まで待たなければならず、XNUMX台を除くすべてのスレーブから負荷を取り除き、XNUMX台のマシンのうち最初のマシンをマスターにし、すぐにXNUMX台目のマシンを接続しなければなりませんでした。したがって、他のすべてのスレーブを新しいマスターに接続し、負荷を返します。 全体的にひどい...

Orchestrator がフェールオーバー モードになるとどのように動作しますか? これは、マスターを現在よりも強力で最新のマシンにしたい状況の例で最も簡単に説明できます。

図はプロセスの途中を示しています。 これまでに何が行われてきたのでしょうか? 一部のスレーブを新しいマスターにしたいと言うと、Orchestrator は単純に他のすべてのスレーブをそのスレーブに再接続し始め、新しいマスターは中継マシンとして機能します。 このスキームでは、エラーは発生せず、すべてのスレーブが機能し、Orchestrator は古いマスターから VIP を削除して新しいマスターに転送し、read_only=0 にして古いマスターのことを忘れます。 全て！ 当社のサービスのダウンタイムは VIP 転送時間で、2 ～ 3 秒です。

今日はここまでです、皆さんありがとうございました。 Orchestrator に関する XNUMX 番目の記事が近々公開される予定です。 有名なソ連の映画「ガレージ」では、ある登場人物が「私なら彼と一緒に偵察には行かない！」と言いました。 それで、オーケストレーター、私も偵察に同行します！

出所： habr.com