PGD overview

EDB Postgres分散PGDは、高度な競合管理、データ損失保護、および

throughput up to 5X faster than native logical replication を備えたマルチマスターレプリケーションとデータ分散を提供します。また、最大ファイブナインの高可用性を備えた分散Postgresクラスターも有効にします。

PGDは、メッシュトポロジを使用して、疎結合のマルチマスター論理レプリケーションを提供します。これは、任意のサーバーに書き込むことができ、変更は行ごとに、同じPGDグループの一部である他のすべてのサーバーに直接送信されることを意味します。

デフォルトでは、 PGDは非同期レプリケーションを使用し、ローカルコミットの後にのみピアノードに変更を適用します。複数の同期レプリケーションオプションも使用できます。

基本アーキテクチャ

複数のグループ

PGDノードは、少なくとも1つの ノードグループ のメンバーです。最も基本的なアーキテクチャでは、PGDクラスター全体に対応する単一のノードグループがあります。

マルチプルのマスター

PGDグループに参加する各ノードデータベースは、他のメンバーから変更を受け取り、ユーザーが直接書き込むことができます。

これは、1つのマスターサーバーのみが書き込みを受け入れ、他のすべてのノードがマスターまたは別のスタンバイから複製するスタンバイであるホットまたはウォームスタンバイとは異なります。

すべてのマスターに常に書き込む必要はありません。頻繁な構成では、ほとんどの書き込みが

ライトリーダー と呼ばれる1つのマスターに転送されます。

デフォルトで非同期

1つのPGDノードで行われた変更は、ローカルにコミットされるまで他のノードに複製されません。その結果、データは常にすべてのノードで完全に同じではありません。一部のノードには、他のノードにまだ到着していないデータがあります。 PostgreSQLのブロックベースのレプリケーションソリューションも、デフォルトで非同期レプリケーションになります。 PGDには、複数のマスターがあり、その結果、複数のデータストリームが存在します。したがって、synchronous_commit およびsynchronous_standby_names を使用する場合でも、異なるノード上のデータは異なる場合があります。

メッシュトポロジ

PGDは、すべてのノードが他のすべてのノードに接続し、すべてのノードが互いに直接データを交換するメッシュネットワークを中心に構造化されています。ノードの追加や削除などの特別な状況を除き、 PGDにはデータの転送はありません。データはEDB Postgres分散クラスターの外部から到着するか、ネイティブのPostgreSQL論理レプリケーションを使用して転送できます。

論理レプリケーション

論理レプリケーションは、レプリケーションID通常は主キーに基づいて、データ行とその変更をレプリケートする方法です。正確なブロックアドレスとバイトごとのレプリケーションを使用する物理的レプリケーションとは対照的に、論理的という用語を使用します。インデックスの変更はレプリケートされないため、書き込み増幅を回避し、帯域幅を削減します。

論理レプリケーションは、ソースノードからデータのスナップショットをコピーすることから始まります。それが完了すると、後のコミットはリアルタイムで発生すると他のノードに送信されます。変更はSQLを再度実行せずにレプリケートされるため、書き込まれた正確なデータが迅速かつ正確にレプリケートされます。

ノードは、ソースノードでコミットが行われた順序でデータを適用し、単一ノードからの変更に対してトランザクションの一貫性が保証されます。さまざまなノードからの変更は他のノードとは無関係に適用され、変更の迅速なレプリケーションが保証されます。

レプリケートされたデータは、安全な場合にはバイナリ形式で送信されます。

接続管理

接続管理 は、コンセンサス駆動クォーラムを活用して、半排他的な方法で正しい接続エンドポイントを決定し、アプリケーションからの意図しないマルチノード書き込みを防止します。このアプローチにより、データの競合の可能性が減少します。任意の時点で、正しい接続エンドポイントとして選択されたノードは、 ライトリーダー と呼ばれます。

各ホストにPGDプロキシ構成をインストールする は、 EDB Postgres

Distributedの一部として提供されるアプリケーション接続管理のためのツールです。

高可用性

各マスターノードは1つ以上のスタンバイノードで保護できるため、ダウンしたノードはすぐに置き換えて続行できます。各スタンバイノードは論理スタンバイノードです。 Postgresフィジカルスタンバイは、PGDではサポートされていません。

1つ以上のノードが現在使用できない場合でも、現在接続されているノード間でレプリケーションは続行されます。ノードが復旧すると、レプリケーションは、変更を見逃すことなく、中断した場所からリスタートできます。

ノードはさまざまなリリースレベルを実行でき、通信に必要なプロトコルをネゴシエートします。その結果、 EDB Postgres分散クラスターは、データベースソフトウェアのメジャーバージョンの場合でも、ローリングアップグレードを使用できます。

DDLは、デフォルトでノード間でレプリケートされます。必要に応じて、 DDL実行をユーザーが制御して、アプリケーションのローリングアップグレードを許可できます。

アーキテクチャオプションとパフォーマンス

Always Onアーキテクチャ

多数の異なるアーキテクチャを構成できますが、それぞれが異なるパフォーマンスとスケーラビリティ特性があります。

グループは、2つ以上のノードサーバーで構成される基本的なビルディングブロックです。グループでは、各ノードは専用のルーターとバックアップを備えた異なるアベイラビリティーゾーンにあり、即時のスイッチオーバーと高可用性を提供します。各グループには、専用のレプリケーションセットが定義されています。グループがノードを失った場合、グループから既存のノードをコピーすることにより、簡単に修復または置換できます。

Always Onアーキテクチャは、1つの場所にある1つのグループ、または2つの別の場所にある2つのグループから構築されます。各グループは高可用性を提供します。 2つのグループが遠隔地で活用される場合、それらは一緒にディザスターリカバリーDRも提供します。

テーブルは両方のグループにまたがって作成されるため、変更はローカルグループのノードだけでなく、すべてのノードに適用されます。

各グループの1つのノードがグループの書き込みリーダーとして選択されます。書き込みリーダーは、メインアプリケーションの書き込みとクエリのターゲットです。他のすべてのノードはシャドウノードまたは「読み取り/書き込みレプリカ」として説明され、必要に応じて引き継ぎを待機します。ノードが接続を失うと、処理はすぐにシャドウノードに切り替わって処理を続行します。グループに障害が発生した場合、処理は他のグループに切り替えることができます。スケーラビリティはこのアーキテクチャの目標ではありません。

書き込みは主に1つのノードのみに行われるため、ノード間の競合の可能性はほぼゼロに減少します。その結果、パフォーマンスへの影響が大幅に削減されます。

セカンダリアプリケーションはシャドウノードに対して実行される場合がありますが、メインアプリケーションがそのノードの使用を開始すると、これらは削減または中断されます。

将来的には、1つのノードが他のグループのメインレプリケーターとして選択され、クラスターの成長に応じてレプリケーションのCPUオーバーヘッドを制限し、他のグループへの帯域幅を最小化します。

サポートされているPostgresデータベースサーバー

PGDは、 PostgreSQL 、 EDB Postgres Extended Server 、および EDB Postgres Advanced ServerのPGDのインストール と互換性があり、 BDRという名前の標準のPostgres拡張機能として展開されます。サポートされているバージョンの組み合わせの詳細については、

互換性 を参照してください。

一部の主要なPGD機能は、ターゲットPostgresデータベースサーバーで使用可能な特定のコア機能に依存しています。したがって、 PGDユーザーは、ビジネスニーズに最適なPostgresデータベースサーバーディストリビューションも採用する必要があります。たとえば、 PGD機能のCommit At Most OnceCAMOを使用することがユースケースにとってミッションクリティカルである場合、コミュニティPostgreSQLディストリビューションを採用しないでください。 CAMOを処理するために必要なコア機能がありません。

Choosing a Postgres distribution の完全な機能マトリックスの互換性を参照してください。

PGDは、ネイティブに近いPostgresの互換性を提供します。ただし、一部のアクセスパターンは、単一のインスタンスで行う場合と同じようにマルチノード設定で必ずしも機能するとは限りません。マルチノード設定で安全に複製できるものには、いくつかの制限があります。

Application usage は、アプリケーション開発の観点からPGDがどのように動作するかについて詳しく説明します。

パフォーマンスに影響を与える特性

デフォルトでは、 PGDはグループ内の各ノードに各テーブルのコピーを1つ保持し、変更はグループ内のすべてのノードに伝播します。

データのコピーはどこにでもあるため、SELECTはローカルノードにアクセスすることのみが必要です。読み取り専用クラスターでは、ノードのパフォーマンスはノード数の影響を受けず、長時間実行されたSELECTクエリによって発生する他のノードでのレプリケーション競合の影響を受けません。したがって、ノードを追加すると、可能な合計SELECTスループットが線形に増加します。

INSERT、UPDATE、およびDELETEDMLがローカルで実行される場合、変更はグループ内のすべてのノードに伝播します。 DML applyのオーバーヘッドは、元の実行よりも少なくなります。したがって、複数のノードで純粋な書き込みワークロードを同時に実行する場合、マルチノードクラスターは、シングルノードよりも多くのTPSを処理できます。

競合処理にはコストがかかり、スループットを低下させます。スループットは、実際にアプリケーションが表示する競合の量によって異なります。競合が非常に低いアプリケーションは、単一ノードよりも優れたパフォーマンスを示します。競合の多いアプリケーションは、単一ノードよりもパフォーマンスが低下する場合があります。これらの結果は、マルチマスターテクノロジーと一貫性があり、PGDに固有ではありません。

同期レプリケーションオプションは、変更をマルチプルのノードに同時に送信できるため、レプリケーション遅延を最小限に抑えることができます。ノードを追加するということは、レプリケーションにより多くのCPUを使用することを意味するため、各ノードが追加されるとピークTPSがわずかに減少します。

ワークロードがすべてのCPUリソースを使用しようとすると、このリソースがレプリケーションを制約し、レプリケーションラグに影響を与える可能性があります。

要約すると、すべての書き込みがすべてのノードで再生されるため、ほとんどのテーブルがレプリケートされる場合、PGDグループにマスターノードを追加しても、大幅な書き込みスループットの増加はありません。 PGD書き込みは、一般にSQLを介してPostgresクライアントからの書き込みよりも効果的であるため、パフォーマンスを向上させることができます。読み取りスループットは、一般にノードの数に線形にスケールします。