Known issues and limitations ============================ 既知の問題 ---------- これらはEDB Postgres Distributed {{version.full}}の現在既知の問題です。これらの既知の問題はPGDのチケットシステムで追跡され、将来のリリースで解決される予定です。 - マテリアライズドビューのレプリケーションは、新しく作成されたマテリアライズドビューでのみ機能します。 {{version.full}}.0にアップグレードする前に作成されたマテリアライズドビューは、アップグレード後に複製されません。この問題を防ぐには、次のいずれかを行うことができます。 - PGD {{version.full}}.0.にアップグレードする前に、各ノードでマテリアライズドビューを手動で作成します。 - OR - PGDにアップグレードした後 {{version.full }}.0.、マテリアライズドビューをドロップして作成して、複製されるようにします。 - ``update_origin_change`` 競合のリゾルバーが\ ``skip`` に設定され、\ ``synchronous_commit=remote_apply`` が使用され、同じ行の同時更新が2つの異なるノードに繰り返し適用される場合、 PGDライタとのデッドロックが原因で更新ステートメントの1つがハングする場合があります。 `Conflicts `_ で述べたように、 ``skip`` は\ ``update_origin_change`` 競合のデフォルトのリゾルバーではなく、この組み合わせは運用環境で使用することを目的としていません。そのノードへの到着順序に基づいて、2つの競合する更新のうちの1つを破棄します。これにより、発散クラスターが発生する可能性があります。 ``skip`` 競合リゾルバーの使用を選択するまれな状況では、 ``remote_apply`` モードの使用に関する問題に注意してください。 - Decoding Worker機能は、 CAMO/Eager/Group Commitでは動作しません。 CAMO/Eager/Groupコミットを使用したインストールでは、\ ``enable_wal_decoder`` を無効のままにする必要があります。 - Lag Controlは、完全に分離されたノードではいかなる方法でもコミット遅延を調整しません。これは、他のすべてのノードが到達不能または動作していない場合です。 少なくとも1つのノードが接続すると、レプリケーションラグコントロールはその作業を取得し、PGDコミット遅延を再度調整します。 - 時間ベースのラグ制御の場合、PGDは現在、履歴適用レートに基づいた推定キャッチアップ時間ではなく、コミットタイムスタンプによって測定されたラグタイムを使用しています。 - CAMOペアのCAMOパートナーを変更することは現在不可能です。ペアを追加または削除することのみが可能です。ペアを追加または削除するには、Postgresの再起動や構成のリロードも必要ありません。 - グループコミットは `CAMO `_ と組み合わせることはできません。 - Eager Replicationを使用するトランザクションは、まだDDLを実行できません。 TRUNCATEコマンドが使用できます。 - パラレル適用は、グループコミットとの組み合わせで現在サポートされていません。グループコミットを使用するときは、(a) `bdr.alter_node_group_option `_ を使用してノードグループの\ ``num_writers`` を1に設定するか、(b) GUC `bdr.writers_per_subscription `_ を使用して、必ず無効にしてください。 :ref:`Configuration of generic replication ` を参照してください。 - 現在、コミットスコープの変更または削除に対する保護はありません。 同時に変更または削除されるコミットスコープでトランザクションを実行すると、トランザクションを適用しようとしているダウンストリームノードでのエラーが原因で、トランザクションブロックまたはレプリケーションが完全に停止する可能性があります。変更または削除する前に、特定のコミットスコープを使用するトランザクションが終了していることを確認してください。 - `PGD CLI `_ は、クラスターから分離されたノードにまだ接続している場合、クラスターの状態に関する古いデータを返すことができます。 :ref:`pgd-cli-config.yml ` ファイルを編集するか、 :ref:`--dsn ` 設定を変更して、クラスター内のアクティブなノードのみが接続用にリストされるようにします。 コミットスコープを安全に変更するには、 `bdr.alter_commit_scope `_ を使用します。 - シリアル化可能なトランザクションで実行されるDDLは、エラー\ ``ERROR: could not serialize access due to read/write dependencies among transactions`` が発生する場合があります。回避策は、シリアル化可能なトランザクションの外部でDDLを実行することです。 - EDB Postgres Advanced Server 17データ型 :ref:`BFILE ` は、現在サポートされていません。これは、 ``BFILE`` がデータベースに保存されるファイル参照であり、ファイル自分自身はデータベースの外部に保存され、レプリケートされないためです。 制限事項 -------- 展開を計画するときは、次のEDB Postgres分散PGDデザインの制限を考慮してください。 ノード ^^^^^^ - PGDは、適切なハードウェアとネットワークを想定して、数百のノードを実行できます。ただし、メッシュベースの展開の場合、通常は1つのクラスターで48を超えるノードを実行することはお勧めしません。 48ノード制限を超えて追加の読み取りスケーラビリティが必要な場合は、メッシュネットワークへの接続を追加せずにサブスクライバ専用ノードを追加できます。 - PGDのコンセンサスメカニズムにフォールトトレランスを提供するために、グループ内のノードの最小推奨数は3です。 2つのノードのみの場合、ノードの1つが応答しない場合、コンセンサスは失敗します。分散シーケンス生成などの一部のPGD操作では、コンセンサスが必要です。 EDB Postgres Distributedが使用するコンセンサスメカニズムの詳細については、 :ref:`Architecture overview ` を参照してください。 単一のインスタンス上の複数のデータベース ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 同じPostgresインスタンス上の複数のデータベースでPGDを使用することのサポートは、 PGD 5から **非推奨** であり、PGD 6ではサポートされなくなります。製品の機能を拡張するにつれて、操作的および機能的に導入される追加の複雑さはありません。マルチデータベースデザインではより長く実行可能です。 これがベストプラクティスであり、 PGDインスタンスごとに1つのデータベースのみを構成することをお勧めします。 現在、CLIやConnection Managerなどのツールがその推奨事項を成文化しています。 単一のインスタンスで最大10のデータベースをホストすることは引き続き可能ですが、そうすると多くの差し迫ったリスクと現在の制限が発生します。 - PGD構成の変更が必要な場合は、データベースごとに管理コマンドを実行する必要があります。これを行うと、潜在的な不一致とエラーのリスクが増加します。 - 各データベースを個別に監視する必要があり、オーバーヘッドを追加します。 - 接続マネージャーは、データベースレベルではなくPostgresインスタンスレベルで動作します。つまり、リーダーノードはすべてのデータベースで同じです。 - データベースを追加するごとに、サーバーのリソース要件が増加します。それぞれが、レプリケーションを維持する独自のワーカープロセス、たとえば、論理ワーカー、WALセンダー、WALレシーバーなどを必要とします。それぞれは、レプリケーションクラスター内の他のインスタンスへの独自の接続セットも必要です。これらのニーズは、すべてのデータベースのパフォーマンスに重大な影響を与える可能性があります。 - CAMOやグループコミットなどの同期レプリケーション方法は、予想通りに動作しません。 Postgres WALはデータベース間で共有されるため、同期コミット確認は任意のデータベースから取得できますが、必ずしも正しいコミットの順序ではありません。 - CLI統合は、1つのデータベースを想定しています。 耐久性オプショングループコミット/ CAMO ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PGD耐久性オプションの動作にはさまざまな制限があります。これらの制限は、 Group CommitとCAMO間の相互作用、およびそれらが :ref:`WAL decoder ` や `transaction streaming `_ などのPGD機能とどのように相互作用するかの製品です。 また、古い同期レプリケーションとの相互運用性、明示的な2フェーズコミットとの相互運用性、およびコミットスコープルール内でサポートされていない組み合わせにも制限があります。 次の制限は、コミットスコープの使用と、それらが有効にするさまざまな耐久性オプションに適用されます。 一般的な耐久性の制限 ^^^^^^^^^^^^^^^^^^^^ - `Legacy synchronous replication `_ は、 CAMO、 Eager 、および Group Commitで使用されるものとは異なるトランザクション確認のメカニズムを使用します。この2つは互換性がないため、一緒に使用しないでください。 Group Commit、 CAMO、またはEagerを使用するときは、 ``synchronous_standby_names`` でPGDノードが構成されていないことを確認します。 - Postgresの2フェーズコミット2PCトランザクションつまり :ref:`PREPARE TRANSACTION ` は、 CAMO、 Group Commit、またはEagerでは使用できません。これらの機能は下で2フェーズコミットを使用するためです。 グループコミット ^^^^^^^^^^^^^^^^ `Group Commit `_ は、グループ内のノードを介した構成可能な同期コミットを有効にします。この機能を使用する場合、次の制限を考慮してください。 - グループコミットを使用する場合、すべてのDDLを実行できるわけではありません。サポートされていないDDLを使用する場合、警告がログに記録され、トランザクションのコミットスコープがローカルに設定されます。サポートされているDDL操作は次のとおりです。 - 非コンカレント ``CREATE INDEX`` - 非コンカレント ``DROP INDEX`` - 個々のテーブルまたはインデックスの非コンカレント\ ``REINDEX`` - ``CLUSTER`` 単一のリレーションまたはインデックスのみ - ``ANALYZE`` - - - - - - 明示的な2フェーズコミットは、既に2フェーズコミットを使用しているため、グループコミットではサポートされていません。 - 同じトランザクションでの異なるコミット決定オプションの組み合わせ、または同じトランザクションでの異なる競合解決オプションの組み合わせは、サポートされていません。 - 現在、Raftのコミット決定は非常に遅く、非常に低いTPSを生成します。 ``eager`` 競合解決設定でのみこれらを使用して、PGD 4以前のEager All-Node Replication動作を取得することをお勧めします。 熱心な ^^^^^^ `Eager `_ は、グループコミットを介して利用できます。競合する可能性のあるトランザクションを積極的に中止することにより、競合を回避します。これには、グループコミットと同じ制限が適用されます。 Eagerでは、 ``NOTIFY`` SQLコマンドまたは\ ``pg_notify()`` ファンクションは許可されていません。 ``LISTEN`` または\ ``UNLISTEN`` も許可されません。 CAMO ---- `Commit At Most Once `_ CAMOは、アプリケーションが複数回コミットするのを防ぐことを目的とした機能です。この機能を使用する場合、計画時に次の制限を考慮してください。 - CAMOは、オリジンノードで最近失敗したCOMMITの結果を照会するように設計されています。切断が発生した場合、アプリケーションはCAMOパートナーからトランザクションステータスを要求する必要があります。障害後、ステータスを要求する前に、遅延ができるだけ少ないことを確認します。アプリケーションは、15分を超えて保存されるCAMO決定に依存してはなりません。 - 再起動などの結果、アプリケーションが割り当てられたグローバル識別子を忘れた場合、それを回復する簡単な方法はありません。したがって、アプリケーションはシャットダウンする前に、未処理のトランザクションが終了するのを待機することをお勧めします。 - クライアントが適切なチェックを適用するには、 CAMOによって保護されたトランザクションを、暗黙的なトランザクション制御を備えた単一のステートメントにすることはできません。また、 CAMOは、トランザクション制御プロシージャ、またはトランザクションを開始または終了しようとする\ ``DO`` ブロックで使用することはできません。 - CAMOはコミットステータスを解決しますが、コミット時の保留中の通知を解決しません。 CAMO、 ``NOTIFY`` SQLコマンドまたは\ ``pg_notify()`` ファンクションは許可されていません。 ``LISTEN`` または\ ``UNLISTEN`` も許可されません。 - 変更を再生するときに、 CAMOトランザクションは他のトランザクションと同様に競合を検出する場合があります。タイムスタンプ競合検出が使用される場合、 CAMOトランザクションは、プリペアオンザオリジンノードのタイムスタンプを使用します。これは、トランザクションがオリジンノード自分自身で可視される前です。 - CAMOは現在トランザクションストリーミングと互換性がありません。 CAMOを使用する予定がある場合は、必ずトランザクションストリーミングを無効にしてください。このオプションはグローバルにまたはPGDノードグループで構成できます。 :ref:`Transaction streaming configuration ` を参照してください。 - CAMOは現在デコードワーカーと互換性がありません。 CAMOを使用する予定がある場合は、デコードワーカーを有効にしないようにしてください。このオプションはPGDノードグループで構成できます。 :ref:`Decoding worker disabling ` を参照してください。 - CAMOを使用する場合、すべてのDDLを実行できるわけではありません。サポートされていないDDLを使用する場合、警告がログに記録され、トランザクションのコミットスコープはローカルのみに設定されます。サポートされているDDL操作は次のとおりです。 - 非コンカレント ``CREATE INDEX`` - 非コンカレント ``DROP INDEX`` - 個々のテーブルまたはインデックスの非コンカレント\ ``REINDEX`` - ``CLUSTER`` 単一のリレーションまたはインデックスのみ - ``ANALYZE`` - - - - - - 明示的な2フェーズコミットは、既に2フェーズコミットを使用しているため、 CAMOではサポートされていません。 - CAMOトランザクションのみを\ ``DEGRADE TO`` 句と組み合わせて、可用性が低下した場合に非同期オペレーションに切り替えることができます。 混合PGDバージョン ^^^^^^^^^^^^^^^^^ PGDは、アップグレードプロセス中にPGDの混合バージョンが動作できるようにすることにより、 :ref:`enable rolling upgrades of PGD ` に開発されました。 私たちは、ユーザーがアップグレード中にのみ混合バージョンを実行し、アップグレードが開始されたら、そのアップグレードを完了することを想定しています。アップグレード時を除き、PGDの混合バージョンの実行はサポートされていません。 その他の制限 ^^^^^^^^^^^^ この非包括的なリストには、予想されるデザインによる他の制限が含まれています。将来的にそれらを解決する予定はありません。 展開を計画するときは、次の制限を考慮してください。 - ``galloc`` シーケンスは、ロールバックしたトランザクションでシーケンスを作成し、同じ名前で再度作成する場合、一部のチャンクをスキップする場合があります。チャンクのスキップは、 DDLレプリケーションがアクティブでないときにシーケンスを作成して削除し、 DDLレプリケーションがアクティブなときに再度作成する場合にも発生する可能性があります。順序保証に違反しないため、問題の影響は軽度です。シーケンスは、一部の最初のチャンクのみをスキップします。また、回避策として、シーケンスの開始値を\ ``bdr.alter_sequence_set_kind()`` ファンクションの引数として指定できます。