Limitations¶
展開を計画するときは、これらのEDB Postgres Distributed（PGD）の設計制限を考慮に入れてください。
ノード¶
PGDは、適切なハードウェアとネットワークを前提に、数百のノードを実行できます。ただし、メッシュベースの展開の場合、通常、1つのクラスターで48を超えるノードを実行することはお勧めしません。 48ノードの制限を超える追加の読み取りスケーラビリティが必要な場合は、メッシュネットワークに接続を追加せずにサブスクライバー専用ノードを追加できます。
PGDには現在、1000アクティブノード以下のハード制限があります。これは、これが許可される現在の最大Raft接続であるためです。
グループ内のノードの推奨最小数は3です。PGDのコンセンサスメカニズムにフォールトトレランスを提供します。 2つのノードだけで、ノードの1つが応答しないとコンセンサスは失敗します。分散シーケンス生成など、一部のPGD操作にはコンセンサスが必要です。 EDB Postgres Distributedによって使用されるコンセンサスメカニズムの詳細については、 Architectural details を参照してください。
単一インスタンス上の複数のデータベース¶
同じPostgresインスタンス上の複数のデータベースにPGDを使用するためのサポートは、PGD 5以降で 非推奨 になり、PGD 6でサポートされなくなります。マルチデータベース設計でより長く実行可能。
これがベストプラクティスであり、PGDインスタンスごとに1つのデータベースのみを構成することをお勧めします。
TPAによる展開の自動化と、CLIやPGDプロキシなどのツールは、既にその推奨事項を成文化しています。
1つのインスタンスで最大10個のデータベースをホストすることは引き続き可能ですが、そうすると多くの即時のリスクと現在の制限が発生します。
PGD構成の変更が必要な場合、データベースごとに管理コマンドを実行する必要があります。そうすると、潜在的な不整合やエラーのリスクが高まります。
各データベースを個別に監視する必要があり、オーバーヘッドが追加されます。
TPAexecは1つのデータベースを想定しています。より多くのデータベースのレプリケーションを設定するには、顧客またはEDBプロフェッショナルサービスチームが展開後のフックで追加のコーディングが必要です。
PGDプロキシは、データベースレベルではなくPostgresインスタンスレベルで動作します。つまり、リーダーノードはすべてのデータベースで同じです。
データベースが追加されるたびに、サーバーのリソース要件が増加します。それぞれには、レプリケーションを維持する独自のワーカープロセスのセット、たとえば、論理ワーカー、WAL送信者、WAL受信者が必要です。また、それぞれには、レプリケーションクラスター内の他のインスタンスへの独自の接続セットが必要です。これらのニーズは、すべてのデータベースのパフォーマンスに深刻な影響を与える可能性があります。
・
ノードの再構築または追加を行う場合、1つのデータベースの物理初期化方法(bdr_init_physical
)は1ノードのみ利用できます。他のすべてのデータベースは論理レプリケーションで初期化する必要があります。これは、時間がかかるため大規模なデータベースでは問題になる可能性があります。
CAMOやGroup Commitなどの同期レプリケーション方法は、期待どおりに機能しません。 Postgres WALはデータベース間で共有されるため、同期コミット確認は、必ずしも正しいコミットの順序でなく、任意のデータベースから来ることができます。
CLIとOTELの統合（v5の新機能）は1つのデータベースを前提としています。
CAMO¶
Commit At Most Once （CAMO）は、アプリケーションが複数回コミットするのを防ぐことを目的とした機能です。この機能を使用する場合は、計画時に次の制限を考慮してください。
CAMOは、オリジンノードで最近失敗したCOMMITの結果を照会するように設計されています。そのため、切断された場合には、アプリケーションをコーディングして、 CAMOパートナーからトランザクションステータスをすぐに要求します。障害が発生してからステータスを要求するまでの遅延をできるだけ短くします。アプリケーションは、 CAMOの決定が15分以上保存されることに依存してはなりません。
アプリケーションが、たとえば、再起動の結果として、割り当てられたグローバル識別子を忘れた場合、それを回復する簡単な方法はありません。したがって、アプリケーションは、未処理のトランザクションが終了するのを待ってからシャットダウンすることをお勧めします。
クライアントが適切なチェックを適用するには、 CAMOによって保護されたトランザクションを、暗黙的なトランザクション制御を持つ単一のステートメントにすることはできません。トランザクション制御プロシージャまたはトランザクションを開始または終了しようとする
DOブロックでCAMOを使用することもできません。
CAMOはコミットステータスを解決しますが、コミット時に保留中の通知を解決しません。
CAMOおよびEager Replicationオプションでは、 NOTIFY
SQLコマンドまたはpg_notify() 関数は許可されません。 LISTEN
またはUNLISTEN も許可しません。
変更をリプレイするとき、 CAMOトランザクションは他のトランザクションと同じように競合を検出する場合があります。タイムスタンプ競合検出を使用する場合、 CAMOトランザクションは、オリジンノードでの準備のタイムスタンプを使用します。これは、トランザクションがオリジンノード自分自身で可視になる前です。
CAMOは現在、トランザクションストリーミングと互換性がありません。 CAMOの使用を計画している場合は、トランザクションストリーミングを必ず無効にしてください。このオプションは、グローバルに構成するか、PGDノードグループで構成できます。 Transaction streaming configuration を参照してください。
その他の制限¶
この非包括的なリストには、設計による予想されるその他の制限が含まれています。将来的にそれらを解決する予定はありません。展開を計画するときは、次の制限を考慮してください。
ノードをフィジカルスタンバイに置き換えても、 CAMO/ Eager / Group Commitを使用するノードでは機能しません。たとえ可能であっても、フィジカルスタンバイとEDB Postgres Distributedを組み合わせることはお勧めしません。
gallocシーケンスは、ロールバックされたトランザクションでシーケンスを作成し、同じ名前で再度作成すると、一部のチャンクをスキップする場合があります。 DDLレプリケーションがアクティブでないときにシーケンスを作成して削除し、 DDLレプリケーションがアクティブなときに再度作成した場合にも、チャンクのスキップが発生する可能性があります。シーケンスの保証に違反しないため、問題の影響は軽度です。シーケンスは、一部の最初のチャンクのみをスキップします。また、回避策として、シーケンスの開始値をbdr.alter_sequence_set_kind()関数への引数として指定できます。レガシー同期レプリケーションは、 CAMO、 Eager、およびGroup Commitで使用されるものとは異なるトランザクション確認のメカニズムを使用します。この2つは互換性がありませんので、一緒に使用しないでください。
Postgresの2フェーズコミット（2PC）トランザクション（つまり、 PREPARE TRANSACTION ）は、 CAMO、グループコミット、またはEager Replicationと一緒に使用できません。これらの機能は下で2フェーズコミットを使用するためです。
