ホームページ >データベース >mysql チュートリアル >mysqlのロードバランシングとは何ですか
MySQL では、ロード バランシングとは、データベース クエリ リクエストを割り当ててデータベース システムのパフォーマンスを向上させるために、複数の MySQL サーバーをクラスタに形成することを指します。 MySQL のロード バランシングは、単一のデータベースが大量のリクエストを処理する場合のボトルネック問題を解決し、リクエストを複数のサーバーに均等に分散することでデータベース システムのパフォーマンスを向上させるという目的を達成します。データベース システムの可用性が向上するため、いずれかのサーバーに障害が発生しても、他のサーバーがリクエストの処理を続行できるため、サービスの継続性が確保されます。
このチュートリアルの動作環境: Windows7 システム、mysql8 バージョン、Dell G3 コンピューター。
MySQL ロード バランシングとは何ですか?
MySQL ロード バランシングとは、複数の MySQL サーバーをクラスターに形成し、データベース クエリ リクエストを割り当ててデータベース システムのパフォーマンスを向上させることを指します。ロード バランシングにより、高可用性、スケーラビリティ、ロード バランシングが可能になります。
負荷分散の基本的な考え方はシンプルです。サーバー クラスター内の負荷を可能な限り平均化することです。この考えに基づいて、私たちの通常のアプローチは、サーバーのフロントエンドにロードバランサーをセットアップすることです。ロード バランサーの役割は、要求された接続をアイドル状態の利用可能なサーバーにルーティングすることです。
図 1 は、大規模な Web サイトの負荷分散セットアップを示しています。 1 つは HTTP トラフィックを担当し、もう 1 つは MySQL アクセスを担当します。
#MySQL ロード バランシングが必要なのはなぜですか?
MySQL のロード バランシングは、単一のデータベースが大量のリクエストを処理する場合のボトルネックの問題を解決し、リクエストを複数のサーバーに均等に分散することでデータベース システムのパフォーマンスを向上させるという目的を達成します。同時に、負荷分散によりデータベース システムの可用性も向上し、サーバーの 1 つに障害が発生しても、他のサーバーがリクエストの処理を続行できるため、サービスの継続性が確保されます。 負荷分散には 5 つの共通の目的があります:スケーラビリティ。ロード・バランシングは、読み取りと書き込みが分離されている場合にスタンバイ・データベースからデータを読み取るなど、特定の拡張に役立ちます。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃効率＃＃＃。負荷分散は、リクエストのルーティング先を制御できるため、リソースをより効率的に使用できます。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃可用性＃＃＃。柔軟な負荷分散ソリューションにより、サービスの可用性が大幅に向上します。
透明性。クライアントは、ロード バランサーが存在するかどうかを知る必要も、ロード バランサーの背後に何台のマシンがあるかを知る必要もありません。クライアントに提供されるのは透過的なサーバーです。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃一貫性＃＃＃。アプリケーションがステートフルである場合 (データベース トランザクション、Web サイト セッションなど)、ロード バランサーは、関連するクエリを同じサーバーにポイントして、状態の損失を防ぐことができます。
#MySQL 負荷分散の実装方法
とミドルウェアの紹介。
負荷分散とはアプリケーションと MySQL サーバーの間で何かを直接構成することだと考える人もいますが、実際にはこれが唯一の負荷分散ではありません。方法。次に、一般的なアプリケーション直接接続方法とその注意点について説明します。
この方法では、最大の問題の 1 つである ダーティ データ が発生する可能性があります。典型的な例は、ユーザーがブログ投稿にコメントし、ページをリロードしても新しいコメントが表示されない場合です。
もちろん、ダーティ データの問題を理由に、読み取りと書き込みの分離を放棄することはできません。実際、多くのアプリケーションでは、ダーティ データに対する耐性が比較的高い可能性があるため、現時点ではこの方法を大胆に導入できます。 では、ダーティ データに対する耐性が低いアプリケーションの場合、読み取りと書き込みをどのように分離すればよいでしょうか?次に、読み書きの分離をさらに区別していきますが、自分に合った戦略が必ず見つかると思います。
1) クエリの分離に基づく3) セッション分離に基づく
この戦略は、ダーティ データ分離戦略よりも深いものです。ユーザーがデータを変更したかどうかを判断します。ユーザーは他のユーザーの最新データを見る必要はなく、自分の更新だけを見る必要があります。
具体的には、セッション層にフラグ ビットを設定して、ユーザーが更新を行ったかどうかを示すことができます。ユーザーが更新を行うと、ユーザーのクエリは一定期間メイン データベースに送信されます。 。
この戦略は、シンプルさと有効性の間で適切に妥協したものであり、より推奨される戦略です。
もちろん、十分なアイデアがある場合は、セッションベースの分離戦略とレプリケーション遅延監視戦略を組み合わせることができます。ユーザーが 10 秒前にデータを更新し、スタンバイ データベースの遅延がすべて 5 秒以内であれば、スタンバイ データベースからデータを大胆に読み取ることができます。セッション全体で同じスタンバイ データベースを選択することを忘れないでください。そうしないと、複数のスタンバイ データベースの遅延に一貫性がなくなると、ユーザーに迷惑がかかることになります。
4) グローバル バージョン/セッション分離に基づく
メイン データベースのログ座標を記録し、コピーされたログ座標と比較することで、スタンバイ データベースがデータを更新したかどうかを確認します。スタンバイデータベースの座標。アプリケーションが書き込み操作を指定している場合、トランザクションのコミット後に SHOW MASTER STATUS 操作を実行し、マスター ログの座標を変更されたオブジェクトまたはセッションのバージョン番号としてキャッシュに保存します。アプリケーションがスタンバイ・データベースに接続するときに、SHOW SLAVE STATUS を実行し、スタンバイ・データベース上の座標をキャッシュ内のバージョン番号と比較します。スタンバイ データベースがメイン データベースのレコード ポイントよりも新しい場合は、スタンバイ データベースが対応するデータを更新しており、安心して使用できることを意味します。
実際、多くの読み取り/書き込み分離戦略では、読み取りクエリの割り当てを決定するために レプリケーション レイテンシーの監視が必要です。ただし、SHOW SLAVE STATUS によって取得される Seconds_behind_master 列の値は遅延を正確に表していないことに注意してください。 Percona Toolkit の pt-heartbeat ツールを使用すると、遅延をより適切に監視できます。
比較的単純なアプリケーションでは、さまざまな目的のために DNS を作成できます。最も簡単な方法は、読み取り専用サーバー (read.mysql-db.com) に 1 つの DNS 名を設定し、書き込み操作を担当するサーバー (write.mysql-db.com) に別の DNS 名を設定することです。スタンバイ データベースがプライマリ データベースを維持できる場合は、読み取り専用 DNS 名がスタンバイ データベースを指すようにし、それ以外の場合はプライマリ データベースを指すようにします。
この戦略は実装が非常に簡単ですが、DNS を完全に制御できないという大きな問題があります。
この戦略はより危険であり、/etc/hosts ファイルを変更することで DNS を完全に制御できない問題を回避できるとしても、これは依然として理想的な戦略です。
サーバー間で仮想アドレスを転送することで負荷分散を実現します。 DNSを変更するのと同じような感じでしょうか？しかし、実際にはそれらは全く異なるものです。 IP アドレスを転送すると、DNS 名は変更されないままになります。ARP コマンドを使用して、IP アドレスの変更を迅速かつアトミックにローカル ネットワークに強制的に通知できます (ARP については知りません。ここを参照してください)。
より便利な手法は、各物理サーバーに固定 IP アドレスを割り当てることです。この IP アドレスはサーバー上で固定されており、変更されません。その後、各論理「サービス」(コンテナーとして理解できます) に仮想 IP アドレスを使用できます。
この方法では、アプリケーションを再構成することなく IP をサーバー間で簡単に転送できるため、実装が容易になります。
上記の戦略は、アプリケーションが MySQL サーバーに接続されていることを前提としていますが、多くの負荷分散では、ネットワーク通信エージェントとしてミドルウェアが導入されます。一方ですべての通信を受け入れ、これらのリクエストをもう一方の指定されたサーバーに分散し、実行結果をリクエスト元のマシンに送り返します。図 2 は、このアーキテクチャを示しています。 
負荷分散ハードウェアとソフトウェアは数多くありますが、MySQL サーバー専用に設計されたものはほとんどありません。 Web サーバーは一般に負荷分散の必要性が高いため、多くの汎用負荷分散デバイスは HTTP をサポートし、他の用途のための基本的な機能はいくつかしか備えていません。
MySQL 接続は通常の TCP/IP 接続であるため、MySQL 上で多目的ロード バランサを使用できます。ただし、MySQL 固有の機能がないため、さらに多くの制限が発生します:
どのサーバーが次の接続を受け入れるかを決定するために使用されるアルゴリズムは数多くあります。各メーカーは独自の異なるアルゴリズムを持っており、一般的な方法は次のとおりです:
ランダム割り当て。リクエストを処理するサーバーは、使用可能なサーバー プールからランダムに選択されます。
投票。リクエストをラウンドロビン順序でサーバーに送信します (例: A、B、C、A、B、C)。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ハッシュ＃＃＃。接続の送信元 IP アドレスはハッシュされ、プール内の同じサーバーにマッピングされます。
最速の対応。リクエストを最も速く処理できるサーバーに接続を割り当てます。
最小接続数。アクティブな接続が最も少ないサーバーに接続を割り当てます。
重み。マシンのパフォーマンスやその他の条件に応じて、マシンごとに異なる重みが設定され、高性能マシンがより多くの接続を処理できるようになります。
上記の方法に最適な方法はなく、特定のワークロードに応じて最適な方法があるだけです。 また、即時処理のアルゴリズムのみを説明します。ただし、キューイング アルゴリズムを使用した方が効率的な場合もあります。たとえば、アルゴリズムは、一度に N 個を超えるアクティブなトランザクションを許可せずに、特定のデータベース サーバーの同時実行性を維持する場合があります。アクティブなトランザクションが多すぎる場合、新しいリクエストはキューに入れられ、利用可能なサーバーのリストに処理させます。
最も一般的なレプリケーション構造は、
1 つのマスター データベースと複数のバックアップ データベース機能部門。レポート作成、分析、データ ウェアハウジング、全文インデックス作成などのベンダー機能の場合、1 つまたはスタンバイ データベースのグループを構成して、単一機能の容量を拡張します。
MySQL の拡張戦略に関して言えば、一般的なアプリケーションが非常に大きなサイズに成長すると、通常はまず単一サーバーからスタンバイ データベースを備えたスケールアウト アーキテクチャに移行し、次にデータ シャーディングまたは機能パーティショニングに移行します。 。ここで注意していただきたいのは、「できるだけ早くシャードを作成し、できるだけ多くシャードを作成する」といったアドバイスを推奨しているわけではないことです。実際、シャーディングは複雑でコストがかかります。そして最も重要なことに、多くのアプリケーションではシャーディングがまったく必要ない可能性があります。シャーディングに多額の費用を費やすよりも、新しいハードウェアと MySQL の新しいバージョンの変更を確認する方が良いでしょう。おそらく、これらの新しい変更には驚かれるでしょう。
まとめ
直結再「分離」、イコライザー、アルゴリズムには限界があります。 は、スケーラビリティの定量的な指標です。
以上がmysqlのロードバランシングとは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。