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