MySQL の高可用性アーキテクチャ テクノロジを一緒に分析しましょう

この記事では、mysql 中高可用性アーキテクチャの技術分析に関する関連知識を提供します。主に MMM、MySQL マスター/スレーブ アーキテクチャ、およびクラスター関連の問題の技術分析を紹介します。みんなが助けてくれます。

#背景説明

情報技術の発展に伴い、企業は情報管理への依存度を高めており、各ビジネス アプリケーションのデータ情報は主にデータベースに保存されています。企業におけるこれらのデータへのアクセス継続性に対する要求はますます高まっており、データ中断によるさまざまな損失を回避するために、データベースの高可用性は企業情報構築における最優先事項となっています。同時に、電気通信、金融、エネルギー、軍事産業など、国民経済や国民生活に関わる産業や分野の主要ビジネスでは、主要なデータストレージの高可用性が求められており、データシステムは24時間稼働を保証する必要があります。 7 データの損失や損傷を防ぐため。クリックしてプログラミング学習教材を受け取ります

高可用性アーキテクチャの概要

高可用性アーキテクチャ基本的にインターネット サービスの標準です。アプリケーション サービスとデータベース サービスの両方が必要です。高可用性であること。システムの場合、 にはフロントエンド アプリケーション、キャッシュ、データベース、検索、メッセージ キューなどの多くのモジュールが含まれる場合があります。システム 全体の高可用性を確保するには、各モジュールの可用性が高い必要があります。データベース サービスの場合、高可用性はさらに複雑になる可能性があります。ユーザーがサービスを利用できるようにするには、アクセスだけでなく正確性の保証も必要です。したがって、データベースの高可用性には、より多くの認証が必要です。

MySQL 高可用性アーキテクチャの分類

MySQL は高可用性のために MMM を実装します
• MySQL は MHA のために高可用性を実装します
• MySQL は高可用性クラスタ モードを実装しますアーキテクチャから高可用性を実現するための
• MySQL

MMM

MMM (MySQL のマスター-マスター レプリケーション マネージャー) の技術分析は、デュアルマスターフェイルオーバーとデュアルマスターの日常管理をサポートするスクリプトプログラム。

• MMM は Perl 言語を使用して開発されており、主に MySQL のマスター-マスター (デュアルマスター) レプリケーションの監視と管理に使用されます。ビジネスでは同じ時間のみが許可されます。一方のマスターに書き込み、もう一方の代替マスターで部分的な読み取りサービスを提供して、マスター間の切り替え時の代替マスターのウォームアップを高速化します。

• MMM の監視側は、書き込み可能な VIP と複数の読み取り可能な VIP を含む複数の仮想 IP (VIP) を提供します。監視管理を通じて、これらの IP は利用可能な mysql にバインドされます。がダウンすると、vip が他の mysql に移行されます。

• #MMM スクリプト プログラムはフェイルオーバー機能を実装する一方で、追加の内部ツール スクリプトによって複数のスレーブの読み取り負荷分散を実現することもできます。

• このパッケージは、標準のマスター/スレーブ構成に基づいて任意の数のスレーブ サーバーにわたる負荷分散を読み取ることもできるため、これを使用して、複製されたサーバーのグループで起動することができます。さらに、仮想 IP には、ノード間のデータ バックアップおよび再同期機能を実装するスクリプトも含まれています。

MMM 基本コンポーネント分析

mmm_mond: 監視プロセス。すべての監視作業を担当し、すべてのノード ロール アクティビティを決定して処理します。したがって、スクリプトはスーパーバイザ上で実行する必要があります。
• mmm_agentd: 各 msql サーバーで実行されているエージェント プロセスは、監視プローブ作業を完了し、簡単なリモート サービス設定を実行します。このスクリプトは監視対象マシン上で実行する必要があります。
• mmm_control: mmm_mond を管理するコマンドを提供する単純なスクリプト。

MMM 実装の基本的な実装原理

MMM は、サーバーのグループ内でレプリケーション遅延が大きいサーバーの仮想 IP を自動および手動で削除する方法を提供します。また、データをバックアップしたり、2 つのノード間でデータ同期を実現したりすることもできます。

MySQL 自体はレプリケーション フェイルオーバー ソリューションを提供しませんが、MMM ソリューションを通じてサーバー フェイルオーバーを実現できるため、mysql の高可用性を実現できます。

MMM の使用シナリオ

MMM はデータの一貫性を完全に保証できないため、MMM はデータの一貫性要件がそれほど高くないアプリケーションに適していますが、ビジネスの可用性を最大限に確保したいと考えています。

データの一貫性に対する高度な要件がある企業の場合、MMM のような高可用性アーキテクチャを使用することはあまりお勧めできません。

MMM プロジェクトは Google から提供されています: code.google.com/p/mysql-mas…
• 公式 Web サイトは次のとおりです: mysql-mmm.org

MHA の概要

MHA (Master High Availability) は、現在、MySQL 高可用性のための比較的成熟したソリューションであり、日本の DeNA 会社の Youshimaton (現在は Facebook に勤務) によって開発され、優れた一連の機能を備えています。 MySQL 高可用性環境でのフェイルオーバーおよびマスター/スレーブの昇格のための高可用性ソフトウェア。 MySQL フェイルオーバー プロセス中、MHA はデータベース フェイルオーバー操作を 0 ～ 30 秒以内に自動的に完了できます。フェイルオーバー プロセス中、MHA はデータの一貫性を最大限に確保して、ある意味での真の高可用性を実現します。

• MHA は、オープン ソースの MySQL 高可用性プログラムです。MHA がマスター ノードの障害を監視すると、最新のデータを持つスレーブ ノードが新しいマスター ノードになるように自動的に昇格します。

• MHA は、一貫性の問題を回避するために他のノードから追加情報を取得します。つまり、MHA は他のスレーブ ノードからデータ情報を取得し、その情報を最も近いマスター ノードスレーブ ノードに送信します。そのため、マスター ノードに障害が発生した場合、このスレーブ ノードがマスター ノードに昇格し、このスレーブ ノードは他のスレーブ ノードのすべてのデータ情報を保持します。

• MHA は、マスター ノードのオンライン切り替え機能、つまりオンデマンドでマスター/スレーブ ノードを切り替える機能も提供します。

MHA の基本コンポーネント

MHA は、MHA マネージャー (管理ノード) と MHA ノード (データ ノード) の 2 つの部分で構成されます。

MHA マネージャーは、複数のマスター/スレーブ クラスターを管理するために独立したマシンに個別に展開することも、スレーブ ノードに展開することもできます。

MHA 実装原理

• MHA ノードは各 MySQL サーバー上で実行されます。MHA マネージャーは定期的にクラスター内のマスター ノードを検出します。マスターに障害が発生した場合、マスター ノードが自動的に検出されます。最新のデータが新しいマスターにプロモートされ、その後、他のすべてのスレーブが新しい​​マスターにリダイレクトされます。フェイルオーバー プロセス全体は、アプリケーションに対して完全に透過的です。
• MHA 自動フェイルオーバー プロセス中、MHA はデータが最大限失われないように、ダウンしたメイン サーバーからバイナリ ログを保存しようとしますが、これは常に実現できるわけではありません。
• たとえば、メイン サーバー ハードウェアに障害が発生した場合、または ssh 経由でアクセスできない場合、MHA はバイナリ ログを保存できず、フェイルオーバーのみが行われ、最新のデータが失われます。 MySQL 5.5 の半同期レプリケーションを使用すると、データ損失のリスクを軽減できます。
• MHA は半同期レプリケーションと組み合わせることができ、1 つのスレーブのみが最新のバイナリ ログを受信した場合、MHA は最新のバイナリ ログを他のすべてのスレーブ サーバーに適用できるため、すべてのノードのデータの一貫性が保証されます。

MHA の使用シナリオ

現在、MHA は主に 1 マスター、複数スレーブのアーキテクチャをサポートしています。

• MHA を構築するには、レプリケーション クラスターに少なくとも 3 つのデータベース サーバー (1 つのマスターと 2 つのスレーブ) が必要です。つまり、1 つはマスターとして機能し、もう 1 つはバックアップ マスターとして機能し、もう 1 つはスレーブとして機能します。

• 少なくとも 3 台のサーバーが必要であるため、タオバオではマシンのコストを考慮してこれに基づいて変更を加えており、現在、タオバオ TMHA は 1 台のマスターと 1 台のスレーブをサポートしています。

• コード的に見ると、MHA は Perl スクリプトの集合体にすぎませんので、Alibaba の技術力があれば、1 つのマスターと 1 つのスレーブをサポートするように MHA を変更することは難しくないと思います。

MySQL マスター/スレーブ アーキテクチャ

この種のアーキテクチャはスタートアップ企業でよく使用されており、その後の段階的な拡張も容易になります

このアーキテクチャの特徴

1. 低コスト、高速かつ便利な導入
2. 読み取りと書き込みの分離
3. スレーブを追加することでライブラリの読み取りの負荷を軽減することもできますライブラリが間に合っている
4. マスター ライブラリの単一障害点
5. データ整合性の問題 (同期遅延が原因)

1. 高可用性ソフトウェアは、VIP、データ管理、および DRBD サービスを完全に担当するハートビートを使用できます。
2. マスター障害後に自動的かつ迅速に切り替えることができ、スレーブ ライブラリは引き続きデータを新しいマスター ライブラリと同期できます。 VIP 経由
3. #スレーブ ライブラリは読み取りと書き込みの分離もサポートしており、ミドルウェアまたはプログラムの実装で使用できます

MySQL Cluster の概要

MySQL Cluster テクノロジは、分散システム内の MySQL に冗長性機能を提供し、セキュリティを強化することでシステムの信頼性とデータの有効性を向上させることができます。 MySQL クラスターには一連のコンピューターが必要です。各コンピューターはノードとして理解でき、これらのノードの機能は異なります。 MySQL Cluster は、その機能に応じて、管理ノード、データ ノード、SQL ノードの 3 種類のノードに分類できます。クラスター内のコンピューターは、単一のノードであることも、2 つまたは 3 種類のノードの集合であることもできます。これらのノードを組み合わせることで、アプリケーションに信頼性とパフォーマンスの高いクラスター データ管理を提供できます。企業データの量が増加しているため、MySQL の要件がさらに増加し​​ています。以前の高可用性ソリューションのほとんどには、通常、MySQL レプリケーション ソリューションなど、特定の欠陥があります。マスターが正常かどうかを検出するには、一定の時間がかかります。マスター/スレーブの切り替えが必要な場合は、ある程度の時間がかかるため、高可用性は監視ソフトウェアと自動管理ツールに大きく依存します。 MySQL Cluster は継続的な開発により、最終的にパフォーマンスと高可用性が大幅に向上しました。

MySQL Cluster の基本概念

MySQL Cluster は単に MySQL クラスタ テクノロジであり、次のもので構成されています。コンピュータのグループ。各コンピュータは、MySQL サーバー、DNB クラスタ データ ノード、他のノードの管理、および特殊なデータ アクセス プログラムを含む 1 つ以上のノードを保存できます。これらのノードは、アプリケーションが高パフォーマンス、高可用性を備えたクラスタ データ管理を向上させるために結合されます。およびスケーラビリティ;

MySQL Cluster のアクセス プロセスは大まかに次のようになります。アプリケーションは通常、特定の負荷分散アルゴリズムを使用して、データ アクセスをさまざまな SQL ノードに分散します。SQL ノードはデータ ノードへのデータ アクセスを実行し、データ ノードからデータ結果を返します。管理ノード SQL ノードとデータ ノードのみを構成および管理します。

MySQL Cluster ノードについて

MySQL Cluster は、ノード タイプに応じて、管理ノード、SQL という 3 つのタイプのノードに分けることができます。ノード、データ ノード、これらすべてのノードは完全な MySQL クラスタ システムを構成します。実際、データは NDB ストレージ サーバーのストレージ エンジンに保存され、テーブル構造は MySQL サーバーに保存されます。アプリケーションは、 MySQL サーバーとクラスター管理サーバーは、管理ツール ndb_mgmd を通じて NDB ストレージ サーバーを管理します;

[1. 管理ノード]

管理ノードは、主に他のノードを管理するために使用されます。通常、config.ini ファイルは、クラスター内で維持する必要があるコピーの数、各データ ノードのデータとインデックスに割り当てるメモリの量、IP アドレス、各データ ノードにデータを保存するためのディスク パスを構成するように構成されます。

管理ノードは通常、クラスター構成ファイルとクラスター・ログを管理します。クラスター内の各ノードは、管理サーバーから構成情報を取得し、管理サーバーがどこにあるかを判断する方法を要求します。ノードで新しいイベントが発生すると、ノードはこのタイプのイベントの情報を管理サーバーに送信し、この情報をクラスター ログに書き込みます。

通常、MySQL には少なくとも 1 つの管理ノードが必要です。クラスター システム。データ ノードと SQL ノードは開始前にクラスター構成情報を読み取る必要があるため、通常は管理ノードが最初に開始されることにも注意してください;

[2.SQL ノード]

SQL ノードは単なる mysqld サーバーであり、アプリケーションはデータ ノードに直接アクセスできず、データを返すには SQL ノード経由でのみデータ ノードにアクセスできます。すべての SQL ノードはすべてのストレージ ノードに接続されているため、いずれかのストレージ ノードに障害が発生した場合、SQL ノードはリクエストを別のストレージ ノードに転送して実行できます。一般に、SQL ノードが多いほど優れています。SQL ノードが多いほど、各 SQL ノードに割り当てられる負荷が小さくなり、システム全体のパフォーマンスが向上します。

[3. データ ノード]

データ ノードは、クラスターにデータを保存するために使用されます。MySQL Cluster は、データ ノード間でデータをレプリケートします。いずれかのノードに障害が発生した場合、データを保存する別のデータ ノードが常に存在します。

通常は、この 3 つの異なるデータ ノードが使用されます。論理ノードは異なるコンピュータに分散できます。クラスタには少なくとも 3 台のコンピュータがあります。クラスタ サービスを正常に維持できるようにするため、通常、管理ノードは別のホストに配置されます。

推奨される学習: mysql ビデオ チュートリアル

以上がMySQL の高可用性アーキテクチャ テクノロジを一緒に分析しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。