postgresql.conf
===============

TPAは、その下にさまざまな\ ``.conf`` ファイルを含む\ ``conf.d``
ディレクトリを作成し、メイン ``postgresql.conf`` の\ ``include_dir``
を使用してこれらの追加構成ファイルを使用します。

Postgres構成ファイルpostgresql.conf、pg_ident.conf、およびpg_hba.confおよび\ ``conf.d``
の下のインクルードファイルは、常に\ ``postgres_conf_dir``
に保存されます。これはデフォルトで\ ``postgres_data_dir``
と同じですが、構成をデータディレクトリとは別にしておきたい場合は、別の場所に設定できます。

主な構成メカニズムは、変数を直接設定することです。

.. code:: yaml

   cluster_vars:
     temp_buffers: 16MB
     log_connections: on
     autovacuum_vacuum_cost_limit: -1
     effective_cache_size: 4GB
     max_connections: 300
     max_wal_senders: 32

TPAは、構成を複数のファイルに分割します。
2つのメインファイルは、\ ``0000-tpa.conf``
および\ ``0001-tpa_restart.conf``
です。これらには、それぞれサーバーのリロードまたは再起動を必要とする設定が含まれています。展開中に、TPAは正しいファイルに変更を書き込み、必要に応じてPostgresをリロードまたは再起動します。

TPAは、特定の状況オプションの拡張機能を構成する場合などに他のファイルを使用する場合がありますが、通常、特定のパラメーターが正確にどこに設定されているかを気にする必要はありません。

次回\ ``tpaexec deploy``
を実行したときに変更が上書きされる可能性があるため、 ``conf.d``
の下のファイルは決して編集しないでください。

postgres_port
-------------

Postgresポートは、デフォルト値から別の有効なポート番号に上書きできます。

.. code:: yaml

   cluster_vars:
     postgres_port: 5433

``postgres_port``
は、値が正しく共有され、この値に依存するすべてのコンポーネントで使用されることを保証ため、
``postgres_conf_settings`` を介してポートを設定するよりも優先されます。

postgres_conf_settings
----------------------

TPAは、多くの使用可能なpostgresql.conf設定すべてではありませんが、直接設定できる\ ``temp_buffers``
や\ ``maintenance_work_mem`` のような変数を提供します。

``postgres_conf_settings``
を使用して、TPAで認識されるかどうかにかかわらず、パラメーターを設定できます。
``postgresql.conf``
に表示されるのとまったく同じように値を引用符で囲む必要があります。

.. code:: yaml

   cluster_vars:
     effective_cache_size: 2GB
     postgres_conf_settings:
       effective_cache_size: 4GB
       authentication_timeout: 1min
       synchronous_standby_names: >-
         any 2 ("first", "second", "third")
       bdr.global_lock_statement_timeout: 60s

これは、TPAがネイティブに認識しない設定で最も役立ちますが、任意のパラメーターに使用できますたとえば、
``effective_cache_size``
は変数として設定できますが、\ ``authentication_timeout`` はできません。

これらの設定は\ ``conf.d/9900-role-settings.conf``
に書き込まれるため、他の方法で設定された変数より優先されます。

``postgres_conf_settings``
の下の値を変更した場合、TPAは、リロードが変更を有効にするのに十分であるかどうか、または再起動が必要かどうかを知る方法がありません。したがって、常にサーバーを再起動して変更をアクティブにします。これが、可能な場合は常に変数を直接使用することをお勧めする理由です。

shared_buffers
--------------

デフォルトでは、TPAは\ ``shared_buffers``
を使用可能なメモリの25%に設定しますこれは単なる経験則であり、推奨ではありません。別の比率を使用するように\ ``shared_buffers_ratio: 0.35``
を設定するか、\ ``shared_buffers_mb: 796``
を特定のMB数に設定するか、\ ``shared_buffers: "2GB"``
などの正確な値を直接指定することにより、このデフォルトをオーバーライドできます。

effect_cache_size
-----------------

デフォルトでは、TPAは\ ``effective_cache_size``
を使用可能なメモリの50%に設定します。別の比率を使用するように\ ``effective_cache_size_ratio: 0.35``
を設定するか、\ ``effective_cache_size_mb: 796``
を特定のMB数に設定するか、\ ``effective_cache_size: "8GB"``
などの正確な値を直接指定することにより、このデフォルトをオーバーライドできます。

shared_preload_libraries
------------------------

TPAは、動作するために\ ``shared_preload_libraries``
のエントリを必要とする拡張機能の内部リストを維持しており、このような拡張機能を\ ``postgres_extensions``
に含めると、\ ``shared_preload_libraries`` が自動的に更新されます。

プリロードが必要な認識されない拡張機能を使用している場合は、\ ``preload_extensions``
に追加できます。

.. code:: yaml

   cluster_vars:
     preload_extensions:
     - myext
     - otherext

``myext`` を\ ``postgres_extensions``
に追加すると、\ ``shared_preload_libraries`` には\ ``myext``
が含まれます。

デフォルトでは、\ ``conf.d/8888-shared_preload_libraries.conf``
に\ ``shared_preload_libraries`` が設定されます。

``shared_preload_libraries``
を変数として直接設定することはサポートされていません。通常は設定する必要はありませんが、やむを得ない場合は、
:ref:`postgres_conf_settings <postgres_conf_settings>` の下に完全に引用符で囲まれた値を設定できます。この場合、値は\ ``conf.d/9900-tpa_postgres_conf_settings.conf``
に設定されます。

Postgresロギング
----------------

デフォルトでは、TPAはPostgres ``log_destination`` GUCを\ ``syslog``
として構成し、Postgresログを\ ``/var/log/postgres/postgres.log``
に書き込むようにrsyslogを構成します。

次のクラスター変数を使用して、これらのデフォルトを変更できます。

- ``postgres_log_file``
  は、ログファイルへのパスです。デフォルト\ ``/var/log/postgres/postgres.log``

- ``postgres_log_file_mode``
  は、ログファイルのモードです。デフォルト\ ``0640``

- ``postgres_log_directory_mode``
  は、ログディレクトリのモードです。デフォルト\ ``0700``

- ``log_destination`` は、同じ名前のPostgres GUCを設定します。
  デフォルト\ ``syslog``

- ``logging_collector`` は、同じ名前のPostgres GUCを設定します。
  ``log_destination`` が\ ``syslog`` の場合はデフォルト\ ``off``
  、それ以外の場合は\ ``on`` 。

``syslog`` 以外の\ ``log_destination``
を選択すると、TPAはログを書き込むようにPostgresロギングコレクターを設定します。すべての場合、TPAはディレクトリの作成とログローテーションの構成を行います。

次の例は、 ``rsyslog``
を使用して選択した場所にログを記録するようにTPAに指示します。

.. code:: yaml

   cluster_vars:
     [...]
     postgres_log_file: /srv/fantastic_logs/pg_server.log

この例では、ログは同じ場所にありますが、
Postgresロギングコレクターを使用してJSONログを書き込み、グループメンバーのログディレクトリでの読み取りと実行を許可しています。

.. code:: yaml

   cluster_vars:
     [...]
     postgres_log_file: /srv/fantastic_logs/pg_server.log
     postgres_log_directory_mode: 0750
     log_destination: jsonlog

..  Note File extensions for log files::
   `log_destination` が`syslog` または`stderr` の場合、 `postgres_log_file` の正確な値が拡張子を含む現在のログファイルに使用されます。 `log_destination` が`jsonlog` または`csvlog` の場合、指定された`postgres_log_file` には`.json` または`.csv` が追加されます。指定された`postgres_log_file` に`.log` が含まれていた場合、削除されます。この動作は `Postgres <https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-FILENAME>`_ からのものです

TPAからではなく。

最終的な拡張子を含むログファイルの正確なパスにアクセスする必要がある場合たとえばフックの一部として、これはAnsibleファクト\ ``postgres_log_file_with_extension``
に保存されます。直接設定することはできません。

.. ::
   ## SSL構成

デフォルトでは、TPAはプライベートキーと自己署名TLS証明書を生成します。これらはPostgresがそれぞれ\ ``ssl_key_file``
および\ ``ssl_cert_file``
として使用します。ファイルはTPAクラスター名\ ``cluster_name.key``
および\ ``cluster_name.crt`` を使用して名前付けられ、\ ``/etc/tpa``
にあります。その結果、\ ``0001-tpa_restart.conf``
では次のデフォルト構成になります。

.. code:: ini

   ssl_key_file=/etc/tpa/cluster_name.key
   ssl_cert_file=/etc/tpa/cluster_name.crt

これは、クライアントとサーバー間のトラフィックが転送中に暗号化されることを保証には十分です。

独自の証明書を提供するには、証明書をターゲットノードに :ref:`Uploading artifacts <Uploading artifacts>` 
としてアップロードし、次のクラスター変数を指定してパスを設定します。

.. code:: yaml

   cluster_vars:
     ...
     artifacts:
     - type: file
       dest: /path/to/your_key.key
       src: /local/path/to/your_key.key
       owner: root
       group: root
       mode: "0644"
     - type: file
       dest: /path/to/your_cert.crt
       src: /local/path/to/your_cert.crt
       owner: root
       group: root
       mode: "0600"
     ssl_key_file: /path/to/your_key.key
     ssl_cert_file: /path/to/your_cert.crt

または、キーと証明書をデフォルトの場所にアップロードすると、TPAは独自の生成の代わりにそれらを使用し、
``ssl_key_file`` または\ ``ssl_cert_file``
を指定する必要はありません。ただし、 ``/etc/tpa``
は、アーティファクトのアップロード時に存在しないため、明示的に作成する必要があることに注意してください。これらのファイルの権限と所有権は、展開中に\ ``postgres``
ユーザーが作成されるときにTPAによって調整されます。

.. code:: yaml

   cluster_vars:
     ...
     artifacts:
     - type: path
       path: /etc/tpa
       state: directory
       owner: root
       group: root
       mode: "0755"
     - type: file
       dest: /etc/tpa/cluster_name.key
       src: /local/path/to/your_key.key
       owner: root
       group: root
       mode: "0644"
     - type: file
       dest: /etc/tpa/cluster_name.crt
       src: /local/path/to/your_cert.crt
       owner: root
       group: root
       mode: "0600"

..  Note Other SSL settings::
   TPAは、デフォルトでは`ssl_ca_file` または`ssl_crl_file` を指定しません。これらのファイルを自分自身で提供するには、 :ref:`Uploading artifacts <Uploading artifacts>` を使用し、同じ名前のクラスター変数を指定します。

.. ::
   ## 手動で変更を加える

TPAで生成された構成をオーバーライドするには2つの方法があります。

最初のおよび推奨されるオプションは、\ ``ALTER SYSTEM``
を使用することです。これは、常に構成ファイルのすべてより優先されます。

.. code:: sql

   ALTER SYSTEM SET bdr.global_lock_statement_timeout TO 60s;

``conf.d/9999-override.conf`` を編集することもできます。

.. code:: shell

   echo "bdr.global_lock_statement_timeout=60s" >> conf.d/9999-override.conf

``conf.d``
の下の他のすべてのファイルは、展開中に構成が変更された場合に上書きされる可能性がありますが、TPAは、最初に空のファイルを作成した後、\ ``9999-override.conf``
を変更することはありません。

変更する設定によっては、\ ``SELECT pg_reload_conf()``
を実行するか、サーバーを再起動して変更を有効にする必要がある場合があります。

postgresql.confをスクラッチから生成する
---------------------------------------

デフォルトでは、TPAは\ ``include_dir``
を追加する以外に、デフォルトの\ ``initdb``
生成されたpostgresql.confファイルをそのまま残します。通常、この動作をオーバーライドする必要はありませんが、そうするように\ ``postgres_conf_template``
を設定できます。

.. code:: yaml

   cluster_vars:
     postgres_conf_template: pgconf.j2

これで、クラスターディレクトリの\ ``templates/pgconf.j2``
を使用してpostgresql.confが生成されます。
