postgresql.conf

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 と同じですが、構成をデータディレクトリとは別にしておきたい場合は、別の場所に設定できます。

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

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_conf_settings#

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

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

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 に追加できます。

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

Postgresログ#

デフォルトのログファイルは/var/log/postgres/postgres.log として定義されます。それを変更する必要がある場合は、config.ymlでpostgres_log_fileを設定できます。

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

TPAはディレクトリの作成を担当し、必要に応じてログをローテーションします。

SSL構成#

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

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

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

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

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によって調整されます。

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"

注釈

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

手動で変更を加える#

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

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

#  ALTER SYSTEM SET bdr.global_lock_statement_timeout TO 60s;

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

$ 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 を設定できます。

cluster_vars:
  postgres_conf_template: pgconf.j2

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

目次