MySQLの高可用性アーキテクチャの詳細な説明

導入

「高可用性」はインターネット上で永遠の話題です。ここでは MySQL については触れません。さまざまなサービスの高可用性を確保するためによく使用されるソリューションがいくつかあります。

サービスの冗長性: サービスの複数のコピーを展開し、ノードが使用できない場合は他のノードに切り替えます。ステートレス サービスの場合、サービスの冗長化は比較的簡単です。

サービス バックアップ: Nginx リバース プロキシや一部のクラスターのリーダー ノードなど、一部のサービスは複数のランタイムに同時に存在できません。この時点で、バックアップ サービスが存在し、常にスタンバイ状態になります。

自動切り替え: サービス冗長化後、ノードが利用できなくなった場合は、迅速な切り替えが必要になります。

要約すると、冗長性 + フェイルオーバーです。

MySQL 高可用性

MySQL の高可用性も同じ考え方に基づいています。まず、サービスを提供するには複数の MySQL インスタンスが必要です。次に、インスタンスに障害が発生した場合、トラフィックを自動的に切り替えることができます。同時に、MySQL をストレージとして使用する場合、ノード間のデータ同期も問題になります (つまり、すべてのステートフル サービスがこの問題に直面します)。

マスター 1 つとバックアップ 1 つ:

MySQL のさまざまな高可用性アーキテクチャは、MySQL インスタンス間のデータ同期と切り離すことはできません。そのため、最初に最も単純な 1 アクティブ 1 スタンバイ アーキテクチャでの MySQL のデータ同期プロセスを紹介します。

上図はマスター・スレーブ間のデータ同期の概略図です。

マスター ノードには、バイナリ ログ内のデータをスレーブ ノードに送信するダンプ プロセスがあります。

スレーブ ノードには、データを受信して​​リレー ログに書き込む IO プロセスがあります。

スレーブノードの SQL プロセスはリレーログに従ってデータを書き込みます。

ここで少し拡張する必要があります。Binlog には、Statement、Row、Mixed の 3 つの形式があります。

ステートメント: 各 SQL ステートメントを binlog に記録します。

行: 各行の変更の特定のデータを binlog に記録します。

混合: MySQL は、SQL を記録する必要があるか、特定の変更されたレコードを記録する必要があるかを柔軟に区別します。

SQL のみが記録される場合、binlog は小さくなります。ただし、マスターとスレーブ間でデータを同期する場合、一部の SQL ステートメントでは、異なるインデックスの選択により、データ同期プロセス中にデータの不整合が発生する可能性があります。行を記録すると、マスターとスレーブの同期で SQL の意味の逸脱がなくなることが保証されます。同時に、行タイプのログはデータの回復が容易ですが、行によってバイナリログが大きくなりすぎます。

MySQL マスター スレーブ同期のいくつかのモード:

非同期モード:
この同期戦略では、マスター データベースは、マスター データベースとスレーブ データベース間のデータ同期を待たずに、独自のプロセスに従ってデータを処理した後、結果を直接返します。 利点: 高い効率。 欠点: マスター ノードがハングアップすると、スレーブ ノードのデータが失われます。完全同期モード: マスター データベースは、すべてのスレーブ データベースが SQL ステートメントの実行と ACK の完了を完了するまで待機してから、成功を返します。 利点: 優れたデータ一貫性の保証。 デメリット: データ操作の遅延が発生し、MySQL スループットが低下します。半同期モード: マスター データベースは、少なくとも 1 つのスレーブ データベースがリレー ログにデータを書き込み、ACK が完了するまで待機してから、結果を正常に返します。 半同期モードは、非同期モードと完全同期モードの中間です。

半同期レプリケーション ソリューションは、MySQL 5.5 で導入されました。一般的な半同期レプリケーション ソリューションの手順は次のとおりです。

マスターノードは、Binlog にデータを書き込み、同期操作を実行します。マスターはスレーブ ノードにデータを送信し、マスター データベースのトランザクションをコミットします。 ACK を受信すると、マスター ノードはデータをクライアントに返します。

このデータ送信モードはafter_commitと呼ばれます。

after_commit モードには問題があります。マスター データベースが ACK を待機しているときに、トランザクションはコミットされており、マスター データベース内の他のトランザクションはコミットされたデータを読み取ることができます。このとき、マスターがクラッシュしてスレーブ データが失われ、マスターとスレーブの切り替えが発生すると、ファントム リードが発生します。 この問題を解決するために、MySQL 5.7では新しい半同期レプリケーションモードafter_syncが導入されました。

上記の問題は、メイン データベースのトランザクション送信を ACK の後に置くことで回避されます。 MySQL 5.7では、スレーブがslave_parallel_workers > 0に設定され、
global.slave_parallel_type = 'LOGICAL_CLOCK' は、slave_parallel_workers ワーカー スレッドをサポートして、マスターによって送信されたトランザクションを 1 つのスキーマのリレー ログで同時に実行できるため、マスターとスレーブ間のレプリケーションの効率が大幅に向上します。 MySQL 5.7の半同期機能は、
rpl_semi_sync_master_wait_slave_count パラメータは、マスターとスレーブの同期が完了したとみなされるスレーブ ノードからの ACK の数を設定します。

MySQL のマスター スレーブ同期データがますます完璧かつ効率的になるにつれて、最初の MySQL 高可用性アーキテクチャが導入されました。MySQL 独自のマスター スレーブ同期ソリューションに基づいて、一般的に使用される展開アーキテクチャは次のとおりです。ユーザーは VIP を介してマスター ノードとスレーブ ノードにアクセスし、各ノードは keepalved 探索を使用します。マスターとスレーブの関係を構成し、データを同期します。

MHA に基づく高可用性アーキテクチャ: MHA マネージャー ノードをデプロイし、各 MySQL インスタンスに MHA ノード ノードをデプロイします。 MHA は数秒以内に自動フェイルオーバーを実現できます。 もちろん、MySQL ノード間のデータ同期も、MySQL 独自のデータ同期方法に依存します。

MGR (MySQL グループ レプリケーション) モード: MySQL の担当者は MGR クラスター ソリューションについてより楽観的であるように感じますが、中国のどの企業がまだそれを使用しているかはわかりません。 MGR クラスターはすべて MySQL サーバーで構成されています。各サーバーには完全なレプリカ データがあります。レプリカは行形式のログと GTID に基づいてデータを同期し、Paxos アルゴリズムを使用してデータの一貫性を確保します。 MGRアーキテクチャは、上記の半同期および非同期データ同期方式よりも複雑です。詳細については、公式Webサイトを参照してください。

要約する

MySQL の高可用性アーキテクチャに特効薬はありません。その原理を理解し、ビジネス シナリオに適したデプロイメント アーキテクチャを選択してください。

MySQL の高可用性アーキテクチャの詳細な説明に関するこの記事はこれで終わりです。MySQL の高可用性アーキテクチャに関するより関連性の高いコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。