MySQL によるロード バランシングを簡単な言葉で説明する

負荷分散の基本的な考え方はシンプルです。サーバー クラスター内の負荷を可能な限り平均化することです。この考えに基づいて、私たちの通常のアプローチは、サーバーのフロントエンドにロードバランサーをセットアップすることです。ロード バランサーの役割は、要求された接続をアイドル状態の利用可能なサーバーにルーティングすることです。

図 1 は、大規模な Web サイトの負荷分散セットアップを示しています。 1 つは HTTP トラフィックを担当し、もう 1 つは MySQL アクセスを担当します。

負荷分散には 5 つの共通の目的があります:

1. スケーラビリティ。ロード・バランシングは、読み取りと書き込みが分離されている場合にスタンバイ・データベースからデータを読み取るなど、特定の拡張に役立ちます。 ＃＃＃＃＃＃＃＃＃効率＃＃＃。負荷分散は、リクエストのルーティング先を制御できるため、リソースをより効率的に使用できます。 ＃＃＃＃＃＃＃＃＃可用性＃＃＃。柔軟な負荷分散ソリューションにより、サービスの可用性が大幅に向上します。
2. 透明性。クライアントは、ロード バランサーが存在するかどうかを知る必要も、ロード バランサーの背後に何台のマシンがあるかを知る必要もありません。クライアントに提供されるのは透過的なサーバーです。 ＃＃＃＃＃＃＃＃＃一貫性＃＃＃。アプリケーションがステートフルである場合 (データベース トランザクション、Web サイト セッションなど)、ロード バランサーは、関連するクエリを同じサーバーにポイントして、状態の損失を防ぐことができます。
3. 負荷分散の実装には、直接接続
と
4. ミドルウェア導入の2つの方法が一般的です。
関連チュートリアル:
5. mysql ビデオ チュートリアル
1 直接接続

ロード バランシングとは、アプリケーションと MySQL の間に何かを直接設定することだと考える人もいます。しかし、実際にはこれが唯一の負荷分散方法ではありません。次に、一般的なアプリケーション直接接続方法とその注意点について説明します。 1.1 読み取りレプリケーションと書き込みレプリケーションの分離この方法では、最大の問題の 1 つである

ダーティ データ

が発生する可能性があります。典型的な例は、ユーザーがブログ投稿にコメントし、ページをリロードしても新しいコメントが表示されない場合です。 もちろん、ダーティ データの問題を理由に、読み取りと書き込みの分離を放棄することはできません。実際、多くのアプリケーションでは、ダーティ データに対する耐性が比較的高い可能性があるため、現時点ではこの方法を大胆に導入できます。

では、ダーティ データに対する耐性が低いアプリケーションの場合、読み取りと書き込みをどのように分離すればよいでしょうか?次に、読み書きの分離をさらに区別していきますが、自分に合った戦略が必ず見つかると思います。

1) クエリの分離に基づく

アプリケーションにダーティ データを許容できない少量のデータしかない場合は、許容できないすべての読み取りと書き込みを割り当てることができます。ダーティデータをマスターに送信します。他の読み取りクエリはスレーブに割り当てられます。この戦略は実装が簡単ですが、ダーティ データを許容するクエリがほとんどない場合、スタンバイ データベースを効果的に使用できない可能性があります。

2) ダーティ データに基づく分離

これは、クエリベースの分離戦略に対する小さな改善です。スタンバイ データが最新かどうかを判断するためにアプリケーションにレプリケーションの遅延をチェックさせるなど、追加の作業が必要になります。多くのレポート アプリケーションはこの戦略を使用できます。夜間にロードされたデータをスタンバイ データベース インターフェイスにコピーするだけでよく、メイン データベースに完全に追いついたかどうかは気にしません。

3) セッション分離に基づく

この戦略は、ダーティ データ分離戦略よりも深いものです。ユーザーがデータを変更したかどうかを判断します。ユーザーは他のユーザーの最新データを見る必要はなく、自分の更新だけを見る必要があります。

具体的には、セッション層にフラグ ビットを設定して、ユーザーが更新を行ったかどうかを示すことができます。ユーザーが更新を行うと、ユーザーのクエリは一定期間メイン データベースに送信されます。 。 この戦略は、シンプルさと有効性の間で適切に妥協したものであり、より推奨される戦略です。

もちろん、十分なアイデアがある場合は、セッションベースの分離戦略とレプリケーション遅延監視戦略を組み合わせることができます。ユーザーが 10 秒前にデータを更新し、スタンバイ データベースの遅延がすべて 5 秒以内であれば、スタンバイ データベースからデータを大胆に読み取ることができます。セッション全体で同じスタンバイ データベースを選択することを忘れないでください。そうしないと、複数のスタンバイ データベースの遅延に一貫性がなくなると、ユーザーに迷惑がかかることになります。

4) グローバル バージョン/セッション分離に基づく

メイン データベースのログ座標を記録し、コピーされたログ座標と比較することで、スタンバイ データベースがデータを更新したかどうかを確認します。スタンバイデータベースの座標。アプリケーションが書き込み操作を指定している場合、トランザクションのコミット後に SHOW MASTER STATUS 操作を実行し、マスター ログの座標を変更されたオブジェクトまたはセッションのバージョン番号としてキャッシュに保存します。アプリケーションがスタンバイ・データベースに接続するときに、SHOW SLAVE STATUS を実行し、スタンバイ・データベース上の座標をキャッシュ内のバージョン番号と比較します。スタンバイ データベースがメイン データベースのレコード ポイントよりも新しい場合は、スタンバイ データベースが対応するデータを更新しており、安心して使用できることを意味します。

実際、多くの読み取り/書き込み分離戦略では、読み取りクエリの割り当てを決定するために レプリケーション レイテンシーの監視が必要です。ただし、SHOW SLAVE STATUS によって取得される Seconds_behind_master 列の値は遅延を正確に表していないことに注意してください。 Percona Toolkit の pt-heartbeat ツールを使用すると、遅延をより適切に監視できます。

1.2 DNS 名の変更

一部の比較的単純なアプリケーションでは、さまざまな目的のために DNS を作成できます。最も簡単な方法は、読み取り専用サーバー (read.mysql-db.com) に 1 つの DNS 名を設定し、書き込み操作を担当するサーバー (write.mysql-db.com) に別の DNS 名を設定することです。スタンバイ データベースがプライマリ データベースを維持できる場合は、読み取り専用 DNS 名がスタンバイ データベースを指すようにし、それ以外の場合はプライマリ データベースを指すようにします。

この戦略は実装が非常に簡単ですが、DNS を完全に制御できないという大きな問題があります。

• DNS の変更はすぐには反映されず、アトミックでもありません。 DNS の変更がネットワーク全体またはネットワーク間に伝播されるまでには長い時間がかかります。
• DNS データはさまざまな場所にキャッシュされ、その有効期限は必須ではなく推奨されます。
• 変更した DNS を完全に有効にするには、アプリケーションまたはサーバーの再起動が必要になる場合があります。

この戦略はより危険であり、/etc/hosts ファイルを変更することで DNS を完全に制御できないという問題を回避できるとしても、これは依然として理想的な戦略です。

1.3 IP アドレスの転送

サーバー間で仮想アドレスを転送することで負荷分散を実現します。 DNSを変更するのと同じような感じでしょうか？しかし、実際にはそれらは全く異なるものです。 IP アドレスを転送すると、DNS 名は変更されないままになります。ARP コマンドを使用して、IP アドレスの変更を迅速かつアトミックにローカル ネットワークに強制的に通知できます (ARP については知りません。ここを参照してください)。

より便利な手法は、各物理サーバーに固定 IP アドレスを割り当てることです。この IP アドレスはサーバー上で固定されており、変更されません。その後、各論理「サービス」(コンテナーとして理解できます) に仮想 IP アドレスを使用できます。

この方法では、アプリケーションを再構成することなく IP をサーバー間で簡単に転送できるため、実装が容易になります。

2 ミドルウェアの導入

上記の戦略は、アプリケーションが MySQL サーバーに接続されていることを前提としていますが、多くの負荷分散では、ネットワーク通信のプロキシとしてミドルウェアが導入されます。一方ですべての通信を受け入れ、これらのリクエストをもう一方の指定されたサーバーに分散し、実行結果をリクエスト元のマシンに送り返します。図 2 は、このアーキテクチャを示しています。

2.1 ロード バランサー

負荷分散ハードウェアとソフトウェアは数多くありますが、MySQL サーバー専用に設計されたものはほとんどありません。 Web サーバーは一般に負荷分散の必要性が高いため、多くの汎用負荷分散デバイスは HTTP をサポートし、他の用途のための基本的な機能はいくつかしか備えていません。

MySQL 接続は通常の TCP/IP 接続であるため、MySQL 上で多目的ロード バランサを使用できます。ただし、MySQL 固有の機能がないため、いくつかの制限があります。

• リクエストを分散すると、適切なロード バランシングが達成されない可能性があります。
• MySQL セッションのサポートが不十分なため、単一の HTTP セッションから MySQL サーバーに送信されるすべての接続リクエストを「修正」する方法がわからない可能性があります。
• 接続プーリングと長い接続により、ロード バランサーが接続要求を分散できない可能性があります。
• MySQL サーバー上で正常性と負荷のチェックをうまく実行できません。

2.2 負荷分散アルゴリズム

どのサーバーが次の接続を受け入れるかを決定するために使用されるアルゴリズムが多数あります。各メーカーは独自の異なるアルゴリズムを持っており、一般的な方法は次のとおりです:

1. ランダム割り当て。リクエストを処理するサーバーは、使用可能なサーバー プールからランダムに選択されます。
2. 投票。リクエストをラウンドロビン順序でサーバーに送信します (例: A、B、C、A、B、C)。 ＃＃＃＃＃＃＃＃＃ハッシュ＃＃＃。接続の送信元 IP アドレスはハッシュされ、プール内の同じサーバーにマッピングされます。
3. 最速の対応。リクエストを最も速く処理できるサーバーに接続を割り当てます。
4. 最小接続数。アクティブな接続が最も少ないサーバーに接続を割り当てます。
5. 重み。マシンのパフォーマンスやその他の条件に応じて、マシンごとに異なる重みが設定され、高性能マシンがより多くの接続を処理できるようになります。
6. 上記の方法に最適な方法はなく、特定のワークロードに応じて最適な方法があるだけです。
また、即時処理のアルゴリズムのみを説明します。ただし、キューイング アルゴリズムを使用した方が効率的な場合もあります。たとえば、アルゴリズムは、一度に N 個を超えるアクティブなトランザクションを許可せずに、特定のデータベース サーバーの同時実行性を維持する場合があります。アクティブなトランザクションが多すぎる場合、新しいリクエストはキューに入れられ、利用可能なサーバーのリストに処理させます。

2.3 1 つのマスター ルームと複数のバックアップ ルームの負荷分散

最も一般的なレプリケーション構造は、1 つのマスター データベースと複数のバックアップ データベースです。このアーキテクチャには拡張性がありませんが、いくつかの方法で負荷分散と組み合わせることで、より良い結果を達成できます。

• 機能部門。レポート作成、分析、データ ウェアハウジング、全文インデックス作成などのベンダー機能の場合、1 つまたはスタンバイ データベースのグループを構成して、単一機能の容量を拡張します。
• スタンバイ データベースがメイン データベース と同じ状態に保たれていることを確認します。バックアップの問題はデータがダーティであることです。このために、関数 MASTER_POS_WAIT() を使用して、スタンバイ ライブラリがメイン ライブラリの設定された同期ポイントに追いつくまで、メイン ライブラリの動作をブロックできます。あるいは、レプリケーション ハートビートを使用して遅延を確認することもできます。

アプリケーションの最初に Alibaba のようなアーキテクチャを作ることは考えられませんし、考えるべきではありません。最良の方法は、アプリケーションが現在明らかに必要としているものを

実装し、急速な成長の可能性に備えて事前に計画を立てることです。 また、10,000 または 100,000 の同時実行数を満たすというパフォーマンスの正確な目標があるのと同じように、スケーラビリティについても

数値目標

を設定することは理にかなっています。これにより、シリアル化や相互運用性などのオーバーヘッドの問題が、関連する理論を通じてアプリケーションに持ち込まれるのを回避できます。 MySQL の拡張戦略に関して言えば、一般的なアプリケーションが非常に大きなサイズに成長すると、通常はまず単一サーバーからスタンバイ データベースを備えたスケールアウト アーキテクチャに移行し、次にデータ シャーディングまたは機能パーティショニングに移行します。 。ここで注意していただきたいのは、「できるだけ早くシャードを作成し、できるだけ多くシャードを作成する」といったアドバイスを推奨しているわけではないことです。実際、シャーディングは複雑でコストがかかります。そして最も重要なことに、多くのアプリケーションではシャーディングがまったく必要ない可能性があります。シャーディングに多額の費用を費やすよりも、新しいハードウェアと MySQL の新しいバージョンの変更を確認する方が良いでしょう。おそらく、これらの新しい変更には驚かれるでしょう。

まとめ

直接接続と重い「分離」、イコライザーとアルゴリズムには限界があります。

• は、スケーラビリティの定量的な指標です。
最後に、この記事がお役に立てば幸いです。

以上がMySQL によるロード バランシングを簡単な言葉で説明するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。