MySQL によるロードバランシングを簡単な言葉で説明する-mysql チュートリアル-php.cn

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

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

图 1 典型的读密集型网站负载均衡架构

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

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

ロードバランシングとは、アプリケーションと 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 は、このアーキテクチャを示しています。
图 1：作为中间件的负载均衡器

2.1 ロードバランサー

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

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

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

2.2 負荷分散アルゴリズム

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

ランダム割り当て。リクエストを処理するサーバーは、使用可能なサーバープールからランダムに選択されます。
投票。リクエストをラウンドロビン順序でサーバーに送信します (例: A、B、C、A、B、C)。＃＃＃＃＃＃＃＃＃ハッシュ＃＃＃。接続の送信元 IP アドレスはハッシュされ、プール内の同じサーバーにマッピングされます。
最速の対応。リクエストを最も速く処理できるサーバーに接続を割り当てます。
最小接続数。アクティブな接続が最も少ないサーバーに接続を割り当てます。
重み。マシンのパフォーマンスやその他の条件に応じて、マシンごとに異なる重みが設定され、高性能マシンがより多くの接続を処理できるようになります。
上記の方法に最適な方法はなく、特定のワークロードに応じて最適な方法があるだけです。

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

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

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

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

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

数値目標

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

まとめ

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