Choosing between Physical Streaming Replication (PSR) and EDB Postgres Distributed (PGD)
========================================================================================

EDBは、高可用性と分散高可用性の両方をサポートしています。高可用性は、物理ストリーミングレプリケーションPSRを介して実現されますが、通常はEDB
Failover EFMやPatroniなどの外部ツールで管理されます。分散高可用性は、
EDB Postgres分散PGDで実現されます。

Postgresの適切なレプリケーション戦略の選択は、アプリケーション固有の可用性、一貫性、および地理的要件によって異なります。
PSRはローカルの高可用性と標準のDRシナリオに効果的ですが、
PGDは、高度な一貫性と耐久性の保証とともに継続的な書き込み可用性を必要とする「常時オン」のグローバルアーキテクチャ向けに設計されています。

EFMまたはPatroniを使用したPSR
-----------------------------

PSRセットアップでは、ノードは通常、プライマリまたはスタンバイとして分類されます。プライマリは、すべての書き込み操作を処理し、先行書き込みログWALストリームを生成する中央機関として機能します。スタンバイは、継続的な復旧状態を維持する復元力のあるセカンダリノードとして機能します。

PSRはブロックレベルで動作し、1つ以上のスタンバイにプライマリのバイトごとのコピーを作成します。
PostgreSQLは自動フェイルオーバーをネイティブに処理しないため、外部オーケストレーションツールが必要です。

PSR管理ツール
^^^^^^^^^^^^^

PSRを管理するためのツールは数多くありますが、ここで強調表示されている2つのツールは、EDB顧客または最も広く採用されているオープンソースソリューションによって最も広く展開されているため、EDBによってサポートされています。

- `EDB Failover Manager (EFM): <https://www.enterprisedb.com/docs/efm/latest/>`_ 
  このエンタープライズグレードのエージェントは、クラスターの状態を監視し、仮想IPVIPアドレスを管理し、スタンバイからプライマリへのプロモーションを自動化します。このソリューションは、ネイティブPSRを優先し、書き込み操作が単一のノードに集中しているベアメタルおよび仮想化プラットフォームを使用する場合に最適です。このアーキテクチャでは、セカンダリリージョンは通常、ディザスターリカバリーDRターゲットとして機能します。リージョン間でトラフィックを移動するには、通常、データベースとアプリケーションレイヤーの両方で正式な調整されたプロモーションプロセスが必要です。

- :ref:`Patroni: </supported-open-source/patroni/>` 
  これは、活発な開発コミュニティがあるPSR用の人気のオープンソースオーケストレーションツールです。
  Patroniは、外部の分散コンセンサスストアDCS、最も一般的には\ ``etcd``
  に依存して、リーダー選択とクラスター状態を維持します。
  EFMと同様に、このソリューションは、通常プライマリおよびセカンダリリージョンにサービスを提供し、サイト間で操作をシフトするための調整された手動またはスクリプト化されたプロセスを必要とするアーキテクチャを使用したPSRを既に選択している場合に最適です。

EDB Postgres Distributed PGD
----------------------------

PGDは、PostgreSQLを分散マルチマスタープラットフォームに変換する統合拡張スタックです。これは、PGDアーキテクトによってPostgreSQLコアに提供された
**論理レプリケーション**
機能をもとに構築されていますが、コア機能に欠けている重要なクラスター全体のオーケストレーションを追加します。

PGDを選択する場合
^^^^^^^^^^^^^^^^^

PGDは、ダウンタイムがオプションでなく、グローバルなフットプリント全体でデータの完全性を保証する必要があるティア1エンタープライズアプリケーション向けに設計されています。要件に次のものが含まれる場合、PGDを検討します。

- **高度な耐久性と分散一貫性**
  同期性の限定された大まかなオプションを提供するPSRとは異なり、PGDは真の分散一貫性を提供します。
  `commit scopes <https://www.enterprisedb.com/docs/pgd/latest/commit-scopes/>`_ を介して、ローカルノードとリモートノードの両方の適用動作を正確に定義できます。これにより、トランザクションが永続的であると考えられる前に、確認する必要があるノードの数と特定のリージョンを正確に選択でき、グローバルからトランザクションレベルまでデータ保護に対してパフォーマンスのバランスを保つことができます。

- **常時接続要件99.999%**
  PGDは、ゼロ待機フェイルオーバーを提供します。すべてのノードは書き込み可能です。いずれかに障害が発生すると、アプリケーションは昇格プロセスを待たずに別のアクティブノードに再ルーティングします。これにより、PSRに固有の検出とプロモーションの遅延が排除され、目標復旧時間RTOがネットワークトラフィックの再ルーティングに必要な時間に削減されます。

- **ゼロダウンタイム操作**
  PGDは、アプリケーションがオンラインになったままのローリングアップグレードとOSパッチを有効にします。クラスターはアクティブ-アクティブであるため、書き込み可用性を失ったり、複雑なスイッチオーバープロセスを必要としたりすることなく、メンテナンスのためにノードを1つずつオフラインにすることができます。このアーキテクチャでは、他のノードの可用性やパフォーマンスに影響を与えることなく、特定のノードで\ ``REINDEX``
  や\ ``VACUUM FULL``
  などの大量のメンテナンス操作を実行することもできます。

- **グローバル読み取りおよび書き込みスケーリング**
  大規模な読み取り容量を必要とするワークロードの場合、PGDはサブスクライバ専用ノードをサポートします。書き込み可能なノードと大規模なサブスクライバーをメッシュアーキテクチャ内のユーザーの物理的に近くに配置することにより、クロスリージョンの遅延を排除し、地理に関係なくきびきびとしたアプリケーションの応答時間を保証します。このアプローチでは、プライマリリージョン全体で高性能の書き込みファブリックを維持しながら、読み取りをスケーリングできます。

PostgreSQLのPGD、PSR+EFM、pglogical2、およびコア論理レプリケーション間の詳細な内訳については、
:ref:`Comparing replication solutions <Comparing replication solutions>` を参照してください。

現在の環境を移行するには、ステップバイステップガイド `Migrating from Postgres Physical Streaming Replication (PSR) to PGD <https://www.enterprisedb.com/docs/pgd/latest/lifecycle/migrating/migration-psr/>`_ 
に従ってください。
