Limitations#

展開を計画するときは、次のEDB Postgres分散PGDデザインの制限を考慮してください。

ノード#

  • PGDは、適切なハードウェアとネットワークを想定して、数百のノードを実行できます。ただし、メッシュベースの展開の場合、通常は1つのクラスターで48を超えるノードを実行することはお勧めしません。 48ノード制限を超えて追加の読み取りスケーラビリティが必要な場合は、メッシュネットワークへの接続を追加せずにサブスクライバ専用ノードを追加できます。

  • PGDのコンセンサスメカニズムにフォールトトレランスを提供するために、グループ内のノードの最小推奨数は3です。 2つのノードのみの場合、ノードの1つが応答しない場合、コンセンサスは失敗します。分散シーケンス生成などの一部のPGD操作では、コンセンサスが必要です。 EDB Postgres Distributedが使用するコンセンサスメカニズムの詳細については、 アーキテクチャの詳細 を参照してください。

単一のインスタンス上の複数のデータベース#

同じPostgresインスタンス上の複数のデータベースでPGDを使用することのサポートは、 PGD 5から 非推奨 であり、PGD 6ではサポートされなくなります。製品の機能を拡張するにつれて、操作的および機能的に導入される追加の複雑さはありません。マルチデータベースデザインではより長く実行可能です。

これがベストプラクティスであり、 PGDインスタンスごとに1つのデータベースのみを構成することをお勧めします。

TPAを使用した展開の自動化と、CLIやPGDプロキシなどのツールは、既にその推奨事項を成文化しています。

単一のインスタンスで最大10のデータベースをホストすることは引き続き可能ですが、そうすると多くの差し迫ったリスクと現在の制限が発生します。

  • PGD構成の変更が必要な場合は、データベースごとに管理コマンドを実行する必要があります。これを行うと、潜在的な不一致とエラーのリスクが増加します。

  • 各データベースを個別に監視する必要があり、オーバーヘッドを追加します。

  • TPAexecは、1つのデータベースを想定しています。より多くのデータベースのレプリケーションを設定するには、顧客またはEDBプロフェッショナルサービスチームが展開後フックで追加のコーディングが必要です。

  • PGDプロキシは、データベースレベルではなくPostgresインスタンスレベルで動作します。つまり、リーダーノードがすべてのデータベースで同じであることを意味します。

  • データベースを追加するごとに、サーバーのリソース要件が増加します。それぞれが、レプリケーションを維持する独自のワーカープロセス、たとえば、論理ワーカー、WALセンダー、WALレシーバーなどを必要とします。それぞれは、レプリケーションクラスター内の他のインスタンスへの独自の接続セットも必要です。これらのニーズは、すべてのデータベースのパフォーマンスに重大な影響を与える可能性があります。

  • CAMOやグループコミットなどの同期レプリケーション方法は、予想通りに動作しません。 Postgres WALはデータベース間で共有されるため、同期コミット確認は任意のデータベースから取得できますが、必ずしも正しいコミットの順序ではありません。

  • CLIとOTELの統合v5の新機能は、1つのデータベースを想定しています。

耐久性オプション グループコミット/ CAMO#

PGD耐久性オプションの動作にはさまざまな制限があります。これらの制限は、 Group CommitとCAMO間の相互作用、およびそれらが Decoding worker や トランザクションストリーミングでの使用 などのPGD機能とどのように相互作用するかの製品です。

また、古い同期レプリケーションとの相互運用性、明示的な2フェーズコミットとの相互運用性、およびコミットスコープルール内でサポートされていない組み合わせにも制限があります。

完全な現在のリストについては、 Durability limitations を参照してください。

混合PGDバージョン#

PGDは、アップグレードプロセス中にPGDの混合バージョンが動作できるようにすることにより enable rolling upgrades of PGD に開発されましたが、ユーザーはアップグレード中にのみ混合バージョンを実行し、ユーザーはできるだけ早くアップグレードを完了することを想定しています。また、ローリングアップグレードプロセスを運用環境で試行する前に、非運用環境でテストすることをお勧めします。

ノードがアップグレードされると、クラスターに戻り、クラスター内の他のすべてのノードでサポートされているノード間プロトコルの最も低いバージョンを使用して、クラスター内の他のノードと通信します。 これは、アップグレードされたノードがクラスター内の他のすべてのノードと通信できるようになりますが、 PGDの新しいバージョンで導入された新機能や改善を利用できないことを意味します。

これは、クラスター内のすべてのノードが同じ新しいバージョンにアップグレードされるまで続きます。 混合バージョンの実行が長くなると、新しいバージョンのメリットを享受できない時間が長くなり、混合バージョンの実行から発生する可能性のある潜在的な相互運用性問題にさらされる時間が長くなります。混合バージョンのクラスターは、長期間サポートされていません。

したがって、 PGDクラスターのアップグレードが開始されたら、できるだけ早くクラスター全体のアップグレードを完了する必要があります。

アップグレード中を除き、PGDの混合バージョンの実行はサポートされておらず、アップグレード中であっても長期間混合バージョンを実行しているクラスターはサポートされていません。

ローリングアップグレードと混合バージョンの詳細については、 Rolling upgrade considerations を参照してください。

その他の制限#

この非包括的なリストには、予想されるデザインによる他の制限が含まれています。将来的にそれらを解決する予定はありません。 展開を計画するときは、次の制限を考慮してください。

  • galloc シーケンスは、ロールバックしたトランザクションでシーケンスを作成し、同じ名前で再度作成する場合、一部のチャンクをスキップする場合があります。チャンクのスキップは、 DDLレプリケーションがアクティブでないときにシーケンスを作成して削除し、 DDLレプリケーションがアクティブなときに再度作成する場合にも発生する可能性があります。順序保証に違反しないため、問題の影響は軽度です。シーケンスは、一部の最初のチャンクのみをスキップします。また、回避策として、シーケンスの開始値をbdr.alter_sequence_set_kind() ファンクションの引数として指定できます。