技術共有

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

オープンソースエコシステム

ご存知のとおり、MySQL のプライマリ データベースとセカンダリ データベース (2 つのノード) は、通常、非同期レプリケーションと半同期レプリケーション (Semi-Sync) を通じて高いデータ可用性を実現します。ただし、コンピュータ ルームのネットワーク障害やホストのハングアップなどの異常なシナリオでは、プライマリ アーキテクチャとセカンダリ アーキテクチャでは、HA 切り替え後に重大な問題が発生する可能性があります (RPO!=0 と呼ばれます)。したがって、ビジネス データがある程度重要な場合は、MySQL プライマリ アーキテクチャとセカンダリ アーキテクチャ (2 ノード) のデータベース製品を選択すべきではありません。RPO=0 のマルチコピー アーキテクチャを選択することをお勧めします。

RPO=0 でのマルチコピー テクノロジーの進化に関する MySQL コミュニティ:

• MySQL は正式にオープン ソースであり、グループ レプリケーションに基づく MySQL グループ レプリケーション (MGR) 高可用性ソリューションを開始しました。Paxos プロトコルは、データの一貫性を確保するために XCOM を通じて内部的にカプセル化されています。
• アリ・クラウド ポーラーDB-X 、アリババの電子商取引ダブルイレブンとさまざまな場所でのマルチアクティビティのビジネスの磨きと検証から派生したもので、2021年10月にコア全体がオープンソース化され、MySQLオープンソースエコシステムを完全に採用します。 PolarDB-X は、集中型および分散型の統合データベースとして位置付けられており、そのデータ ノード Data Node (DN) は自社開発の X-Paxos プロトコルを採用しており、MySQL 5.7/8.0 との高い互換性を備えているだけでなく、財務レベルの高可用性機能を提供します。だけでなく、拡張性の高いトランザクション エンジン、柔軟な運用と保守の災害復旧、および低コストのデータ ストレージという特徴もあります。PolarDB-X オープンソース | Paxos ベースの MySQL の 3 つのコピー》。

ポーラーDB-X集中型および分散型統合の概念: データ ノード DN は、スタンドアロン データベース フォームと完全に互換性のある集中型 (標準バージョン) フォームとして独立して使用できます。ビジネスが分散拡張が必要になるまで成長すると、アーキテクチャは適切な分散形式にアップグレードされ、分散コンポーネントは元のデータ ノードにシームレスに接続されます。アプリケーション側でのデータの移行や変更は必要ありません。この式、アーキテクチャの説明によってもたらされる使いやすさと拡張性を楽しむことができます。「集中分散統合」

MySQL の MGR と PolarDB-X の標準バージョン DN はどちらも最下層の原理から Paxos プロトコルを使用しています。では、実際の使用における具体的なパフォーマンスと違いは何でしょうか。この記事では、アーキテクチャの比較、主な違い、テストの比較について詳しく説明します。

MGR/DN 略語の説明: MGR は MySQL MGR の技術形式を表し、DN は PolarDB-X 単一 DN 集中型 (標準バージョン) の技術形式を表します。

要約

詳細な比較分析は比較的長いため、興味があれば最初に概要と結論を読んで、その後の記事でヒントを探すことができます。

MySQL MGR を使いこなすには専門的な技術知識と運用保守チームが必要なため、一般の企業や企業には推奨されません。この記事では、業界で長年出回っている MySQL MGR の 3 つの「隠れた落とし穴」も再現しています。 :

• ダーク ピット 1: MySQL MGR および XCOM プロトコルはフル メモリ モードを採用しており、デフォルトでは RPO=0 のデータ整合性保証を満たしていません (この記事の後半でテスト ケースでデータ欠落の問題が発生します)。現在、MGR の設計ではパフォーマンスと RPO の両方を達成できません。
• 落とし穴 2: ネットワーク遅延が発生すると、MySQL MGR のパフォーマンスが低下します。この記事では、4 分間のネットワーク シナリオ (同じ都市の 3 つのコンピュータ ルームと 2 か所の 3 つのセンターを含む) の比較をテストしました。都市のパフォーマンス パラメータは、同じ都市の 1/5 にすぎません。RPO=0 のデータ保証がオンになっている場合、パフォーマンスはさらに悪くなります。したがって、MySQL MGR は、同じコンピュータ ルームのシナリオでの使用には適していますが、コンピュータ ルーム間の災害復旧には適していません。
• 落とし穴 3: MySQL MGR のマルチコピー アーキテクチャでは、スタンバイ ノードの障害によりマスター ノード リーダーのトラフィックが 0 に低下します。これは常識と一致しません。この記事では、(MySQL の以前のマスター/スレーブ レプリカ アーキテクチャと比較して) MGR のシングル リーダー モードを有効にすることに焦点を当て、スレーブ レプリカのダウンタイムと回復という 2 つのアクションをシミュレートします。これにより、スレーブ ノードの運用とメンテナンスの操作によってマスターも停止されます。ノード (リーダー) が表示され、トラフィックが 0 になり (約 10 秒間継続)、全体的な操作性と保守性が比較的悪かった。したがって、MySQL MGR にはホストの運用とメンテナンスに関する要件が比較的高く、専門の DBA チームが必要です。

MySQL MGR と比較すると、PolarDB-X Paxos には、データの一貫性、コンピュータ ルーム間の災害復旧、ノードの運用とメンテナンスの点で MGR のような落とし穴はありませんが、災害復旧においてはいくつかの小さな欠点と利点もあります。

• 同じコンピュータ室の単純なシナリオでは、同時実行性が低い場合の読み取り専用パフォーマンスと同時性が高い場合の純粋な書き込みパフォーマンスは、MySQL MGR よりもわずかに約 5% 低くなります。複数のコピーがネットワーク経由で同時に送信されます。パフォーマンスにはさらに最適化の余地があります。
• 利点: MySQL 5.7/8.0 の機能と 100% 互換性があると同時に、マルチコピー スタンバイ データベース レプリケーションおよびフェイルオーバー パスでより効率的な最適化が行われ、高可用性スイッチング RTO <= 8 秒 (一般的な 4 秒) です。業界における - 分の災害復旧シナリオ。すべて良好なパフォーマンスを示し、半同期 (準同期)、MGR などを置き換えることができます。

1. アーキテクチャの比較

用語集

MGR/DN 略語の説明:

1. MGR: MySQL MGR の技術形式、後続のコンテンツの略語: MGR
2. DN: Alibaba Cloud PolarDB-X は集中型 (標準バージョン) の技術形式です。分散データ ノード DN は、独立して集中型 (標準バージョン) の形式として使用できます。以下の内容は省略されています。として:DN

MGR

MGR はシングルマスター モードとマルチマスター モードをサポートし、イベント、Binlog & Relaylog、Apply、Binlog apply Recovery、GTID などの MySQL のレプリケーション システムを完全に再利用します。 DN との主な違いは、MGR トランザクション ログの多数派がコンセンサスに達するためのエントリ ポイントが、メインのデータベース トランザクションがコミットされる前であることです。

• リーダー：

1. 1. トランザクションがコミットされる前に、before_commit フック関数 group_replication_trans_before_commit が呼び出され、MGR のマジョリティ レプリケーションに入ります。
   2. MGR は、Paxos プロトコルを使用して、THD にキャッシュされた Binlog イベントをすべてのオンライン ノードに同期します。
   3. 過半数の応答を受信した後、MGR はトランザクションを送信できると判断します。
   4. THD はトランザクション グループの送信プロセスに入り、ローカルの Binlog 更新 REDO 応答クライアント OK メッセージの書き込みを開始します。

• フォロワー：

1. 1. MGR の Paxos エンジンは、リーダーからのプロトコル メッセージをリッスンし続けます。
   2. Paxos のコンセンサス プロセスが完了した後、この (バッチ) イベントがクラスター内の過半数に達したことが確認されます。
   3. 受信したイベントをリレーログに書き込み、IOスレッドをリレーログに適用
   4. リレー ログ アプリケーションは完全なグループ送信プロセスを経て、最終的にスタンバイ データベースが独自の binlog ファイルを生成します。

MGR が上記のプロセスを採用する理由は、MGR がデフォルトでマルチマスター モードになっており、各ノードが書き込みできるため、単一の Paxos グループ内のフォロワー ノードは、まず受信したログを RelayLog に変換してから結合する必要があるためです。送信するリーダーとして受信した書き込みトランザクションを使用して、2 段階のグループ送信プロセスで最後のトランザクションを送信するために Binlog ファイルが作成されます。

DN

DN は MySQL の基本的なデータ構造と関数レベルのコードを再利用しますが、ログ レプリケーション、ログ管理、ログ再生、およびクラッシュ リカバリを X-Paxos プロトコルと密接に統合して、独自の多数派レプリケーションとステータス マシン メカニズムのセットを形成します。 MGR との主な違いは、DN トランザクション ログの多数派がコンセンサスに達するためのエントリ ポイントが、メインのデータベース トランザクション送信プロセス中にあることです。

• リーダー：

1. 1. トランザクションのグループ送信プロセスに入ります。グループ送信のフラッシュ フェーズでは、各 THD のイベントが Binlog ファイルに書き込まれ、ログが X-Paxos を通じてすべてのフォロワーに非同期的にブロードキャストされます。
   2. グループ送信の同期フェーズでは、最初に Binlog が永続化され、次に X-Paxos 永続化の場所が更新されます。
   3. グループ送信のコミットフェーズでは、まず X-Paxos が過半数の応答を受け取るまで待機し、次にトランザクションのグループを送信し、最後にクライアントから OK メッセージで応答する必要があります。

• フォロワー：

1. 1. X-Paxos はリーダーからのプロトコル メッセージをリッスンし続けます。
   2. (グループ) イベントを受信し、ローカルの Binlog に書き込み、応答します。
   3. 次のメッセージが受信されます。このメッセージには、過半数に達したポジションのコミット インデックスが含まれます。
   4. SQL 適用スレッドは、受信した Binlog ログをバックグラウンドで適用し続け、最大でも過半数の位置にのみ適用します。

この設計の理由は、DN が現在シングルマスター モードのみをサポートしているため、X-Paxos プロトコル レベルのログは Binlog 自体であり、フォロワーもリレー ログとその永続ログとリーダーのログのデータ コンテンツを省略しているためです。は同じ価格に等しい。

2. 主な違い

2.1. Paxos プロトコルの効率

MGR

• MGR の Paxos プロトコルは、Multi-Paxos 理論に属する Mencius プロトコルに基づいて実装されています。異なる点は、Mencius がマスター ノードの負荷を軽減し、スループットを向上させる最適化改良を行っていることです。
• MGR の Paxos プロトコルは XCOM コンポーネントによって実装され、マルチマスター モードとシングルマスター モードの展開をサポートします。シングルマスター モードでは、リーダー上の Binlog が、メッセージの各バッチ (トランザクション) をアトミックにブロードキャストします。標準の Multi-Paxos プロセス。
• トランザクションの大部分を満たすために、XCOM は Accept+AckAccept+Learn という少なくとも 3 つのメッセージ インタラクションを通過する必要があります。少なくとも 1.5​​ RTT オーバーヘッド。最大 3 つのメッセージ インタラクション (Prepare+AckPrepare+Accept+AckAccept+Learn) が必要です。つまり、合計で最大 2.5 RTT のオーバーヘッドが発生します。
• Paxos プロトコルは XCOM モジュール内で高い凝集性を持って完成し、MySQL レプリケーション システムを認識しないため、リーダーは、Binlog の永続化やグループの送信など、ローカルでトランザクションをコミットする前に、完全な Paxos プロセスが完了するまで待つ必要があります。
• フォロワーが過半数の送信を完了すると、イベントを非同期的にリレー ログに保存し、SQL スレッド アプリケーションとグループが運用環境のバイナリ ログを送信します。
• Paxos によって同期されるログは、グループ送信プロセスに入る前にソートされていない Binlog であるため、リーダー上の Binlog イベントの順序は、フォロワー ノード上のリレー ログ内のイベントの順序と同じではない可能性があります。

DN

• DN の Paxos プロトコルは Raft プロトコルに基づいて実装されており、Multi-Paoxs 理論にも属しています。違いは、Raft プロトコルの方がより強力なリーダーシップの保証とエンジニアリングの安定性の保証を備えていることです。
• DN の Paxos プロトコルは、X-Paoxs コンポーネントによって完了します。シングルマスター モードでは、リーダー上の Binlog が標準の Raft プロセスでアトミックにブロードキャストされます。 。
• トランザクションの大部分を満たすために、X-Paoxs は Append+AckAppend という 2 つのメッセージ対話を実行するだけで済みます。1 RTT オーバーヘッド
• リーダーがログをフォロワーに送信した後、過半数が満たされている限り、第 2 段階のコミット インデックス ブロードキャストを待たずにトランザクションをコミットします。
• Follower が大部分の送信を完了するには、すべてのトランザクション ログを永続化する必要があります。これは、MGR が XCOM メモリ内で受信するだけで済むこととは大きく異なります。
• Commit Index は後続のメッセージおよびハートビート メッセージに引き継がれ、CommitIndex がプッシュアップされた後、Follower が適用イベントを実行します。
• リーダーとフォロワーの Binlog の内容は同じ順序であり、Raft ログには穴がなく、バッチ/パイプライン メカニズムを使用してログ レプリケーションのスループットが向上します。
• MGR と比較すると、リーダーではトランザクションがコミットされるときに常に 1 往復の遅延のみが発生します。遅延に敏感な分散アプリケーションにとって非常に重要です

2.2. RPO

理論的には、Paxos と Raft はどちらもデータの一貫性を確保でき、クラッシュ リカバリ後に大部分に達したログは失われませんが、特定のプロジェクトでは依然として違いがあります。

MGR

XCOM は Paxos プロトコルを完全にカプセル化し、そのすべてのプロトコル データはデフォルトで最初にメモリにキャッシュされます。トランザクション マジョリティはログの永続性を必要としません。 パイのほとんどがダウンし、リーダーが失敗した場合、RPO != 0 という深刻な問題が発生します。極端なシナリオを想定します。

1. MGR クラスタは 3 つのノード ABC で構成され、そのうち AB は同じ都市内の独立したコンピュータ ルーム、C は都市を越えたノードです。 A はリーダー、BC はフォロワー ノードです
2. リーダー A ノードでトランザクション 001 を開始します。リーダー A は、Paxos プロトコルを通じてトランザクション 001 のログをブロードキャストします。 セクション AB が多数派を形成し、都市間ネットワークの遅延によりノード C はトランザクション 001 のログを受信できませんでした。
3. 次の瞬間、リーダー A はトランザクション 001 を送信し、クライアント成功を返します。これは、トランザクション 001 がデータベースに送信されたことを意味します。
4. この時点では、ノード B のフォロワーでは、トランザクション 001 のログがまだ XCOM キャッシュにあり、RelayLog にフラッシュされる時間がありません。この時点では、ノード C のフォロワーはまだトランザクション 001 を受信して​​いません。ノード A のリーダーからのログ。
5. この時点で、ノード AB はダウンし、ノード A は障害が発生して長期間回復できませんが、ノード B は再起動してすぐに回復し、ノード BC は読み取りおよび書き込みサービスを提供し続けます。
6. トランザクション 001 ログはダウンタイム中にノード B の RelayLog に保存されず、ノード C によっても受信されなかったため、現時点では BC ノードは実際にはトランザクション 001 を失い、それを取得できません。
7. 多数派が敗北したこのシナリオでは、RPO!=0 になります。

コミュニティのデフォルト パラメータでは、トランザクションの大部分はログの永続性を必要とせず、RPO=0 を保証しません。これは、XCOM プロジェクトの実装におけるパフォーマンスとのトレードオフであると考えられます。絶対 RPO=0 を保証するには、読み取りおよび書き込みの一貫性を制御するパラメータ group_replication_consistency を AFTER まで設定する必要があります。ただし、この場合、トランザクションは 1.5 RTT ネットワーク オーバーヘッドに加えて、過半数に達するためにログ IO オーバーヘッドを必要とします。パフォーマンスは非常に悪くなります。

DN

PolarDB-X DN は、X-Paxos を使用して分散プロトコルを実装し、MySQL のグループ コミット プロセスに深く結合しています。トランザクションが送信されると、実際の送信が許可される前に大部分が配置と永続性を確認する必要があります。ここでのディスク配置のほとんどは、メイン ライブラリの Binlog 配置を指します。スタンバイ ライブラリの IO スレッドは、メイン ライブラリのログを受信し、それを永続化するために独自の Binlog に書き込みます。したがって、極端なシナリオですべてのノードに障害が発生した場合でも、データは失われず、RPO=0 が保証されます。

2.3. RTO

RTO 時間は、システム自体のコールド リスタートの時間オーバーヘッドと密接に関係しており、これは特定の基本機能に反映されます。障害検出メカニズム -> クラッシュ回復メカニズム -> マスター選択メカニズム -> ログ バランシング

2.3.1. 障害検出

MGR

• 各ノードは定期的に他のノードにハートビート パケットを送信し、他のノードが正常かどうかを確認します。ハートビート周期は 1 秒に固定されており、調整することはできません。
• group_replication_member_expel_timeout (デフォルトは 5 秒) が経過しても他のノードが応答していないことが現在のノードで検出された場合、そのノードは障害が発生したノードとみなされ、クラスターから追い出されます。
• ネットワークの中断や異常な再起動などの例外の場合、ネットワークが復元された後、障害が発生した 1 つのノードが自動的にクラスターに参加しようとし、ログを結合します。

DN

• リーダー ノードは、ハートビート パケットを他のノードに定期的に送信して、他のノードが正常かどうかを確認します。ハートビート期間は、選出タイムアウトの 1/5 です。選出タイムアウトはパラメータ consensus_election_timeout によって制御され、デフォルトは 5 秒であるため、リーダー ノードのハートビート期間はデフォルトで 1 秒になります。
• リーダーは、他のノードがオフラインであることを検出した場合、他のすべてのノードに定期的にハートビート パケットを送信し続け、他のノードがクラッシュして回復した後に時間内にアクセスできるようにします。ただし、リーダー ノードはオフライン ノードにトランザクション ログを送信しなくなりました。
• 非リーダー ノードはハートビート検出パケットを送信しませんが、非リーダー ノードが consensus_election_timeout 後にリーダー ノードからハートビートを受信して​​いないことが判明した場合、再選択がトリガーされます。
• ネットワークの中断や異常な再起動などの例外の場合、ネットワークが復旧した後、障害のあるノードは自動的にクラスターに参加します。
• したがって、障害検出の点で、DN はより多くの運用および保守構成インターフェイスを提供し、都市を越えた導入シナリオにおける障害の特定がより正確になります。

2.3.2. クラッシュからの回復

MGR

• • XCOM によって実装された Paxos プロトコルはメモリ状態にあり、マジョリティの達成には永続性は必要ありません。プロトコル ステータスは、生き残っているマジョリティ ノードのメモリ状態に基づいています。すべてのノードがハングアップした場合、クラスターの再起動後にプロトコルを復元することはできません。復元するには手動による介入が必要です。
  • 単一ノードのみがクラッシュして回復したが、フォロワー ノードがより多くのトランザクション ログを持つリーダー ノードよりも遅れており、リーダー上の XCOM キャッシュされたトランザクション ログがクリアされている場合、唯一の選択肢はグローバル リカバリまたはクローン プロセスを使用することです。
  • XCOM キャッシュ サイズは group_replication_message_cache_size によって制御され、デフォルトは 1GB です。
  • グローバル リカバリとは、ノードがクラスタに再参加するときに、必要な不足しているトランザクション ログ (バイナリ ログ) を他のノードから取得することによってデータをリカバリすることを意味します。このプロセスは、必要なすべてのトランザクション ログを保持するクラスター内の少なくとも 1 つのノードに依存します。
  • クローンはクローン プラグインに依存します。クローン プラグインは、データ量が大きい場合や多くのログが欠落している場合の回復に使用されます。これは、データベース全体のスナップショットをクラッシュしたノードにコピーし、その後、最新のトランザクション ログと最終同期することで機能します。
  • グローバル リカバリとクローンのプロセスは通常は自動化されていますが、ネットワークの問題や他の 2 つのノードの XCOM キャッシュがクリアされているなどの特殊な場合には、手動による介入が必要になります。

DN

• • X-Paxos プロトコルは Binlog 永続性を使用し、クラッシュから回復する場合、送信されたトランザクションが最初に完全に復元されます。保留中のトランザクションの場合、トランザクションをコミットまたはロールバックする前に、XPaxos プロトコル層がマスターとバックアップの関係を決定するための合意に達するまで待つ必要があります。 プロセス全体が完全に自動化されています。すべてのノードがダウンした場合でも、クラスターは再起動後に自動的に回復できます。
  • 多くのトランザクション ログでフォロワー ノードがリーダー ノードに遅れをとっているシナリオでは、リーダーの Binlog ファイルが削除されない限り、フォロワー ノードは確実に追いつきます。
  • したがって、クラッシュ回復に関して、DN は手動介入をまったく必要としません。

2.3.3. リーダーの選択

シングルマスター モードでは、MGR の XCOM と強力なリーダー モードである DN X-Paxos は、リーダーの選択に関して同じ基本原則に従います。つまり、クラスターによって合意されたログはロールバックできません。 しかし、合意されていないログに関しては違いがあります

MGR

• リーダーの選択は、どのノードが次にリーダー サービスとして機能するかによって決まります。このリーダーは、選出時に必ずしも最新のコンセンサス ログを持っているわけではないため、クラスター内の他のノードから最新のログを同期し、ログが結合された後に読み取りおよび書き込みサービスを提供する必要があります。
• この利点は、リーダーの選択自体が重みや順序などの戦略的な産物であることです。 MGR は、group_replication_member_weight パラメータを通じて各ノードの重みを制御します。
• 欠点は、新しく選出されたリーダー自体に大きなレプリケーション遅延が発生する可能性があり、ログに追いつき続ける必要があること、またはアプリケーションの遅延が大きくなり、読み取りと読み取りを提供できるようになる前にログ アプリケーションに追いつき続ける必要があることです。書き込みサービス。これにより RTO 時間が長くなります

DN

• リーダーの選出は、プロトコルの意味で、クラスター内のすべての多数派のログを持つノードがリーダーとして選出されるため、このノードは以前はフォロワーまたはロガーであった可能性があります。
• ロガーは、他のノードにログを同期した後、読み取りおよび書き込みサービスを提供できなくなり、リーダーの役割を積極的に放棄します。
• 指定されたノードが確実にリーダーになるように、DN は楽観的な重み付け戦略と必須の重み付け戦略を使用してリーダーになる順序を制限し、戦略的多数決メカニズムを使用して新しいマスターがすぐに読み取りと書き込みを提供できるようにします。遅延ゼロのサービス。
• したがって、リーダーの選択に関して、DN は MGR と同じ戦略的選択をサポートするだけでなく、必須のウェイト戦略もサポートします。

2.3.4. ログの照合

ログの等化とは、プライマリ データベースとセカンダリ データベース間のログにログ レプリケーションの遅延があり、セカンダリ データベースでログを等化する必要があることを意味します。再起動および復元されるノードの場合、通常、スタンバイ データベースからリカバリが開始されますが、メイン データベースと比較してログ レプリケーションの遅延がすでに発生しているため、ログをメイン データベースに追いつく必要があります。リーダーから物理的に遠く離れたノードの場合、通常、過半数に到達することは関係ありません。常にレプリケーション ログの遅延があり、常にログに追いついています。このような状況では、ログ レプリケーションの遅延をタイムリーに解決するには、特別なエンジニアリングの実装が必要です。

MGR

• トランザクション ログはすべて XCOM キャッシュ内にあり、デフォルトではキャッシュは 1G しかありません。そのため、レプリケーションが大幅に遅れているフォロワー ノードがログを要求すると、キャッシュが簡単にクリアされます。
• このとき、遅れているフォロワーは自動的にクラスターから追い出され、前述のグローバル リカバリまたはクローン プロセスを使用してクラッシュ回復を行い、追いついた後に自動的にクラスターに参加します。遭遇したらたとえば、ネットワークの問題、または他の 2 つのノードの XCOM キャッシュがクリアされた場合、問題を解決するには手動介入が必要になります。
• なぜ最初にクラスターを追い出す必要があるのでしょうか? マルチライト モードで障害のあるノードはパフォーマンスに大きく影響し、リーダーのキャッシュは非同期結合の後に追加する必要があるためです。
• リーダーのローカル Binlog ファイルを直接読み取ることができないのはなぜですか? 前述の XCOM プロトコルがメモリ内にいっぱいになっていて、Binlog と Relay Log に XCOM に関するプロトコル情報が存在しないためです。

DN

• データはすべて Binlog ファイル内にあり、Binlog がクリーンアップされない限り、オンデマンドで送信でき、クラスターから追い出される可能性はありません。
• メイン ライブラリが Binlog ファイルから古いトランザクション ログを読み取ることによって発生する IO ジッターを軽減するために、DN は FIFO キャッシュから最近キャッシュされたトランザクション ログを読み取ることを優先します。FIFO キャッシュはパラメーター consensus_log_cache_size とデフォルトによって制御されます。 64Mです
• FIFO キャッシュ内の古いトランザクション ログが更新されたトランザクション ログによって削除された場合、DN は以前にキャッシュされたトランザクション ログをプリフェッチ キャッシュから読み取ろうとします。プリフェッチ キャッシュはパラメータ consensus_prefetch_cache_size によって制御され、デフォルトは 64M です。
• プリフェッチ キャッシュに必要な古いトランザクション ログがない場合、DN は非同期 IO タスクの開始を試行し、指定されたトランザクション ログの前後のいくつかの連続したログを Binlog ファイルからバッチで読み取り、プリフェッチ キャッシュに配置して待機します。 DN の次の再試行読み取り用に。
• したがって、DN では、ログのバランスをとる際に手動による介入はまったく必要ありません。

2.4. スタンバイデータベースの再生遅延

スタンバイ・データベースの再生遅延は、同じトランザクションがメイン・データベースで完了した時点と、トランザクションがスタンバイ・データベースに適用された時点との間の遅延です。ここでテストされるのは、スタンバイ・データベースの適用アプリケーション・ログのパフォーマンスです。これは、例外が発生したときにスタンバイ データベースがデータ アプリケーションを完了し、読み取りおよび書き込みサービスを提供するまでにかかる時間に影響します。

MGR

• MGR スタンバイ データベースは、アプリケーションを適用するときに、RelayLog ファイルを再度読み取り、完全な 2 段階のグループ送信プロセスを経て、対応するデータと Binlog ファイルを生成する必要があります。
• ここでのトランザクション アプリケーションの効率は、メイン データベースのトランザクション送信効率と同じです。デフォルトの double-one 構成 (innodb_flush_log_at_trx_commit、sync_binlog) では、スタンバイ データベース アプリケーションの同じリソース オーバーヘッドが大きくなります。

DN

• DN バックアップ データベースは、適用時に Binlog ファイルを再度読み取り、1 段階のグループ送信プロセスを実行して、対応するデータを生成するだけで済みます。
• DN は完全なクラッシュ リカバリをサポートしているため、スタンバイ データベース アプリケーションは innodb_flush_log_at_trx_commit=1 を有効にする必要がなく、実際には double-one 構成の影響を受けません。
• したがって、スタンバイ データベースの再生遅延という点では、DN スタンバイ データベースの再生効率は MGR よりもはるかに高くなります。

2.5. 主要なイベントの影響

大規模なトランザクションは、通常のトランザクションの送信に影響を与えるだけでなく、分散システム内の分散プロトコル全体の安定性に影響を与えます。深刻な場合、大規模なトランザクションにより、クラスター全体が長時間使用できなくなります。

MGR

• MGR には、大規模なトランザクションをサポートするための最適化はありません。大規模なトランザクションの上限を制御するためのパラメータ group_replication_transaction_size_limit が追加されるだけです。デフォルトは 143M で、最大値は 2GB です。
• トランザクション ログが大規模トランザクション制限を超えると、エラーが直接報告され、トランザクションは送信できません。

DN

• 大規模なトランザクションによって引き起こされる分散システムの不安定性の問題を解決するために、DN は大規模なトランザクションのトランザクション ログを論理的 + 物理的に分割するソリューションを採用しています。小さなブロック。トランザクション ログの各小さなブロックは完全な Paxos コミット保証を使用します。
• 大規模なトランザクションを分割するソリューションに基づいて、DN は大規模なトランザクションのサイズに制限を課さず、ユーザーはそれらを自由に使用でき、RPO=0 を保証することもできます。
• 詳細な手順については、を参照してください。「PolarDB-X ストレージ エンジン コア テクノロジー | 大規模トランザクションの最適化」
• したがって、DNは大規模な業務に影響されることなく、大規模な業務を処理することができます。

2.6. 導入形態

MGR

• MGR は、シングルマスター展開モードとマルチマスター展開モードをサポートします。マルチマスター モードでは、各ノードは読み取りと書き込みが可能で、メイン データベースは読み取りと書き込みのみが可能です。のみ。
• MGR 高可用性展開には、少なくとも 3 つのノード展開が必要です。つまり、少なくとも 3 つのデータとログのコピーが必要です。ログ コピー ロガー モードはサポートされていません。
• MGR は読み取り専用ノードの拡張をサポートしませんが、MGR + マスター/スレーブ レプリケーション モードの組み合わせをサポートして、同様のトポロジ拡張を実現します。

DN

• DN は、シングルマスター モードの展開をサポートします。シングルマスター モードでは、メイン データベースは読み取りと書き込みが可能ですが、スタンバイ データベースは読み取り専用になります。
• DN 高可用性展開には少なくとも 3 つのノードが必要ですが、ロガー形式のログ コピーをサポートします。つまり、リーダーとフォロワーはロガーと比較すると、ログのみが存在し、データを持たず、存在する権利がありません。選ばれた。 この場合、3 ノードの高可用性展開では、データのコピー 2 つとログのコピー 3 つ分のストレージ オーバーヘッドのみが必要となり、低コストの展開となります。
• DN は、読み取り専用ノードの展開と読み取り専用コピーの学習者フォームをサポートしています。フル機能のコピーと比較して、学習者コピーでは、ダウンストリームのサブスクリプションとメイン ライブラリの利用が可能になるだけです。

2.7. 機能の概要

3. テストの比較

MGR は MySQL 5.7.17 で導入されましたが、その他の MGR 関連機能は MySQL 8.0 でのみ利用可能であり、MySQL 8.0.22 以降のバージョンでは全体的なパフォーマンスがより安定し、信頼性が高くなります。したがって、比較テストには、両者の最新バージョン 8.0.32 を選択しました。

PolarDB-X DN と MySQL MGR の比較テストでは、テスト環境、コンパイル方法、展開方法、操作パラメータ、およびテスト方法に違いがあり、それが不正確なテスト比較データにつながる可能性があることを考慮して、この記事ではさまざまな詳細に焦点を当てます。次のように進めます。

注記：

• MGR ではフロー制御がデフォルトで有効になっていますが、PolarDB-X DN ではフロー制御がデフォルトでオフになっています。したがって、MGR のパフォーマンスが最高になるように、MGR の group_replication_flow_control_mode が個別に設定されます。
• MGR には列挙中に明らかな読み取りボトルネックがあるため、MGR の読み取り専用パフォーマンスが最高になるように、MGR の replication_optimize_for_static_plugin_config が個別に構成されて有効になります。

3.1. パフォーマンス

データベースを選択するときに誰もが最初に注目するのはパフォーマンス テストです。ここでは、公式の sysbench ツールを使用して、それぞれ 1,000 万のデータを含む 16 のテーブルを構築し、OLTP シナリオでパフォーマンス テストを実行し、異なる OLTP シナリオの異なる同時実行条件下で 2 つのパフォーマンスをテストして比較します。実際の展開のさまざまな状況を考慮して、次の 4 つの展開シナリオをそれぞれシミュレートします。

1. 3 つのノードが同じコンピュータ ルームに展開されており、マシンが相互に ping を実行すると、0.1 ミリ秒のネットワーク遅延が発生します。
2. 同じ都市の 3 つのセンターと同じ地域の 3 つのコンピューター ルームに 3 つのノードが展開されている場合、コンピューター ルーム間の ping に 1 ミリ秒のネットワーク遅延が発生します (例: 上海の 3 つのコンピューター ルーム)。
3. 2 か所の 3 つのセンター、2 か所の 3 つのコンピュータ ルームに 3 つのノードが展開、同じ都市のコンピュータ ルーム間のネットワーク ping は 1 ミリ秒、同じ都市と別の場所の間のネットワーク遅延は 30 ミリ秒 (例: 上海/上海/深セン)
4. 3 か所に 3 つのセンター、3 か所の 3 つのコンピュータ ルームに 3 つのノードが展開されています (例: 上海/杭州/深セン)。杭州と上海の間のネットワーク遅延は約 5 ミリ秒、杭州/上海から深センまでの最遠距離は 30 ミリ秒です。 。

例証します:

a. 4 つの展開シナリオのパフォーマンスを水平に比較してみます。2 か所の 3 センターと 3 か所の 3 つのセンターはすべて 3 コピーの展開モードを採用しており、実際の運用ビジネスは 5 コピーの展開モードに拡張できます。

b. 高可用性データベース製品を使用する場合の RPO=0 に対する厳しい制限を考慮して、MGR はデフォルトで RPO<>0 で構成されます。ここでは、それぞれの MGR RPO<>0 と RPO=0 の間の比較テストを追加していきます。導入シナリオ。

• MGR_0 は、MGR RPO = 0 の場合のデータを表します。
• MGR_1 は、MGR RPO <> 0 の場合のデータを表します。
• DN は、DN RPO = 0 の場合のデータを表します。

3.1.1. 同じコンピュータ室

それはテスト結果からわかります。

• 読み取り専用シナリオでは、MGR_1 (RPO<>0) と MGR_0 (RPO=0) のどちらを比較しても、DN と MGR の差は -5% から 10% の間で安定しており、基本的に同じであると考えることができます。 RPO が 0 に等しいかどうかは、読み取り専用トランザクションには影響しません。
• 読み取り/書き込みと書き込み専用の混合トランザクション シナリオでは、DN (RPO=0) のパフォーマンスは MGR_1 (RPO<>0) と比較して 5% ～ 47% 向上しており、DN のパフォーマンス上の利点は明らかです。同時実行性が低い場合、同時実行性が高い場合の利点は明らかではありません。 これは、同時実行性が低い場合は DN のプロトコル効率が高くなりますが、同時実行性が高い場合の DN と MGR のパフォーマンス ホットスポットはすべてクリーニング中であるためです。
• RPO=0 という同じ前提の下で、読み取り/書き込みと書き込み専用の混合トランザクション シナリオでは、DN のパフォーマンスは MGR_0 と比較して 2 倍から 46 倍向上し、同時実行性が増加するにつれて、DN のパフォーマンス上の利点が強化されます。 MGR がデフォルトでパフォーマンスのために RPO=0 を放棄するのも不思議ではありません。

3.1.2. 同じ都市にある 3 つのセンター

それはテスト結果からわかります。

• 読み取り専用シナリオでは、MGR_1 (RPO<>0) と MGR_0 (RPO=0) のどちらを比較しても、DN と MGR の差は -7% から 5% の間で安定しており、基本的に同じであると考えることができます。 RPO が 0 に等しいかどうかは、読み取り専用トランザクションには影響しません。
• 読み取り/書き込みトランザクションと書き込み専用トランザクションが混在するシナリオでは、DN (RPO=0) のパフォーマンスは MGR_1 (RPO<>0) と比較して 30% ～ 120% 向上し、同時実行時の DN のパフォーマンス上の利点は明らかです。は低く、同時実行性が高いとパフォーマンスが向上します。 目に見えない機能。 これは、同時実行性が低い場合は DN のプロトコル効率が高くなりますが、同時実行性が高い場合の DN と MGR のパフォーマンス ホットスポットはすべてクリーニング中であるためです。
• RPO=0 という同じ前提の下で、読み取り/書き込みと書き込み専用の混合トランザクション シナリオでは、DN のパフォーマンスは MGR_0 と比較して 1 ～ 14 倍向上し、同時実行性が増加するにつれて、DN のパフォーマンス上の利点が強化されます。 MGR がデフォルトでパフォーマンスのために RPO=0 を放棄するのも不思議ではありません。

3.1.3. 2 つの場所と 3 つのセンター

それはテスト結果からわかります。

• 読み取り専用シナリオでは、MGR_1 (RPO<>0) と MGR_0 (RPO=0) のどちらを比較しても、DN と MGR の差は -4% から 7% の間で安定しており、基本的に同じであると考えられます。 RPO が 0 に等しいかどうかは、読み取り専用トランザクションには影響しません。
• 読み取り/書き込みと書き込み専用の混合トランザクション シナリオでは、DN (RPO=0) のパフォーマンスは、MGR_1 (RPO<>0) と比較して 2 ～ 16 倍向上しており、同時実行性が高い場合、DN のパフォーマンス上の利点は明らかです。は低く、同時実行性が高い場合の利点は明らかではない機能です。 これは、同時実行性が低い場合は DN のプロトコル効率が高くなりますが、同時実行性が高い場合の DN と MGR のパフォーマンス ホットスポットはすべてクリーニング中であるためです。
• RPO=0 という同じ前提の下で、読み取り/書き込みと書き込み専用の混合トランザクション シナリオでは、DN のパフォーマンスは MGR_0 と比較して 8 倍から 29 倍向上し、同時実行性が増加するにつれて、DN のパフォーマンス上の利点が強化されます。 MGR がデフォルトでパフォーマンスのために RPO=0 を放棄するのも不思議ではありません。

3.1.4. 3 つの場所と 3 つのセンター

それはテスト結果からわかります。

• 読み取り専用シナリオでは、MGR_1 (RPO<>0) と MGR_0 (RPO=0) のどちらを比較しても、DN と MGR の差は -5% から 0% の間で安定しており、基本的に同じであると考えられます。 RPO が 0 に等しいかどうかは、読み取り専用トランザクションには影響しません。
• 読み取り/書き込みと書き込み専用の混合トランザクション シナリオでは、DN (RPO=0) のパフォーマンスは、MGR_1 (RPO<>0) と比較して 2 倍から 5 倍向上しており、同時実行時の DN のパフォーマンス上の利点は明らかです。は低く、同時実行性が高い場合の利点は明らかではない機能です。 これは、同時実行性が低い場合は DN のプロトコル効率が高くなりますが、同時実行性が高い場合の DN と MGR のパフォーマンス ホットスポットはすべてクリーニング中であるためです。
• RPO=0 という同じ前提の下で、読み取り/書き込みと書き込み専用の混合トランザクション シナリオでは、DN のパフォーマンスは MGR_0 と比較して 2 倍から 17 倍向上し、同時実行性が増加するにつれて、DN のパフォーマンス上の利点が強化されます。 MGR がデフォルトでパフォーマンスのために RPO=0 を放棄するのも不思議ではありません。

3.1.5. 導入の比較

さまざまな導入方法でのパフォーマンスの変化を明確に比較するために、上記のテストでは、oltp_write_only シナリオ 256 同時実行でのさまざまな導入方法での MGR と DN の TPS データを選択し、ベースラインとしてコンピューター ルームのテスト データを使用して計算しました。異なる導入方法の TPS データをベースラインと比較して、都市間導入時のパフォーマンス変化の違いを認識します。

それはテスト結果からわかります。

• 導入方法の拡大により、MGR_1 (RPO<>0) の TPS は、同じコンピュータ ルーム内での導入と比較して大幅に低下し、同じ都市内でのコンピュータ ルーム間導入のパフォーマンスは 27.5% 低下しました。都市間（2 か所に 3 センター、3 か所に 3 センター）展開の割合 77% ～ 82% 減少。これは、RT の都市間展開の増加によるものです。
• DN (RTO=0) は、同じコンピュータ ルームでの展開と比較して、同じ都市内での複数のコンピュータ ルームの展開および 2 か所の 3 つのセンターの展開のパフォーマンスが 4% から 12% 低下しました。 3 か所に 3 つのセンターを展開すると、ネットワーク遅延が大きくなり、パフォーマンスが 37% 低下しました。これは、都市全体での RT の展開が増加したことも原因です。ただし、DN の Batch&Pipeline メカニズムのおかげで、都市間の影響は同時実行数を増やすことで解決できます。たとえば、3 か所および 3 センターのアーキテクチャでは、同時実行数が 512 以上の場合、同じ都市および 2 つの都市でのパフォーマンス スループットが向上します。基本的には3つの位置と3つの中心を揃えることができます。
• 都市間展開が MGR_1 (RPO<>0) に大きな影響を与えていることがわかります。

3.1.6. パフォーマンスのジッター

実際の使用では、パフォーマンスデータに注意を払うだけでなく、パフォーマンスジッターにも注意する必要があります。結局のところ、ジッターがジェット コースターのような場合、実際のユーザー エクスペリエンスは非常に悪くなります。 TPS リアルタイム出力データを監視および表示します。sysbenc ツール自体がパフォーマンス ジッターの出力監視データをサポートしていないことを考慮して、比較指標として数学的な変動係数を使用します。

• 変動係数 (CV): 変動係数は、標準偏差を平均で割ったもので、特に平均の差が大きい場合に、異なるデータセットの変動を比較するためによく使用されます。 CV が大きいほど、平均に対するデータの変動が大きくなります。

256 の同時 oltp_read_write シナリオを例として、同じコンピュータ ルーム、同じ都市の 3 つのセンター、2 か所の 3 つのセンターにある MGR_1 (RPO<>0) と DN (RPO=0) の TPS を統計的に分析します。 3 つのセンターに 3 つのジッター状況。 実際のジッター グラフは次のとおりです。各シナリオの実際のジッター インジケーター データは次のとおりです。

それはテスト結果からわかります。

• MGR の TPS は、oltp_read_write シナリオで不安定な状態になり、理由もなく突然急激に低下します。この現象は、複数の展開シナリオでの複数のテストで確認されています。 それに比べて、DN は非常に安定しています。
• 変動係数 CV を計算すると、MGR の CV は 6% ～ 10% と非常に大きく、同じコンピュータ ルーム内の遅延が最小の場合には最大値の 10% に達することもありますが、DN の CV は 2% ～ 4% と比較的安定しています。 % であり、DN のパフォーマンスは MGR よりも基本的に 2 倍高くなります。
• MGR_1 (RPO<>0) のパフォーマンス ジッターが比較的大きいことがわかります。

3.2. RTO

分散データベースの中核となる機能は、高可用性です。クラスター内のどのノードに障害が発生しても、全体の可用性には影響しません。同じコンピュータ ルームに 1 つのマスターと 2 つのバックアップを備えた 3 ノードの典型的な導入形態について、次の 3 つのシナリオでユーザビリティ テストを実施しようとしました。

• メイン データベースを中断して再起動し、プロセス中にクラスターが可用性を回復するまでの RTO 時間を観察します。
• スタンバイ データベースを中断して再起動し、プロセス中のプライマリ データベースの可用性パフォーマンスを観察します。

3.2.1. メインデータベースのダウンタイムと再起動

負荷がない場合は、リーダーを強制終了し、クラスター内の各ノードのステータスの変化と書き込み可能かどうかを監視します。

テスト結果から、無圧力条件下では次のことがわかります。

• DN の RTO は 8 ～ 15 秒で、2 ノードに減らすのに 8 秒、3 ノードを復元するのに 15 秒かかります。
• MGR の RTO は 23 ～ 37 秒です。2 つのノードにダウングレードするのに 23 秒、3 つのノードを復元するのに 37 秒かかります。
• RTO パフォーマンス DN は全体的に MGR よりも優れています

3.2.2. スタンバイデータベースのダウンタイムと再起動

sysbench を使用して、oltp_read_write シナリオで 16 スレッドの同時ストレス テストを実行します。図の 10 秒目で、スタンバイ ノードを手動で強制終了し、sysbench のリアルタイム出力 TPS データを観察します。

それはテスト結果のグラフからわかります。

• スタンバイ データベースが中断された後、MGR のメイン データベースの TPS は大幅に低下し、通常のレベルに戻るまで約 20 秒かかりました。ログ分析によると、ここには 2 つのプロセスがあります。障害のあるノードが到達不能になったことを検出し、障害のあるノードを MGR クラスターから追い出すことです。このテストでは、MGR コミュニティで長い間広まっていた欠陥が確認されました。たとえ 3 つのノードのうち 1 つのノードだけが利用できなくなったとしてもです。クラスター全体で一定期間深刻なジッターが発生し、使用できなくなりました。
• シングルマスター MGR で単一ノード障害が発生し、インスタンス全体が使用できなくなる問題を解決するために、コミュニティは 8.0.27 で MGR paxos シングル リーダー機能を導入して問題を解決しましたが、この機能はデフォルトでオフになっています。 ここでは、group_replication_paxos_single_leader をオンにして検証を続けます。今回はスタンバイ データベースを中断した後、メイン データベースのパフォーマンスは安定しており、ネットワーク負荷の軽減に関連していると考えられます。
• DN の場合、スタンバイ データベースが中断された後、メイン データベースの TPS はすぐに約 20% 増加し、その後は安定し、クラスターは常に利用可能でした。これは MGR の逆です。その理由は、スタンバイ データベースを中断した後、メイン データベースは毎回、残りのスタンバイ データベースにログを送信するだけで済むため、ネットワーク パケットの送受信プロセスが効率的になるためです。

テストを継続して、スタンバイ データベースを再起動して復元し、メイン データベースの TPS データの変化を観察します。

それはテスト結果のグラフからわかります。

• MGR は 5 秒で 2 ノードから 3 ノードに回復しました。ただし、メイン ライブラリが利用できない状況も発生しており、これは約 12 秒続きます。スタンバイ ノードが最終的にクラスターに参加しましたが、MEMBER_STATE ステータスは常に RECOVERING であり、現時点でデータが追跡されていることを示します。
• group_replication_paxos_single_leader を有効にした後のシナリオでは、スタンバイ データベースの再起動も検証され、その結果、MGR は 10 秒で 2 ノードから 3 ノードに回復します。しかし、それでも約 7 秒間利用できない時間が続きました。このパラメータでは、単一ノードで障害が発生し、インスタンス全体が使用できなくなるシングルマスター MGR の問題を完全には解決できないようです。
• DN の場合、スタンバイ データベースは 10 秒以内に 2 ノードから 3 ノードに回復し、メイン データベースは引き続き使用可能です。 ここでは、スタンバイ データベースの再起動によるログ レプリケーションの遅延が原因で、TPS に短期的な変動が発生します。そのため、メイン データベースにはわずかな影響が生じます。ログを確認すると、全体的なパフォーマンスが安定した状態になります。

3.3. RPO

MGR 過半数障害 RPO<>0 シナリオを構築するために、コミュニティ独自の MTR ケース メソッドを使用して、MGR で障害挿入テストを実行します。設計されたケースは次のとおりです。

--echo
--echo ############################################################
--echo # 1. Deploy a 3 members group in single primary mode.
--source include/have_debug.inc
--source include/have_group_replication_plugin.inc
--let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
--let $rpl_group_replication_single_primary_mode=1
--let $rpl_skip_group_replication_start= 1
--let $rpl_server_count= 3
--source include/group_replication.inc
 
--let $rpl_connection_name= server1
--source include/rpl_connection.inc
--let $server1_uuid= `SELECT @@server_uuid`
--source include/start_and_bootstrap_group_replication.inc
 
--let $rpl_connection_name= server2
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--echo
--echo ############################################################
--echo # 2. Init data
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
 
--source include/rpl_sync.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--echo
--echo ############################################################
--echo # 3. Mock crash majority members
 
--echo # server 2 wait before write relay log
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
--echo # server 3 wait before write relay log
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
 
--echo # server 1 commit new transaction
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
INSERT INTO t1 VALUES(2);
# server 1 commit t1(c1=2) record
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 1 crash
--source include/kill_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 3 check
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo
--echo ############################################################
--echo # 4. Check alive members, lost t1(c1=2) record
 
--echo # server 3 check
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 lost t1(c1=2) record
SELECT * FROM t1;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 lost t1(c1=2) record
SELECT * FROM t1;

!include ../my.cnf
 
[mysqld.1]
loose-group_replication_member_weight=100
 
[mysqld.2]
loose-group_replication_member_weight=90
 
[mysqld.3]
loose-group_replication_member_weight=80
 
[ENV]
SERVER_MYPORT_3=		@mysqld.3.port
SERVER_MYSOCK_3=		@mysqld.3.socket

ケースの実行結果は次のとおりです。

 
############################################################
# 1. Deploy a 3 members group in single primary mode.
include/group_replication.inc [rpl_server_count=3]
Warnings:
Note	####	Sending passwords in plain text without SSL/TLS is extremely insecure.
Note	####	Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[connection server1]
[connection server1]
include/start_and_bootstrap_group_replication.inc
[connection server2]
include/start_group_replication.inc
[connection server3]
include/start_group_replication.inc
 
############################################################
# 2. Init data
[connection server1]
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
include/rpl_sync.inc
SELECT * FROM t1;
c1
1
[connection server2]
SELECT * FROM t1;
c1
1
[connection server3]
SELECT * FROM t1;
c1
1
 
############################################################
# 3. Mock crash majority members
# server 2 wait before write relay log
[connection server2]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 3 wait before write relay log
[connection server3]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 1 commit new transaction
[connection server1]
INSERT INTO t1 VALUES(2);
SELECT * FROM t1;
c1
1
2
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13000	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13002	ONLINE	SECONDARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 1 crash
# Kill the server
# sleep enough time for electing new leader
 
# server 3 check
[connection server3]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 3 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
# server 2 check
[connection server2]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	UNREACHABLE	SECONDARY	8.0.32	XCom
# server 2 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
############################################################
# 4. Check alive members, lost t1(c1=2) record
# server 3 check
[connection server3]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 3 lost t1(c1=2) record
SELECT * FROM t1;
c1
1
 
# server 2 check
[connection server2]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 2 lost t1(c1=2) record
SELECT * FROM t1;
c1
1

欠損番号を再現する場合のおおよそのロジックは次のとおりです。

1. MGR は、シングルマスター モードの 3 つのノード (サーバー 1/2/3) で構成されます。サーバー 1 はメイン データベースであり、1 つのレコード c1=1 を初期化します。
2. リレー ログの書き込み時にフォールト インジェクション サーバー 2/3 がハングする
3. サーバー 1 ノードに接続し、c1=2 のレコードを書き込み、トランザクションのコミットも成功を返しました。
4. その後、Mock サーバー 1 が異常終了します (マシン障害、復旧不可、アクセス不能)。この時点では、サーバー 2/3 が過半数を形成します。
5. サーバー 2/3 を通常どおり再起動します (迅速な回復) が、サーバー 2/3 はクラスターを使用可能な状態に復元できません。
6. サーバー 2/3 ノードに接続し、データベース レコードをクエリすると、c1=1 のレコードのみが表示されます (サーバー 2/3 は c1=2 を失いました)。

上記のケースによると、MGR の場合、サーバーの大部分がダウンしてメイン データベースが使用できなくなり、スタンバイ データベースが復元された後、RPO<>0 のデータ損失が発生し、成功したコミットのレコードは次のようになります。元々クライアントに返却されたものは紛失しています。

DN の場合、マジョリティを達成するにはマジョリティでログが保持される必要があるため、上記のシナリオでもデータは失われず、RPO=0 が保証されます。

3.4. スタンバイデータベースの再生遅延

MySQL の従来のアクティブ/スタンバイ モードでは、通常、スタンバイ データベースには IO スレッドと適用スレッドが含まれます。Paxos プロトコルの導入後、IO スレッドは主にスタンバイ データベースのレプリケーション遅延を同期します。スタンバイ データベースの再生の適用のオーバーヘッドに依存します。ここではスタンバイ データベースの再生遅延になります。

sysbench を使用して oltp_write_only シナリオをテストし、同時実行数 100 およびさまざまなイベント数でのスタンバイ データベース再生の遅延時間をテストします。スタンバイ データベースの再生遅延時間は、performance_schema.replication_applier_status_by_worker テーブルの APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 列を監視して各ワーカーがリアルタイムで動作しているかどうかを確認し、レプリケーションが終了したかどうかを判断することで判断できます。
 

それはテスト結果のグラフからわかります。

• 同じ量の書き込みデータの場合、DN のスタンバイ データベースのすべてのログの再生完了時間は、MGR の所要時間よりもはるかに優れており、MGR のわずか 3% ～ 4% です。 これは、アクティブ/スタンバイ切り替えの適時性にとって重要です。
• 書き込み数が増加しても、MGR に対する DN のスタンバイ データベース再生遅延の利点は維持され続け、非常に安定しています。
• スタンバイ データベースの再生遅延の理由を分析すると、MGR のスタンバイ データベースの再生戦略では、デフォルト値 EVENTUAL を使用した group_replication_consistency が採用されています。つまり、RO および RW トランザクションは、実行前に前のトランザクションの適用を待機しません。これにより、メイン データベースの書き込みパフォーマンスを最大限に確保できますが、スタンバイ データベースの遅延が比較的大きくなります (メイン データベースの書き込みパフォーマンスの向上と引き換えにスタンバイ データベースの遅延と RPO=0 を犠牲にし、電流制限機能をオンにすることにより) MGR のパフォーマンスのバランスをとることができ、スタンバイ データベースは遅延しますが、メイン データベースのパフォーマンスは損なわれます)

3.5. テストの概要

4. まとめ

綿密な技術分析とパフォーマンス比較を経て、ポーラーDB-X DN は、自社開発の X-Paxos プロトコルと一連の最適化された設計により、パフォーマンス、正確性、可用性、リソース オーバーヘッドの点で MySQL MGR に比べて多くの利点を示しています。ただし、MGR は MySQL エコシステムでも重要な位置を占めています。 、スタンバイ データベースの停止のジッター、マシン ルーム間の災害復旧パフォーマンスの変動、安定性などのさまざまな状況を考慮する必要があるため、MGR を有効に活用したい場合は、専門の技術チームと運用保守チームを備えている必要があります。サポート。

大規模、高同時実行性、高可用性の要件に直面した場合、PolarDB-X ストレージ エンジンは、すぐに使用できるシナリオで MGR と比較して、独自の技術的利点と優れたパフォーマンスを備えています。ポーラーDB-XDN ベースの集中型 (標準バージョン) は、機能とパフォーマンスのバランスが良く、競争力の高いデータベース ソリューションです。