:MGRモードの概要

利点

次の表は、データの信頼性、データの一貫性、およびグローバルトランザクションの一貫性の観点から、MGR、半同期レプリケーション、および非同期レプリケーションを比較しています。

高いデータ信頼性

MGRモードは、Paxosプロトコルの多数決ルールを使用して、高いデータ信頼性を確保します。 多数決ルールは、RDSクラスター内の大多数のノードがトランザクションのバイナリログを受信した後にのみ、RDSクラスターの各ノードでトランザクションをコミットできることを指定します。 これにより、RDSクラスター内のノードに障害が発生した場合のデータ損失を防ぎます。

たとえば、RDSクラスターには5つのノードがあります。 3つのノードがトランザクションのバイナリログを受信し、2つのノードがバイナリログを受信していません。 2つのノードに障害があります。

• 障害のあるノードがバイナリログを受信した場合、バイナリログを受信した少なくとも1つのノードが正常に実行されます。

• 障害のあるノードがバイナリログを受信していない場合、バイナリログを受信した3つのノードが正常に実行されます。

強力なデータ一貫性

MGRモードでは、トランザクションはRDSクラスターのセカンダリノードにコミットされ、バイナリログファイルに書き込まれます。 プライマリノードが故障した場合、故障したプライマリノード上のデータ量は、故障したプライマリノードが再起動された後、新たに選択されたプライマリノード上のデータ量以下である。 障害のあるプライマリノードが再起動されると、自動的にRDSクラスターに参加し、不足しているバイナリログが再起動されたプライマリノードに自動的に同期され、プライマリノードとセカンダリノード間のデータの一貫性が確保されます。

プライマリ /セカンダリレプリケーションモードでは、トランザクションはバイナリログファイルに書き込まれ、セカンダリノードにコミットされます。 トランザクションがバイナリログに書き込まれた後、セカンダリノードにコミットされる前にプライマリノードに障害が発生した場合、障害のあるプライマリノードのデータ量は、障害のあるプライマリノードが再起動された後のセカンダリノードのデータ量よりも大きくなります。 この場合、セカンダリノードの1つが新しいプライマリノードとして選択されると、新しいプライマリノード上のデータ量は、元のプライマリノード上のデータ量よりも少なくなる。 これにより、プライマリノードとセカンダリノード間でデータの不一致が発生します。

グローバルトランザクションの整合性

MGRモードは、ノード間の読み取りおよび書き込み操作に強力なグローバル一貫性を提供します。 group_replication_consistencyパラメーターを使用して、ビジネス要件に基づいて読み取りおよび書き込み操作の整合性レベルを指定できます。

• セカンダリノードの読み取り一貫性が強い: RDSクラスターのセカンダリノードのセッションレベルgroup_replication_consistencyパラメーターをBEFOREに設定できます。 この場合、セカンダリノードでクエリAを実行すると、プライマリノードで必要なトランザクションが適用された後にのみクエリAが実行されます。 必要なトランザクションは、クエリAの前に実行されるクエリを含むトランザクションを示します。このようにして、セカンダリノードとプライマリノードから読み取られるデータは一貫しています。

• プライマリノードの強力な書き込み整合性: RDSクラスターのプライマリノードのセッションレベルgroup_replication_consistencyパラメーターをAFTERに設定できます。 この場合、書き込みトランザクションをコミットすると、トランザクションはRDSクラスター内のすべてのノードに適用された後にコミットされます。

デプロイ方法

MGRモードを使用するRDSクラスターは、シングルリーダーモードとマルチリーダーモードをサポートしています。

• 複数のリーダー

  RDSクラスター内のすべてのノードが読み取りおよび書き込みリクエストを処理できます。 複数リーダーモードを使用して、RDSクラスターの書き込み機能を強化します。 マルチリーダーモードは、Paxosプロトコルのマルチポイントデータ書き込み戦略を採用し、行レベルの競合に対する競合検出を使用します。 これにより、すべてのノードが同じ順序でデータを受信してマルチポイント書き込みを実装することが保証されます。

  ただし、複数リーダーモードのRDSクラスターの安定性は低くなります。 RDSクラスター内の大多数のノードが使用可能な場合、ノードの障害がRDSクラスターの可用性に影響します。

• シングルリーダー

  RDSクラスター内の1つのノードのみが書き込みリクエストを処理できます。 RDSクラスター内の他のノードは読み取り要求のみを処理します。 シングルリーダーモードは、Paxosプロトコルのシングルリーダー複製戦略を採用しています。 これにより、読み取り機能が向上し、データの信頼性が向上し、RDSクラスターの高可用性が維持されます。

  • RDSクラスター内のノードの過半数が使用可能な場合、RDSクラスター内のセカンダリノードに障害が発生しても、RDSクラスターの可用性は影響を受けません。

  • プライマリノードに障害がある場合、RDSクラスターは、RDSクラスター内の強力なデータ一貫性を確保しながら、Paxosプロトコルに基づいてプライマリ /セカンダリの切り替えを自動的に完了します。

  ApsaraDB RDS for MySQLでは、シングルリーダーモードでMGRモードを使用するRDSクラスターを作成できます。 RDSクラスターでは、読み取り専用ノードが最適化され、RDSクラスターのパフォーマンスが向上し、高いデータ信頼性と強力なデータ一貫性が確保されます。

アーキテクチャ

MGRのアーキテクチャには、MySQLのサーバーレイヤーとレプリカレイヤーの下に次のレイヤーがあります。

• グループ複製ロジック層: この層は、スタンドアロンMySQLのサーバー層の下に追加され、フックを使用してグループ通信システム (GCS) 層に接続されます。 この層は、GCS層との間でトランザクションを送受信し、トランザクションを再生することができる。

• GCS層: この層は、XCom層と連携して、グループ複製論理層とクラスタとの間の通信を可能にする。 GCS層はまた、障害を検出し、クラスタメンバーを管理する。

• XCom層: この層は、Paxosプロトコルに基づいて開発される。 XCom層は、GCS層と連携して、グループ複製論理層とクラスタとの間の通信を可能にする。 XComレイヤーは、データ送信のグローバルな順序を保証し、クラスタメンバーの役割を変更できます。 XCom層はまた、すべてのノードが同じ順序でデータを受信することを保証する。 クラスター内のノードの大部分が使用可能な場合、XComレイヤーはデータの損失を防ぐのに役立ちます。

XComレイヤー

Paxosプロトコル

次のリストは、MGRモードのPaxosプロトコルの機能を説明しています。

• クラスター内のすべてのノードがトランザクションのバイナリログを同じ順序で受信するようにします。これは、複数のリーダーモードに不可欠です。

• クラスター内の大多数のノードがトランザクションのバイナリログを受信した後にのみトランザクションをコミットできるようにします。これはデータの信頼性に不可欠です。 クラスター内のノードの大部分が使用可能な場合、データは失われません。

Paxosプロトコルでは、ノード間のデータ送信順序の一貫性を達成するためにロックが使用される。 この方法は非効率的であり、ノード間の負荷が不均衡になる。 MySQLのXCom層は、PaxosベースのバリアントプロトコルであるMenciusプロトコルに依存しています。 Menciusプロトコルは、ポーリングメカニズムを使用して開発されたリーダーレスのPaxosプロトコルです。 このプロトコルは、ノード間の負荷を効果的にバランスする。

複数リーダーモードの実装

マルチリーダーモードは、Menciusプロトコルに基づいて実装されます。 Menciusプロトコルでは、クラスター内の各ノードは、他のノードへの接続をプロアクティブに確立して、単一リーダーのPaxosグループをリードします。 クラスタがn個のノードを含む場合、互いに干渉しないn個のPaxosグループが形成される。 各Paxosグループでは、リーダーノードのみがデータを送信できます。 残りのノードの大部分がデータを受信すると、データは正常に送信されます。 ノード上のクライアントがデータを受信すると、ノードはそのPaxosグループ内のリーダーとしてデータをグループ内の他のノードにシリアルに送信します。 これにより、各Paxosグループで同じデータ送信順序が保証されます。

データが複数のPaxosグループから送信される場合、データ送信順序を保証するためにポーリングメカニズムが使用されます。 複数のPaxosグループからデータを受信した後、XComレイヤーは指定された順序でデータをグループ複製ロジックレイヤーに送信します。 上の図は、データが (1,1) 、(1,2) 、および (1,3) の順序でグループレプリケーション論理層に送信されなければならないことを示しています。

ノードの後にリストされたノードのデータがクラスタ内の大多数のノードによって受信され、ノード上のデータが送信される必要がない場合、ノードはnoop状態をブロードキャストして、ノード自体をスキップすることを他のノードに通知する。 ノードは、ノードがそのデータを送信するか、またはnoop状態をブロードキャストする前にリストされたノードの後にのみ、データを送信できます。 ジッタまたは障害がノード上で検出されると、ノードはデータを送信することができず、noop状態をブロードキャストすることができない。 この場合、ノードの後にリストされているノードはデータを送信できず、クラスターは使用できません。 これは、マルチリーダーモードの重大な欠陥です。

シングルリーダーモードの実装

マルチリーダーモードの欠陥は最適化できますが、排除することはできません。 したがって、MySQLはMGRモードにシングルリーダーモードを提供します。 これにより、クラスター内の少数のノードに障害がある場合にクラスターが利用できなくなります。

上の図は、1つのノードのみが書き込み要求を処理できるシングルリーダーモードのXComアーキテクチャを示しています。 したがって、1つのPaxosグループのみをアクティブにする必要があります。 データがポーリングされると、受信機は他のPaxosグループを自動的に無視します。 このように、Paxosプロトコルは、クラスタ内のノードの大部分が利用可能である限り、クラスタの利用可能性に影響を与えることなくデータを送信するために使用することができる。

シングルリーダーモードでは、クラスター内のセカンダリノードはトランザクションを送信しません。 セカンダリノードは、クラスター管理に関する情報を送信します。 セカンダリノードがデータを送信する前に、セカンダリノードはプライマリノードからデータを送信する場所を要求し、クラスター内のすべてのノードにデータを送信する必要があります。 たとえば、前の図の <3,1> は、データ送信の場所を示しています。 シングルリーダーモードでは、データは高いレイテンシと低い効率で送信されますが、クラスタ管理に関する情報は比較的低い頻度で送信されるため、クラスタのパフォーマンスには影響しません。

グループ複製ロジック層

グループ複製論理層は、クラスタとの間でトランザクションを送受信し、トランザクションを再生する。 次のリストは、プライマリノードとセカンダリノードでのグループレプリケーションロジック層の動作を示しています。

• プライマリノード: プライマリノードでトランザクションがコミットされる前に、グループレプリケーション論理レイヤーはトランザクションのバイナリログをXComレイヤーに送信し、クラスター内の他のノードに送信します。 クラスタ内の大多数のノードがトランザクションを受信した後、競合検出が実行される。 トランザクションが競合検出に合格した場合、トランザクションはバイナリログファイルに書き込まれ、プライマリノードでコミットされます。 トランザクションが競合検出に失敗した場合、トランザクションはロールバックされます。

• セカンダリノード: クラスタ内の大多数のノードがトランザクションを受信した後、グループ複製論理層は、競合検出を実行するためにXCom層からグループ複製論理層にトランザクションを送信する。 トランザクションが競合検出に合格した場合、トランザクションはリレーログに書き込まれ、アプライアスレッドによって適用されます。 トランザクションがコンフリクト検出に失敗した場合、トランザクションのデータは破棄される。

競合の検出

• シナリオ

  MGRモードでは、シナリオによっては、異なるノードのトランザクションを同じノードで実行する必要があります。 したがって、競合検出は、トランザクション変更が互いに競合しないことを保証するために、ノードのトランザクションに対して実行されなければならない。 次のリストは、シナリオを説明しています。

  • 複数リーダーモードでは、すべての書き込み操作に競合検出が必要です。

  • シングルリーダーモードでは、プライマリ /セカンダリの切り替えが実行され、元のプライマリノードのリレーログが新しいプライマリノードに適用される前に書き込みトランザクションが実行される場合、競合の検出も必要です。

• 実装

  MGRモードでは、行レベルの競合検出は、データ行の主キーのハッシュ値を使用して実行されます。 各ノードは、ハッシュ配列であるトランザクション認証情報の配列を保持する。 ハッシュ配列は、データ行のハッシュ値をキーとして使用し、現在のトランザクションがソースノードでコミットされる前に取得された、データ行とgtid_executedを変更する現在のトランザクションのグローバルトランザクション識別子 (GTID) の和集合を値として使用します。 gtid_executedは、ソースノードでコミットされたすべてのトランザクションのGTIDセットを指定します。

  トランザクションがソースノードでコミットされる前に、システムは、トランザクションによって変更され、ソースノードでgtid_executedされたデータをクラスター内の他のノードに送信します。 gtid_executedには、現在のトランザクションがコミットされる前にソースノードでコミットされたトランザクションが含まれます。 gtid_executedは、以下、コミットメントセットと呼ばれる。

  クラスタ内のソースノードを含むすべてのノードは、現在のトランザクションによって変更されたすべてのデータ行のハッシュ値をキーとして使用し、認証情報配列からキーの値を読み取り、これらの値をGTIDセットに入れます。 GTIDセットは、現在のトランザクションがコミットされる前にコミットされなければならないトランザクションを指定する。 このGTIDセットは、以下、依存関係セットと呼ばれる。

  現在のトランザクションがコミットまたはリレーログに書き込まれる前に、システムは次の観点からコミットメントセットと依存関係セットを比較します。

  • コミットメントセットに依存関係セットが含まれている場合、データ行を変更したすべてのトランザクションがコミットされます。 この場合、現在のトランザクションは競合検出に合格する。 システムは、現在のトランザクションをバイナリログに書き込み、ソースノードでトランザクションをコミットし、現在のトランザクションを他のノードのリレーログに書き込みます。

  • コミットメントセットに依存関係セットが含まれていない場合、データ行を変更したトランザクションはコミットされません。 この場合、現在のトランザクションはコンフリクト検出に失敗する。 システムは、ソースノードの現在のトランザクションをロールバックし、他のノードのリレーログを破棄します。

  ストレージの使用量を減らすためには、認証情報配列の冗長なデータをできるだけ早く削除する必要があります。 トランザクションがクラスター内のすべてのノードで実行された場合、トランザクションは他のトランザクションと競合しません。 この場合、トランザクションによって変更されたすべてのデータ行を認証情報配列から削除することができる。 MGRモードでは、実行されるトランザクションのデータは60秒ごとに削除されます。

MGRモードの安定性に関するAliSQLによる最適化

MGRの安定性は、シングルリーダーモードを使用すると大幅に改善されます。 ただし、いくつかのシナリオでは安定性の問題が依然として存在します。 セカンダリノードのレイテンシが大きい場合、多数のトランザクションを適時に適用することはできません。 その結果、大量の認証情報が蓄積され、次のような問題が発生する可能性があります。

• 大量のメモリが占有され、メモリ不足 (OOM) エラーが発生する可能性があります。

• 蓄積された認証情報を削除するためのオーバヘッドが高く、クラスタの安定性に影響を及ぼす。

次のリストは、AliSQLがプライマリノードとセカンダリノードで蓄積された認証情報の削除を最適化する方法を示しています。

• プライマリノード: 認証情報配列は使用されません。 したがって、認証情報アレイをプライマリノードから削除して、プライマリノードのリソースおよび安定性に対する悪影響を排除することができる。

• セカンダリノード: group_replication_consistencyパラメーターがEVENTUALに設定されている場合のみ、認証情報を保持する必要があります。 group_replication_consistencyパラメーターがEVENTUALに設定されている場合、セカンダリノードは、セカンダリノードがプライマリノードとして選択された後、リレーログが再生されるまで待つ必要なく、すぐに外部サービスを提供します。 これにより、データ操作の競合が発生する可能性があります。 この設定は一般的には使用されません。 group_replication_consistencyパラメーターをEVENTUALに設定できない場合、セカンダリノードに保持される認証情報の量が減少します。 これにより、セカンダリノードのメモリ消費が削減され、クラスタの安定性が向上します。