明らかにした！ Alibaba リアルタイム データ ウェアハウス分散トランザクション スケールアウト設計

[[396205]]

1. はじめに

ハイブリッド トランザクション分析処理 (HTAP) は、2014 年に有名な情報技術コンサルティングおよび分析会社である Gartner によって提案された新しいデータベース システムの定義です。具体的には、OLTP 機能 (トランザクション機能) と OLAP 機能 (分析機能) の両方を備えたデータベース システムのタイプを指します。従来のシナリオでは、OLTP タスクと OLAP タスクを実行するデータベースは 2 つの異なるシステムです。代表的な OLTP システムには、MySQL、PostgreSQL、PolarDB などがあり、代表的な OLAP システムには、Clickhouse、AnalyticDB などがあります。実稼働システムでは、元のビジネス データは通常、OLTP システムに保存され、その後、オフライン インポート、ETL、DTS などを通じて一定の遅延で OLAP システムに同期され、その後のデータ分析が実行されます。

HTAP システムの直感的な利点は、OLTP タスクと OLAP タスクを 1 つのシステムで完了できるため、ユーザーのシステム使用コストを節約できることです。さらに、HTAP システムには完全な ACID 機能があり、開発者はリアルタイム挿入、オフライン インポート、単一データ更新など、より多くのデータ書き込み方法を利用でき、簡単に処理できます。さらに、完全な HTAP 製品も優れた ETL ツールです。開発者は、HTAP システムを使用して一般的なデータ処理ニーズに対応できます。 HTAP システムは、ユーザーの使用コストと開発コストを大幅に節約し、上位のビジネス システムの形に影響を与えます。現在、ストレージとコンピューティングの分離、クラウド ネイティブ テクノロジー、HTAP などのテクノロジーは、データベース システムの重要な進化の方向性として業界で認識されています。

AnalyticDB for PostgreSQLは、Alibaba Cloud（以下、ADB PG）のリアルタイムデータウェアハウス製品です。 ADB PG は MPP 水平拡張アーキテクチャを採用し、標準 SQL 2003 をサポートし、PostgreSQL/Greenplum と互換性があり、Oracle 構文エコシステムとの互換性が高く、HTAP 製品でもあります。 ADB PG は、中国情報通信科学院が主催する分散分析データベースおよび分散トランザクションデータベースの機能と性能の認証に合格しました。これは、両方の認証に合格した中国で唯一のデータベース製品です。 ADB PG の初期バージョンは OLAP シナリオに重点を置いており、OLTP 機能を備えていました。 HTAP の普及に伴い、ADB PG はバージョン 6.0 以降、多くの面で OLTP パフォーマンスを大幅に最適化しました。最も重要なプロジェクトの 1 つは、マルチマスター プロジェクトです。スケールアウトにより、単一のマスターノードのみをサポートする元のアーキテクチャによって引き起こされるパフォーマンスのボトルネックの問題が解決され、OLTP トランザクション パフォーマンスのスケールアウトが可能になり、ユーザーのリアルタイム データ ウェアハウスと HTAP のニーズをより適切に満たすことができます。

マルチマスター プロジェクトは 2019 年に開始されて以来、1 回の書き込みと複数の読み取り、および複数の書き込みと複数の読み取りという 2 つの進化段階を経てきました。 ADB PG システムの高同時実行性とリアルタイムの書き込み/更新/クエリ機能が大幅に向上し、Alibaba 内のデータバンクなどの複数のコアビジネスをサポートしました。また、2020年のアリババのダブル11とダブル12のプロモーションのテストにも耐えました。現在、製品の安定性と性能は広く検証されています。この記事の次の部分では、まず ADB PG のオリジナルのシングルマスター アーキテクチャによって発生するパフォーマンスのボトルネックとその原因を紹介し、次にマルチマスターの設計思想を紹介します。次に、マルチマスターアーキテクチャの詳細な設計について詳しく紹介します。次に、マルチマスター プロジェクトで解決したいくつかの重要な技術的問題とコア ソリューションを紹介します。最後に、マルチマスター アーキテクチャのパフォーマンスをテストします。

2. シングルマスターアーキテクチャとマルチマスターアーキテクチャ

データ ウェアハウス システム設計では、システム内のノードは通常、マスター ノードとセグメント ノード (コンピューティング ノード) に分割されます。マスターノードとコンピューティングノードは、異なるタイプのタスクを実行します。 ADB PG を例にとると、マスター ノードは主に、ユーザー要求の受信、クエリの最適化、タスクの分散、メタデータ管理、トランザクション管理を担当します。セグメント ノードは、コンピューティング タスクとストレージ管理タスクを担当します。クエリ要求の場合、マスター ノードはユーザーが送信した SQL を解析して最適化し、最適化された実行プランをコンピューティング ノードに配布する必要があります。コンピューティング ノードは、ローカルに保存されたデータを読み取り、計算やデータ シャッフルなどのタスクを完了する必要があります。最後に、コンピューティング ノードは計算結果をマスター ノードに返して集計します。テーブルの作成や書き込みなどのリクエストの場合、マスターノードはメタデータやトランザクションなどを管理し、コンピューティングノード間の作業を調整する必要があります。

上図に示すように、ADB PG は Greenplum から進化しました。初期の ADB PG バージョンは、Greenplum と同様に、単一マスター アーキテクチャを採用していました。つまり、データベース インスタンスではメイン マスターが 1 つだけ動作し、1 つ以上のスタンバイ マスター ノードが高可用性バックアップとして構成されます。メイン マスター ノードがダウンした場合にのみ、スタンバイ マスターに切り替わり、動作します。ビジネスの発展、特にリアルタイム データ ウェアハウスと HTAP シナリオの需要の増加に伴い、シングル マスターのシステム ボトルネックの問題が徐々に浮上してきました。クエリ リンクの場合、一部のクエリの最後の段階ではマスター ノードでの最終データ処理が必要となり、一定の CPU/メモリ リソースが消費されます。書き込みシナリオでは、多数のリアルタイムの挿入/更新/削除に高いパフォーマンス保証が必要です。さらに、シングル マスター アーキテクチャが非常に多数の同時接続をどのように処理するかも問題です。上記の問題は、マスターノードの構成を改善（スケールアップ）することで軽減できますが、根本的な解決にはなりません。

ADB PG は、ノードをスケールアウトすることでマスター層のリソースボトルネックの問題を解決し、リアルタイム データ ウェアハウスや HTAP などのビジネス シナリオのニーズをより適切に満たすことを目標に、2019 年にマルチマスター プロジェクトを開始しました。上図は、元のスタンバイ マスターを保持しながら、複数のセカンダリ マスター ノードを追加することでパフォーマンスのスケールアウトを実現し、高可用性を確保するマルチ マスター アーキテクチャの概略図です。 ADB PG のトランザクション機能を保証するために、マルチマスター プロジェクトでは、トランザクションをサポートしていない他のリアルタイム データ ウェアハウスでは発生しないいくつかの困難を克服する必要があります。一方、ADB PG は、複数のマスターを持つシナリオをサポートするために、分散トランザクション機能を拡張する必要があります。一方、ADB PG では、グローバル デッドロック処理、DDL サポート、分散テーブル ロック サポートのアルゴリズムを革新し、変更する必要があります。最後に、ADB PG は、更新された新しいアーキテクチャのクラスターのフォールト トレランスと高可用性機能を設計する必要があります。この記事の残りの部分では、上記のトピックについて紹介します。

3. マルチマスターアーキテクチャ設計

元のシングルマスター アーキテクチャと比較して、マルチマスター アーキテクチャは、メインマスター/スタンバイマスターに基づいてセカンダリマスターの役割を実装します。セカンダリ マスターは、メイン マスターと同じ DDL、DML、およびその他の要求をサポートします。同時に、ユーザーは必要に応じて拡張し、システム全体の機能を向上させることができます。以下では、各マスターの役割とそれに対応する主な能力について簡単に紹介します。

メイン マスター: ユーザーのビジネス要求を受け入れ、分散処理のためにさまざまなコンピューティング ノードにタスクを配布します。さらに、メインマスターは、マルチマスターの実装に密接に関連する GTM、FTS、およびグローバルメタ情報サービスの役割も担います。

• GTM: グローバル トランザクション ID とスナップショット情報を管理するグローバル トランザクション マネージャーは、分散トランザクションを実装するためのコア コンポーネントです。
• FTS: フォールト トレランス サービス。コンピューティング ノードと補助調整ノードのヘルス状態を検出し、コンピューティング ノードに障害が発生した場合にコンピューティング ノードのプライマリ ロールとミラー ロールを切り替えます。
• カタログ: システム テーブル Catalog などの情報によって表されるグローバル メタデータ ストレージ。
• スタンバイ マスター: メイン マスターと一般的なマスター/スタンバイ関係を形成し、元のメイン マスターに障害が発生した場合に新しいメイン マスターとして引き継ぐことができます。
• セカンダリマスター: 「弱体化されたメインマスター」とみなすことができます。メインマスターと同様に、ビジネスリクエストを受け入れ、タスクをさまざまなコンピューティングノードに分散して処理することができます。セカンダリ マスターは、GTM プロキシを介してメイン マスター上の GTM およびコンピューティング ノードと対話し、分散トランザクションを実装します。

メイン マスターとセカンダリ マスターは、上位層 SLB を通じて重みベースの負荷分散管理を実行することに注意してください。メインマスターとセカンダリマスターの構成仕様が同じ場合、重み設定によりメインマスターは比較的小さなビジネスリクエスト負荷を引き受け、GTM、FTSなどに十分な処理能力を確保します。

4つのマルチマスターキーテクノロジー

この章では、主に分散トランザクション処理、グローバルデッドロック処理、DDL サポート、分散テーブルロック サポート、クラスターのフォールト トレランス、高可用性など、マルチマスターのいくつかの主要な技術的ポイントについて詳しく説明します。

1 分散トランザクション管理

ADB PGの分散トランザクション実装

ADB PG の分散トランザクションは、2 フェーズ コミット (2PC) プロトコルを使用して実装されます。分散スナップショットは、マスターと異なるセグメント間のデータの一貫性を確保するために使用されます。具体的な実施ポイントは以下の通りです。

分散トランザクションはメインマスターによって開始され、2PC プロトコルを通じてセグメントに送信されます。 2PC は分散システム用の古典的なプロトコルです。トランザクション全体の送信プロセスを、準備とコミット/中止の 2 つの段階に分割します。上記の簡単な図に示されているように、トランザクションに参加するすべてのセグメントが正常に送信された場合にのみ、トランザクション全体が正常に送信されます。最初の段階で準備に失敗したセグメントがある場合、トランザクション全体が中止されます。第 2 段階でコミットに失敗したセグメントがあり、マスターが PREPARED ログを正常に記録した場合、失敗したコミットを再試行するための再試行が開始されます。トランザクションに 1 つのセグメントのみが含まれる場合、パフォーマンスを向上させるために、システムは 1PC 方式でトランザクションを送信するように最適化されることに注意してください。具体的には、上図のマスターによって調整された準備とコミットの 2 つのステージが 1 つに結合され、最終的には参加するセグメントのみがトランザクション実行のアトミック性を保証する責任を負います。

メイン マスター上の GTM グローバル トランザクション管理コンポーネントは、グローバル分散トランザクションのステータスを維持します。各トランザクションは新しい分散トランザクション ID を生成し、タイムスタンプと対応するステータス情報を設定します。スナップショットを取得すると、分散スナップショットが作成され、現在のスナップショットに保存されます。分散スナップショット レコードのコア情報は次のとおりです。

クエリを実行する際、メイン マスターは分散トランザクションやスナップショットなどの情報をシリアル化し、libpq プロトコルを介してセグメントに送信して実行します。セグメントがデシリアライズされた後、対応する分散トランザクションとスナップショット情報が取得され、これに基づいてクエリされたタプルの可視性が決定されます。クエリに参加しているすべてのセグメントは、同じ分散トランザクションとスナップショット情報を使用してタプルの可視性を決定するため、クラスター全体のデータの一貫性が確保されます。さらに、PostgreSQL のコミット ログ ログと同様に、ADB PG はグローバル トランザクションのコミット ログを保存して、トランザクションがコミットされたかどうかを判断します。この情報は共有メモリに保存され、distributedlog ディレクトリに永続的に保存されます。さらに、ADB PG は、ローカル トランザクション ID (xid) と分散グローバル トランザクション ID (gxid) 間のマッピング関係をすばやく見つけられるように、ローカル トランザクション分散トランザクション コミット キャッシュを実装しています。例を使ってこれを理解してみましょう。

上の図に示すように、Txn A がデータを挿入すると、Txn B がそのデータを更新します。 PostgreSQL の MVCC メカニズムに基づいて、現在のヒープ テーブルには 2 つの対応するレコードが存在します。 Txn B がデータを更新した後、元のタプルに対応する xmax を自身のローカル xid 値 (0 から 4) に変更します。その後、2 つのクエリ Txn C と Txn D は、独自の分散スナップショット情報を組み合わせて可視性の判断を行います。具体的なルールは次のとおりです。

• gxid < distribedSnapshot->xminの場合、タプルは表示されます
• gxid > distribedSnapshot->xmaxの場合、タプルは表示されません。
• 分散スナップショット->inProgressXidArrayにgxidが含まれている場合、タプルは表示されません。
• それ以外の場合、タプルは表示されます。分散スナップショットに基づいて可視性を判定できない場合、または分散スナップショットに基づいて可視性を判断する必要がない場合は、ローカルスナップショット情報を使用して判定します。このロジックは、PostgreSQL の可視性を決定するロジックと同じです。

上記のルールに基づいて、Txn C は 2 つのタプル レコードを見つけた後、xid と gxid 間のマッピング関係を通じて、2 つのレコードに対応する gxid 値 (それぞれ 100 と 105) を見つけます。ルール c は、Txn B の更新が Txn C に表示されないように制限するため、Txn C によって照会される結果は 'foo' になります。そして、Txn D はルールに基づいて Txn B によって更新されたタプルに表示されるため、照会された結果は 'bar' になります。

マルチマスターの分散トランザクション実装

マルチマスターの分散トランザクションの本質は、元の分散トランザクションを強化することです。上の図に示すように、Postmaster はデーモン プロセスです。メインマスターのバックエンド業務処理プロセスは共有メモリを介して GTM サーバーと通信しますが、セカンダリマスターは共有メモリを介してメインマスター上の GTM サーバーと直接通信することはできません。このため、セカンダリ マスターとメイン マスターの間にチャネルを追加し、一連の GTM 相互作用プロトコルを実装しました。さらに、セカンダリマスターとメインマスター間の接続を減らし、ネットワーク通信の効率を向上させるために、複数のバックエンドプロセスの GTM リクエストを同じセカンダリマスターにプロキシする GTM プロキシを実装しました。次に、この記事では、マルチマスター分散トランザクション実装の技術的な詳細を、GTM 相互作用プロトコル、GTM プロキシ、分散トランザクション回復の 3 つの側面から体系的に説明します。

（１）GTMインタラクションプロトコル

GTM 相互作用プロトコルは、セカンダリ マスターとメイン マスター間のトランザクション相互作用のコア プロトコルです。特定のプロトコル メッセージと説明を次の表に示します。

ご覧のとおり、メッセージの核となるのは、依然として GXID、SNAPSHOT などの情報を交換し、BEGIN/PREPARE/COMMIT/ABORT などのトランザクション操作を実行することですが、ここでは 1 つ 1 つ説明しません。ノード間のメッセージ相互作用のコストが非常に高いことは指摘する価値があります。 OLAP ユーザーの特性とニーズを考慮して、プロトコルと組み合わせてさまざまな一貫性オプションを提供します。これにより、ユーザーはパフォーマンスと一貫性の間でトレードオフや選択を行うことができます。

• セッションの一貫性: 同じセッションが、モノトニック読み取り、モノトニック書き込み、書き込んだ内容の読み取り、書き込み後の読み取りの一貫性など、期待される一貫性の要件を満たします。
• 強力な一貫性: 線形一貫性。操作が完了すると、すべてのセッションでそれを表示できます。また、さまざまな一貫性モードに基づいてカスタマイズおよび合理化されます。

上記の表に示すように、ユーザーがより高いパフォーマンスを必要とし、一貫性に関してある程度の妥協をできる場合は、セッション一貫性モードを選択できます。強力な一貫性と比較すると、セッション一貫性はプロトコルの相互作用を大幅に簡素化し、GET_GXID と GET_GXID_MULTI のみを保持します。

このうち、GET_GXID_MULTI は本質的に GET_GXID のバッチ操作です。セッション一貫性モードでは、セカンダリ マスターはメイン マスターからグローバル GXID 情報を取得するだけでよく、その後はローカル スナップショット、再試行、および GDD グローバル デッドロック検出 (後述) に基づいてトランザクションを個別に処理するため、マスターとのメッセージ対話が大幅に簡素化され、パフォーマンスが向上します。もちろん、ここでの代償は一貫性の妥協です。実際、セッションの一貫性は、ほとんどの OLAP/HTAP 顧客の要求を満たすことができます。

（２）GTMプロキシの実装

マルチマスターの実装では、GTM Proxy は Postmaster の子プロセスとして管理されます。これによる利点は、1) 新しいロールを追加する必要がなく、サポート管理が簡単になることです。 2) GTM プロキシとバックエンドの間には自然な認証と相互信頼が存在します。 3) GTM プロキシは共有メモリを介してバックエンド プロセスと通信できるため、TCP ループバックよりも効率的であり、メモリ コピーが削減され、ネットワーク スタックのオーバーヘッドが排除されます。

各 GTM プロキシ プロセスは GTM サーバーとのネットワーク接続を確立し、複数のローカル バックエンド プロセスにサービスを提供して、GTM リクエストを GTM サーバーに転送します。 GTM プロキシは、次のようなターゲットを絞ったリクエスト最適化処理も実行します。

• バックエンドはスナップショットを共有してスナップショット要求の数を減らす
• バックエンドへの同時 GTM リクエストをマージしてバッチ処理する
• gxid をバッチ取得 (セッション一貫性)

GTM プロキシは、セカンダリ マスターとメイン マスター間の接続数を減らし、ネットワーク通信の効率を向上させる鍵となります。実際、実装では、ユーザーが強力な一貫性モードをオンにすると、メイン マスターで GTM プロキシがデフォルトでオンになり、メイン マスターと GTM サーバー上の複数のバックエンド プロセス間でリクエストがプロキシされるため、GTM サーバーへの負荷がさらに軽減されます。

（３）分散トランザクションの回復

多くの場合、システムでは、システム/マスターの再起動、メイン マスター/スタンバイ マスターの切り替えなど、分散トランザクションのリカバリを実行する必要があります。マルチマスターを考慮しない場合、分散トランザクションのリカバリは、次の 3 つのステップに簡単に分けることができます。

1. メイン マスターは xlog を再生して、準備はされているがまだコミットされていないすべてのトランザクションを検索します。
2. すべてのセグメントに、コミットする必要があるすべてのトランザクションをコミットするようにコマンドします。
3. すべてのセグメントでコミットされておらず、「メイン マスター」によってコミットされる必要があるトランザクションのリストに含まれていないすべてのトランザクションを収集し、これらのトランザクションを中止します。

上記のプロセスをマルチマスターでさらに検討すると、いくつかの新しい問題が発生します。解決する必要がある主な問題は次のとおりです。1) セカンダリ マスターによって開始されたトランザクションの回復。 2) セカンダリ マスターまたはマスターの再起動時などに、セグメントおよびセカンダリ マスターの準備済みステージに残っているトランザクションのリカバリ/クリーンアップ。この目的のために、マルチ マスターの 2 フェーズ トランザクション送信および分散トランザクション リカバリ プロセスを強化しました。以下では、主に、セカンダリ マスターが削除されて初めて起動されたときの 2 フェーズ トランザクション送信と対応するクリーンアップ プロセスの機能強化について説明します。

さらに、メイン マスター/セカンダリ マスターの再起動プロセスも強化されました。これと元のメイン マスターの再起動と回復との主な違いは、それ自体によって開始された分散トランザクションを区別する必要があることです。具体的な区別は、GXID を強化することによって実現されます。元の GXID 基本情報の上にマスター ID 情報を追加し、{GXID}-MasterID を組み合わせることで、GXID に基づいて特定のマスターを区別できるようになりました。

2 グローバルデッドロック検出

ADB PG 4.3 では、UPDATE および DELETE の実行時にグローバル デッドロックを回避するために、テーブルに書き込みロックが追加されます。この方法はグローバルデッドロックを回避しますが、同時更新のパフォーマンスは非常に低くなります。 ADB PG 6.0 からグローバル デッドロック検出が導入されました。検出プロセスは、クラスター内のロック待機情報を収集して分析します。デッドロックが見つかった場合、デッドロックを解決するために、デッドロックの原因となったプロセスが強制終了されます。これにより、同時実行性の高い状況での単純なクエリ、挿入、削除、更新操作のパフォーマンスが大幅に向上します。 ADB PG 6 でグローバル デッドロック検出を実装する際の重要なポイントは次のとおりです。

• グローバルデッドロック検出サービスプロセス（GDD）はメインマスター上で実行されます。
• GDDは、すべてのセグメント上の分散トランザクションのgxidと待機関係を定期的に取得します。
• GDD は、ループが形成されているかどうかを検出するために、グローバル トランザクション待機関係グラフを構築します。ループが形成された場合、ループ内のトランザクションはロールバックされ、デッドロックが解決されます。

次の図に示すように、ADB PG マルチマスターのグローバル デッドロック検出も、ADB PG 6.0 の実装によって強化されています。

ADB PG マルチマスターの GDD もメインマスター上で実行されます。主に、セカンダリ マスターによって開始された分散トランザクションの gxid リストを収集し、分散トランザクションの原因となるデッドロックを解決するようにセカンダリ マスターに通知するための 2 つのマスター間 RPC 呼び出しを追加します。

• Get_gxids: 各セカンダリマスターからgxidリストを取得し、デッドロックの原因となったトランザクションがどのマスターに属しているかを判断します。
• Cancel_deadlock_txn: デッドロックの原因となったトランザクションがセカンダリマスターに属している場合は、マスターにトランザクションのロールバックを要求します。

3 DDLサポート

ADB PG のネイティブ実装では、メイン マスターは DDL をサポートし、2PC を介してセグメント上のカタログと変更を同期します。 ADBPG マルチマスターは、この実装を拡張して、セカンダリ マスター上のカタログの同期をサポートします。

さらに、セカンダリ マスターは DDL 処理もサポートします。簡単に言えば、セカンダリ マスター内に単純なプロキシを実装しました。セカンダリ マスターが DDL 要求を受信すると、その要求をメイン マスターに転送して処理します。詳細は、次の図に示されています。

DDL の実装は非常に複雑です。実際の実装は上記よりもはるかに複雑で、VACCUM/CLUSTER/ANALYZE などの比較的特殊な DDL 処理など、多くの詳細が含まれます。ただし、全体的な実施計画は基本的に上記の原則に準拠しています。

4 分散テーブルロック

ご存知のとおり、データベースの実装では、テーブル データへの同時アクセスをサポートするために、通常はロックを通じて実装されます。 ADB PG のロック モデルは、次の表に示すように PostgreSQL と互換性があります。

マルチマスターは、ADB PG のテーブル ロック プロトコルを強化および適応します。要約すると、メイン マスターとセカンダリ マスターのロック順序とルールを標準化するために、新しい分散テーブル ロック プロトコルを定義しました。

マスター上のすべてのプロセスがレベル​​1～3のロックを要求する

• テーブルロックをローカルに要求する
• すべてのセグメントのテーブルロックをリクエストする
• トランザクションが終了するとすべてのノードがロックを解除します

メインマスターのプロセスはレベル4-8のロックを要求する

• テーブルロックをローカルに要求する
• すべてのセカンダリマスターのテーブルロックをリクエストする
• すべてのセグメントのテーブルロックをリクエストする
• トランザクションが終了するとすべてのノードがロックを解除します

セカンダリマスターのプロセスはレベル4～8のロックを要求する

• メインマスターのテーブルロックをリクエストする
• テーブルロックをローカルに要求する
• 他のすべてのセカンダリマスターのテーブルロックをリクエストする
• すべてのセグメントのテーブルロックをリクエストする
• トランザクションが終了するとすべてのノードがロックを解除します

上記のルールに基づいて、すべてのテーブル ロック要求が最終的に特定のマスターまたはセグメントによって判断されることを保証し、ADB PG の元のテーブル ロック プロトコルとの互換性を確保できます。

5 クラスタのフォールトトレランスと高可用性

ADB PG は、主に次の機能を含むレプリケーションと監視を通じてフォールト トレランスと高可用性を実現します。1) スタンバイ マスターとミラー セグメントは、それぞれメイン マスターとプライマリ セグメントのレプリカを提供します (PG ストリーミング レプリケーションを通じて実装)。 2) FTS は、バックグラウンドで監視とマスター/スレーブ切り替えを担当します。上図に示すように:

• メインマスターからスタンバイマスターへのストリームレプリケーション。
• プライマリ セグメントからミラー セグメントへのストリーム レプリケーション。
• メインマスターの FTS プローブ プロセスは、プライマリ セグメントを検出するためのパケットを送信します。
• メイン マスターの FTS プローブ プロセスは、セカンダリ マスターを検出するためのパケットを送信します。
• メイン マスターが再起動されると、その FTS プローブ プロセスはすべてのマスターの GTM サーバーに通知します。
• セカンダリ マスターの FTS プローブは、メイン マスターにパケットを送信して、最新のクラスター構成とステータス情報を取得し、それをローカルに保存します。
• セカンダリ マスターの FTS プローブがメイン マスターへの接続に失敗した場合、スタンバイ マスターをアクティブ化しようとします。成功した場合、新しいメインマスターに更新されます。それ以外の場合は、元のメインマスターが引き続きアクティブ化されます。

簡単に言えば、ADBPG マルチマスターは、元の ADB PG のフォールト トレランスと高可用性を強化し、システムとセカンダリ マスターとの互換性をさらに高めます。さらに、セカンダリマスターに障害が発生した場合は、管理および制御システムによってさらに監視され、リアルタイムで修復されます。

5. マルチマスター拡張性能評価

ADB PG シングルマスター インスタンスは、高同時実行ポイント クエリやインポートなどの OLTP 指向のシナリオでシングルマスターのボトルネックに直面することが多く、マルチマスターを導入することでこの問題はうまく解決されます。 OLTP 負荷下でのマルチマスターのスケールアウト能力を検証するために、このセクションでは、デフォルトのセッション一貫性モードで ADB PG マルチマスターの 2 つの一般的な負荷 (TPC-B と C) でパフォーマンス テストを実行します。

1 TPC-C パフォーマンステスト

TPC-C は、トランザクション処理パフォーマンス評議会 (TPC) の下で設定された主流のパフォーマンス テスト ベンチマークであり、主にデータベース システムのトランザクション機能をテストします。 TPC-C テストでは、同時実行やオンラインとオフラインのトランザクションの混合実行など、複数のトランザクション処理方式が実装され、データベース システムのトランザクション機能を総合的に検査できます。私たちが使用するテスト環境は、Alibaba Cloud ECS の ADB PG インスタンスに基づいています。具体的なパラメータは次のとおりです。

• マスター（メインマスター/セカンダリマスター）：8c64g
• ノード仕様（セグメント）：4C32G
• ノード数（セグメント）: 32
• ストレージタイプ: ESSD クラウドディスク
• ノードストレージ容量（セグメント）：1000GB

ご覧のとおり、マスターが 1 つしかない場合、同時実行数が 64 に達すると、TPC-C のパフォーマンスは基本的にピークに達し、同時実行数が増えても向上することはできません。ただし、マスターが 4 つある場合でも、同時実行数の増加に応じて TPC-C のパフォーマンスは線形に拡張できます。

2 TPC-Bパフォーマンステスト

TPC-B は、TPC に基づいて設定された別のパフォーマンス テスト ベンチマークであり、主にシステムが 1 秒あたりに処理できる同時トランザクションの数を測定するために使用されます。私たちが使用するテスト環境は、Alibaba Cloud ECS の ADB PG インスタンスに基づいています。具体的なパラメータは次のとおりです。

• マスター（メインマスター/セカンダリマスター）：8c64g
• ノード仕様（セグメント）：4C32G
• ノード数（セグメント）: 32
• ストレージタイプ: ESSD クラウドディスク
• ノードストレージ容量（セグメント）：1000GB

TPC-C と同様に、マスターが 1 つしかない場合、同時実行数が 64 に達すると、TPC-B のパフォーマンスは基本的にピークに達し、同時実行数の増加に伴って向上できないことがわかります。ただし、マスターが 4 つある場合でも、同時実行性の増加に伴って TPC-B のパフォーマンスは直線的に拡張されます。

VI.結論

ADB PG マルチマスターは、マスターノードを水平に拡張することで、元のアーキテクチャにおける単一マスターの制限を効果的に克服しました。コンピューティング ノードの弾力性と組み合わせることで、システム全体の機能、特に接続数と読み取り/書き込みパフォーマンスがさらに向上し、リアルタイム データ ウェアハウスや HTAP などのビジネス シナリオのニーズをより適切に満たすことができます。