PGD overview¶

EDB Postgres Distributed（PGD）は、マルチマスターレプリケーションとデータ分散を、高度な競合管理、データ損失保護、およびネイティブ論理レプリケーションよりも最大5倍高速なスループットを提供します。また、最大ファイブ・ナインの高可用性を備えた分散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を再度実行せずにレプリケートされるため、書き込まれた正確なデータが迅速かつ正確にレプリケートされます。

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

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

接続管理¶

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

Installing PGD Proxy は、 EDB Postgres

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

高可用性¶

各マスターノードは1つ以上のスタンバイノードで保護できるため、ダウンしたノードをすばやく交換して続行できます。各スタンバイノードは、論理スタンバイノードまたはフィジカルスタンバイノードのいずれかです。

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 と互換性があり、 BDRという名前の標準のPostgres拡張機能としてデプロイされます。サポートされているバージョンの組み合わせの詳細については、

Compatibility matrix を参照してください。

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

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

PGDは、ネイティブに近いPostgres互換性を提供します。ただし、一部のアクセスパターンは、マルチノードセットアップで必ずしも単一インスタンスで機能するとは限りません。マルチノード設定で安全に複製できるものにもいくつかの制限があります。: Application usage は、アプリケーション開発の観点からPGDがどのように動作するかについて詳しく説明します。

パフォーマンスに影響する特性¶

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

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

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

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

同期レプリケーションオプションは、レプリケーションラグを最小限に抑えるように、複数のノードに同時に変更を送信できます。ノードを追加すると、レプリケーションにより多くのCPUを使用することになるため、ノードが追加されるたびにピークTPSがわずかに低下します。

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

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