MySQL の高可用性アーキテクチャテクノロジを一緒に分析しましょう-mysql チュートリアル-php.cn

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

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

#背景説明

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

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

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

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

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

MMM

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

MMM は Perl 言語を使用して開発されており、主に MySQL のマスター-マスター (デュアルマスター) レプリケーションの監視と管理に使用されます。ビジネスでは同じ時間のみが許可されます。一方のマスターに書き込み、もう一方の代替マスターで部分的な読み取りサービスを提供して、マスター間の切り替え時の代替マスターのウォームアップを高速化します。
MMM の監視側は、書き込み可能な VIP と複数の読み取り可能な VIP を含む複数の仮想 IP (VIP) を提供します。監視管理を通じて、これらの IP は利用可能な mysql にバインドされます。がダウンすると、vip が他の mysql に移行されます。
#MMM スクリプトプログラムはフェイルオーバー機能を実装する一方で、追加の内部ツールスクリプトによって複数のスレーブの読み取り負荷分散を実現することもできます。
このパッケージは、標準のマスター/スレーブ構成に基づいて任意の数のスレーブサーバーにわたる負荷分散を読み取ることもできるため、これを使用して、複製されたサーバーのグループで起動することができます。さらに、仮想 IP には、ノード間のデータバックアップおよび再同期機能を実装するスクリプトも含まれています。

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

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

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

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

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

MMM の使用シナリオ

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

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

公式 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 マスター/スレーブアーキテクチャ

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

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

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

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

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 サイトの他の関連記事を参照してください。