Postgres configuration
======================

いくつかのPostgres構成パラメーターはPGDノードに影響を与えます。ノードごとにこれらのパラメーターを異なるように設定できますが、一般的にはお勧めしません。

PGD独自の設定については、 
`PGD settings reference <https://www.enterprisedb.com/docs/pgd/latest/reference/tables-views-functions/pgd-settings>`_ を参照してください。

Postgres設定
------------

PGDを正しく実行するには、次のPostgres設定が必要です。

- ``wal_level`` - PGDは論理デコードに依存しているため、 ``logical``
  に設定する必要があります。

- ``shared_preload_libraries`` - 拡張機能を有効にするには\ ``bdr``
  を含める必要があります。他のほとんどの拡張機能は、コンマ区切りリストの\ ``bdr``
  エントリーの前後に表示できます。このリストには\ ``pglogical``
  を含めないでください。

- ``track_commit_timestamp`` -
  競合する各行のタイムスタンプを取得するには、競合解決のために\ ``on``
  に設定する必要があります。

PGDでは、これらのPostgreSQL設定を適切な値に設定する必要があります。これは、クラスターのサイズとスケールによって異なります。

- ``logical_decoding_work_mem`` -
  論理デコードによって使用されるメモリバッファサイズ。このサイズよりも大きいトランザクションはバッファをオーバーフローし、ローカルディスクに一時的に保存されます。デフォルトは64MBですが、かなり高く設定できます。

- ``max_worker_processes`` -
  PGDはレプリケーションとメンテナンスタスクにバックグラウンドワーカーを使用するため、正しく動作するには十分なワーカースロットが必要です。各データベースのワーカーの正しい最小数の式は、次の値を合計することです。

- PostgreSQLインスタンスごとに1つ

- そのインスタンスのデータベースごとに1つ

- PGD対応データベースごとに4つ

- PGDグループのピアノードごとに1つ

- ピアノードの数 回the (ライターの数bdr.num_writers)プラス1
  ノードがPGDグループから削除されるときに、一時的により多くのワーカープロセスが必要になる場合があります。

- ``max_wal_senders`` - 各ピアノードに2つ必要です。

- ``max_replication_slots`` - 各ピアノードに2つ必要です。

- ``max_active_replication_origins`` - 各ピアノードに3つ必要です。
  PostgreSQL 18以降で利用できます。

- ``wal_sender_timeout`` および\ ``wal_receiver_timeout`` -
  通常はデフォルトの1分で十分ですが、大規模なトランザクションの場合、処理にこの時間よりも長い時間が必要になる場合があります。
  WAL送信者は、待機しているレプリケーション接続に送信する前に、トランザクションのフルサイズを処理する必要があるため、Postgresはそれをタイムアウトとして認識できます。問題が実際に大規模なトランザクションによるものである場合は、wal_sender_timeoutを\ ``3600s``
  以上のような高い値に引き上げ、サーバーをリロードすることにより問題が解決される可能性があります。さらに、この設定は、ノードがCAMOパートナーを切断または再接続したとみなすまでの時間を決定します。詳細は、
  :ref:`CAMO failure scenarios <Commit At Most Once>` を参照してください。

N個のピアノードを持つグループの通常の実行では、PGDにはN個のスロットとWAL送信機が必要です。同期中に、PGDは別のN-1スロットとWALセンダーを一時的に使用するため、この時折のピーク要求に十分な高いパラメーターを設定するように注意してください。

Parallel
applyがオンの場合、スロット数はフォーミュラ*ライターからNスロットに増やす必要があります。これは、
``max_replication_slots`` もレプリケーションオリジンの最大数を設定し、
Parallel
applyの一部の機能はライタごとに追加のオリジンを使用するためです。

:ref:`Decoding worker <Decoding worker>` が有効になっている場合、このプロセスにはPGDグループごとに1つの追加のレプリケーションスロットが必要です。

``max_worker_processes`` 、\ ``max_wal_senders``
、および\ ``max_replication_slots``
パラメーターを変更するには、ローカルノードを再起動する必要があります。

古い同期レプリケーションモードは、次のパラメーターを使用してサポートされています。詳細と制限については、
:ref:`コミットスコープへの移行 <コミットスコープへの移行>` を参照してください。

- ``synchronous_commit`` および\ ``synchronous_standby_names`` -
  PGDレプリケーションの耐久性とパフォーマンスに影響します。
  `physical replication <https://www.postgresql.org/docs/11/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT>`_  と同様の方法。

準備されたトランザクションの最大数
----------------------------------

max_prepared_transactions
^^^^^^^^^^^^^^^^^^^^^^^^^

明示的な2フェーズコミット、
CAMO、またはEagerトランザクションのため、クラスター全体で同時に準備されたトランザクションの最大数に対処するために十分に高く設定する必要があります。制限を超過すると、ノードはローカル2フェーズコミットまたはCAMOトランザクションを実行できず、クラスター上のすべてのEagerトランザクションを防止します。このパラメーターは、Postgresサーバーの起動時にのみ設定できます。

グローバル構成に関する考慮事項
------------------------------

特定のPostgreSQL構成パラメーターはスタンドアロンインスタンスに役立ちますが、
PGDクラスターの安定性、バックグラウンドワーカー、およびレプリケーションプロセスに悪影響を与える可能性があります。

次のパラメーターは、\ ``postgresql.conf``
でグローバルに有効にしたり、PGDノードデータソース名DSNにオプションとして含めたりする必要はありません。

- ``idle_session_timeout``

- ``transaction_timeout``

代わりに、これらのパラメーターをセッションごとに設定して、システムレベルの操作を干渉しないことを確認します。
