メンテナンスのために MySQL の高可用性に依存すべきではない理由について話しましょう-mysql チュートリアル-php.cn

メンテナンスのために MySQL の高可用性に依存すべきではない理由について話しましょう

エンタープライズ環境では、ダウンタイムのコストが急速に増加します。ある調査では、回答者の 40% が、わずか 1 時間のダウンタイムで組織に 100 万ドル以上の損失が生じたと回答しました。データベースサービスを継続的に利用できるようにすることは明らかに価値があります。

これにより、あらゆる形態や規模の関係者との関係は言うまでもなく、組織の多額の費用が節約されます。

では、継続的な可用性を確保するにはどうすればよいでしょうか?継続的な可用性の背後にある概念は、高可用性と呼ばれます。この記事では、高可用性の概要と、それを MySQL クラスターに実装する方法について説明します。

また、システム管理者がメンテナンスタスクを実行するために誤って高可用性に依存するという高可用性の暗い側面も指摘し、なぜそうすることで高可用性の目標が損なわれ、ビジネス運営が危険にさらされるのかについて説明します。

1. 高可用性の概要

最初に可用性について話しましょう。ユーザーがほとんどの時間利用できないサービス (データベースなど) を実行する意味はほとんどありません。したがって、可用性について話すときは、サービスがどれだけアクセスしやすいかを意味します。

適切に実行されているサービスであれば、必要なときにいつでも利用できることが合理的に期待されますが、年に 1 ～ 2 日、または月に数時間のダウンタイムが発生することもあります。

一般に利用可能なサービスは、多くのユースケースシナリオに最適ですが、サービスが本質的に重要である場合、または多数のユーザーがサービスに依存している場合、「可用性」だけに依存するだけでは十分ではありません。の。

これが高可用性のすべてです。最も基本的な高可用性は、通常予想されるよりも高いレベルの可用性、より具体的には合意されたレベルを保証し、メンテナンス、パッチ適用、および一般的なエラーや障害を許容します。

2. 高可用性とはどのレベルの可用性ですか?

高可用性とは何かについて合意された定義はなく、単に特定の (より高い) 可用性要件を満たすことです。通常、プロバイダーが受け入れる「可用性」を超えます。実際、組織は、高可用性のコストとダウンタイム関連の損失のコストを比較検討して、運用のニーズに基づいて必要な可用性を定義する場合があります。

必要な可用性のレベルはパーセンテージで表すことができます。たとえば、99.99% または「フォーナイン」の可用性は、年間最大 52.06 分のダウンタイムを意味しますが、「シックスナイン」または 99.9999% の可用性は、年間のダウンタイムが 31.56 分に制限されます。

基本的に、選択はあなた次第ですが、繰り返しになりますが、それはトレードオフです。高可用性を維持するにはコストがかかり、追加の物理リソースとソフトウェアライセンスが必要になり、人的リソースが消耗されます。ただし、中断による波及コストや顧客の不満による収益損失のリスクを避けるためには、支払う価値があると思われるかもしれません。

3. 高可用性は実際にはどのように機能しますか?

高可用性インフラストラクチャの正確な性質は、ワークロードによって異なります。ただし、大まかに言えば、高可用性は、1 つのサービスまたはデバイスに障害が発生してもワークロードが中断されないフォールトトレランスがある場合に実現されます。通常、これは単一障害点がなく、すべてのサービスとデバイスがネットワークレベルとアプリケーションレベルで完全に冗長であることを意味します。

サービスによっては、これには通常、多数のノードが関係する場合があります。たとえば、MySQL クラスターには、データが保存されるさらにいくつかのノードが含まれます。次に、複数のノードを負荷分散ツールと組み合わせて、1 つのノードに障害が発生した場合にリクエストが別のノードに転送されるようにします。パフォーマンスがわずかに低下しても、ユーザーは利用可能なサービスに引き続きアクセスできます。

4. MySQL での高可用性の構成

もちろん、高可用性 MySQL データベースへのパスは、MySQL の実装によって異なります。一言で言えば、複数のノードを持つ何らかのタイプの MySQL クラスターを作成する必要があります。つまり、データは複数の MySQL サーバーに保存する必要があります。

次に、これらのノード上のデータを複製して、データベースに含まれるデータの正確なコピーが各ノードに確実に存在するようにするサービスが必要です。最後に、データベースリクエストがデータベースノードに均等に送信されるようにするためのロードバランサ (負荷分散) が必要ですが、1 つのノードがオフラインになった場合でもリクエストが満たされるようにする必要があります。

たとえば、MySQL は高可用性を実現する商用製品である Te MySQL InnoDB Cluster を提供しています。これは、MySQL データベース環境で高可用性を確保する一般的な方法である MySQL グループレプリケーションに基づいています。

もう 1 つの選択肢は、長年にわたり MySQL の高可用性を提供してきた Galera です。 MySQL の MariaDB フォークを使用している場合は、ロードバランシングに HAProxy を利用しながら、Galera クラスターで複数のノードを実行することで、高可用性を実現するために MariaDB 環境を構成できます。あるいは、MariaDB 独自の
MaxScale 製品を検討することもできます。

5. 高可用性を信頼する正当な理由…

エンタープライズ規模のワークロードでは、長期的には最高の結果が得られるため、高可用性の原則を採用することが増えています。運用において高可用性の設定を検討すべき理由は次のとおりです:

非常に重要なアプリケーション. 軍事アプリケーションなど、一部のアプリケーションではダウンタイムをまったく許容できません。またはエネルギーネットワーク。このような場合、高可用性は必須であり、リスク評価を行ってどの程度の高可用性を保証する必要があるかを決定することはできますが、極めて高い可用性を確保する以外に選択肢はほとんどありません。
波及効果. システムがワークロードの中心にある場合、接続され同期されたシステムに障害が発生するため、たとえ短時間の停止でも広範な問題を引き起こす可能性があります。データベースなど、いくつかのコア領域での高可用性への投資を検討する価値はあります。回復が困難な可能性のある、より大きな関連問題のコストを考慮すると、それだけの価値があるかもしれません。
収益の損失. 高可用性は、たとえ 9 という少ない数であっても、収益の損失を防ぐことができます。大手オンライン小売業者の場合、わずか数時間の売上の損失と、それに伴う風評被害が、収益に非常に大きな影響を与える可能性があります。
顧客の期待とサービスレベルアグリーメント: 貴社の事業運営には、クライアントに一定の稼働時間を保証するサービスレベルアグリーメントが適用される場合があります。この場合、クライアントのワークロードが一定レベルの稼働時間でサービスされるようにする必要があり、これは高可用性によって実現されます。これを怠ると、契約が解除されたり、契約に応じて賠償金が課せられる場合があります。

これらは、高可用性の正当な理由のいくつかです。そして、今日のテクノロジー優先の世界では、高可用性プラットフォームなしでは実行できないワークロードが数多くあります。

6. …そして高可用性を信頼する間違った理由

残念ながら、高可用性の人気が高まるにつれ、その悪用が発生しています。高可用性によりシステムは非常に堅牢になるため、技術チームはシステム管理タスク (パッチ適用など) を実行する際に、高可用性インフラストラクチャがマシンをオフラインにする負担を負担するだけであると考え、ショートカットを実行する誘惑に駆られることがあります。

実際には、すぐに複雑になります。 MySQL Cluster を例に挙げます。はい、マシンを再起動してパッチを適用すると、高可用性により MySQL クラスターは引き続き実行されます。ただし、パッチ適用のためにノードをシャットダウンしてから再起動すると、入力する必要のあるデータのバックログが作成されることに注意してください。このプロセスが完了するまでに長い時間がかかる場合があります。

言うまでもなく、すべてのデータベースホストは同じデータを参照する必要があります。危険は再同期プロセスにあります。すでにシャットダウンしてパッチを適用している間に別のノードがダウンすると、最終的な有効なクォーラムが失われる可能性があります。言い換えれば、データに関する「真実」を保持しているサーバーの数が許容レベルよりも少ない可能性があります。この状態からの回復は困難かつ複雑な場合があり、データ損失が発生する可能性もあります。

7. メンテナンスのために高可用性に依存しない

#高可用性とは、障害が発生した場合でもシステムが正常に動作することを保証することです。この障害に対する固有の保護は、高可用性を実現するために堅牢で無責任なシステムメンテナンスに依存し、誰もそれに気付かないというフリーパスではありません。

代わりに、技術チームは、高可用性インフラストラクチャがストレスに耐えられることを単に期待するのではなく、他のソリューションに依存する必要があります。たとえば、パッチを適用するシステムに完全な冗長性を設定するなどです。あるいは、可能な場合は

代わりにリアルタイムのパッチ適用を使用することにより、パッチをインストールするためにサービスを再起動する必要がなくなります。それにもかかわらず、メンテナンス作業での高可用性への依存には憂慮すべき兆候が見られます。よく見ると、パッチ適用タスクを実行するために高可用性を利用するようにユーザーに指示するベンダーの公式ガイダンスも見つかります。ユーザーは、パッチ適用のために 1 つのノードがオフラインになっても、他のノードに問題が発生しないことを祈るだけです。