‘Known issues’

このセクションでは、 EDB Postgres Distributed 4の現在の既知の問題について説明します。

データの一貫性

競合の監視 について読んで、データの一貫性の観点からの非同期操作モードの影響を理解してください。

問題のリスト

これらの既知の問題はBDRのチケットシステムで追跡されており、将来のリリースで解決される予定です。

  • フェールオーバーとスイッチオーバー時間のHARPのパフォーマンスは、DCSノード間のレイテンシーに非線形に依存します。これが、複数のリージョン（通常はゴールドとプラチナのレイアウト）にわたるEDB Postgres分散デプロイの場合、 HARPにリージョンごとにetcdクラスターを使用することをお勧めします。 config.yml でharp_consensus_protocol オプションがetcd に設定されている場合、TPAexecはこれらのリージョンクラスターごとに実行するetcdを既に設定しています。

レイテンシーの高いネットワーク全体でのDCS展開では、 leader_lease_duration HARPオプション（TPAexecのharp_leader_lease_duration ）を増やすことをお勧めします。

  • update_origin_change 競合のリゾルバーがskip に設定され、synchronous_commit=remote_apply が使用され、同じ行の同時更新が2つの異なるノードに繰り返し適用される場合、 BDRライタでのデッドロックが原因で更新ステートメントがハングする場合があります。

    競合の監視 の章で述べたように、 skip

    はupdate_origin_change の競合のデフォルトのリゾルバーではなく、この組み合わせは実稼働での使用を想定していません。そのノードへの到着順に基づいて、2つの競合する更新の一方を破棄します。これにより、クラスターが発散する可能性があります。 skip 競合リゾルバーの使用を選択するまれな状況では、 remote_apply モードの使用に関する問題に注意してください。

  • デコーディングワーカー機能は、 CAMO/EAGER/Group Commitでは動作しません。 CAMO/Eager/Group Commitを使用したインストールでは、 enable_wal_decoder を無効にしておく必要があります。

  • Decoding Workerは、デフォルトのレプリケーションセットでのみ機能します。

  • ラグ制御は、完全に分離されたノード、つまり他のすべてのノードが到達不能または動作していない場合、コミット遅延を調整しません。少なくとも1つのノードが接続されるとすぐに、レプリケーションラグ制御が作業を取得し、 BDRコミット遅延を再度調整します。

  • 時間ベースのラグ制御の場合、 BDRは現在、履歴適用率に基づいた推定キャッチアップタイムではなく、ラグタイム（コミットタイムスタンプで測定）を使用します。

  • CAMOペアのCAMOパートナーを変更することは現在不可能です。ペアの追加・削除のみ可能です。ペアを追加または削除するには、Postgresの再起動や構成のリロードは必要ありません。

  • Group Commitは show-camo またはEager All Node replicationと組み合わせることはできません。 Eager Replicationは現在、「グローバル」なBDRコミットスコープを使用する場合にのみ機能します。

  • Eager ReplicationもGroup Commitもsynchronous_replication_availability = 'async' をサポートしていません。

  • Group Commitは、bdr.global_commit_timeout 後のコミットのタイムアウトをサポートしていません。

  • Eager Replicationを使用するトランザクションはまだDDLを実行できません。また、明示的な2フェーズコミットをサポートしていません。 TRUNCATEコマンドは許可されています。

  • CAMOまたはGroup Commitを使用すると、すべてのDDLを実行できるわけではありません。

  • Group Commitとの組み合わせでの並列適用は現在サポートされていません。 Group Commitを使用するときは、ノードグループに対して num_writers を1に設定するか（ bdr.alter_node_group_config を使用）、GUC bdr.writers_per_subscription を介して無効にしてください（

    Configuration of Generic Replication を参照）。

  • 現在、コミットスコープの変更または削除に対する保護はありません。同時に変更または削除されるコミットスコープでトランザクションを実行すると、トランザクションを適用しようとしているダウンストリームノードでエラーが発生したため、トランザクションがブロックまたはレプリケーションが完全に停止する可能性があります。特定のコミットスコープを使用するトランザクションは、変更または削除する前に完了していることを確認してください。

制限事項のリスト

これは、設計による予想される制限の（包括的ではない）リストです。将来的に解決される予定はありません。

  • ノードをフィジカルスタンバイに置き換えても、 CAMO/Eager/Group Commitを使用するノードでは機能しません。フィジカルスタンバイとBDRを組み合わせることは、一般的にはお勧めできません。

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

  • レガシーBDR同期レプリケーションは、 CAMO、Eager、およびGroup Commitで使用されるものとは異なるトランザクション確認のメカニズムを使用します。 2つは互換性がないため、一緒に使用しないでください。したがって、 synchronous_standby_names に表示されるノードは、 CAMO、 Eager 、またはGroup Commit構成の一部であってはなりません。ロジカルスタンバイとフィジカルスタンバイの両方を含む、他のノードへの同期レプリケーションを使用できます。