PostgreSQL設定¶

PostgreSQLに精通しているユーザーは、インスタンスを構成するための次の2つのファイルの存在を認識しています。

postgresql.conf ：PostgreSQLのメイン実行時構成ファイル
pg_hba.conf ：クライアント認証ファイル

PostgreSQLコンテナの宣言的構成と不変性の概念により、ユーザーはこれらのファイルに直接触れることはできません。 parameters およびpg_hba キーを介してカスタムpostgresql.conf およびpg_hba.conf 設定を定義することにより、 Cluster リソース定義のpostgresql セクションを介して構成できます。

これらの設定は、すべてのインスタンスで同じです。

警告

ALTER SYSTEM クエリを使用して、PostgreSQLインスタンスの構成を命令的な方法で変更しないでください。通常オペレーターによって制御されるオプションのいくつかを変更すると、実際にクラスターの予測不能/回復不能な状態につながる可能性があります。さらに、 ALTER SYSTEM の変更はクラスター全体に複製されません。

カスタム設定の使用法のリファレンスは、サンプルに含まれています。を参照してください。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-custom
spec:
  instances: 3

  # Parameters and pg_hba configuration will be append
  # to the default ones to make the cluster work
  postgresql:
    parameters:
      max_worker_processes: "60"
    pg_hba:
      # To access through TCP/IP you will need to get username
      # and password from the secret cluster-example-custom-app
      - host all all all md5

  # Example of rolling update strategy:
  # - unsupervised: automated update of the primary once all
  #                 replicas have been upgraded (default)
  # - supervised: requires manual supervision to perform
  #               the switchover of the primary
  primaryUpdateStrategy: unsupervised

  # Require 1Gi of space per instance using default storage class
  storage:
    size: 1Gi

。

`postgresql` セクション¶

ポッド内のPostgreSQLインスタンスは、デフォルトのpostgresql.conf ファイルで起動します。このファイルには、次の設定が自動的に追加されます。

listen_addresses = *
include custom.conf

custom.conf ファイルには、次の例のように、 postgresql セクションのユーザー定義設定が含まれます。

# ...
postgresql:
  parameters:
    shared_buffers: "1GB"
# ...

custom.conf の内容は、次のセクションをこの順序で適用することにより、オペレーターによって自動的に生成および維持されます。

グローバルデフォルトパラメーター
PostgreSQLメジャーバージョンに依存するデフォルトパラメーター
ユーザー指定のパラメーター
固定パラメーター

グローバルデフォルトパラメーター は次のとおりです。

dynamic_shared_memory_type = posix
logging_collector = on
log_destination = csvlog
log_directory = /controller/log
log_filename = postgres
log_rotation_age = 0
log_rotation_size = 0
log_truncate_on_rotation = false
max_parallel_workers = 32
max_replication_slots = 32
max_worker_processes = 32
shared_memory_type = mmap # for PostgreSQL >= 12 only
wal_keep_size = 512MB # for PostgreSQL >= 13 only
wal_keep_segments = 32 # for PostgreSQL <= 12 only
wal_sender_timeout = 5s
wal_receiver_timeout = 5s

警告

PostgreSQLクラスターでのWALセグメントの保持を計画し、予想および観察されたワークロードに基づいて、サーバーバージョンに応じて、 wal_keep_size または`wal_keep_segments` を適切に構成することはあなたの義務です。

または、ストリーミングレプリケーションクライアントのみが高可用性クラスターで実行されているレプリカインスタンスである場合、レプリケーションスロット機能を利用できます。これにより、クラスターレベルでレプリケーションスロットのサポートが追加されます。 replicationSlots.highAvailability オプションでこの機能を有効にできます（詳細については、 ReplicationSlotsConfiguration を参照してください）。

レプリケーションスロットも連続バックアップも配置されていない場合、 wal_keep_size またはwal_keep_segments を構成することが、スタンバイの同期が失われるのを防ぐ唯一の方法です。スタンバイが同期しなくなると、次のようなエラーメッセージが生成されます。"could not receive data from WAL stream: ERROR: requested WAL segment **** **** **** **** **** **** has already been removed" 。これには、ストリーミングレプリケーションの目的で古いWALセグメントを保持するために、 PGDATA の一部、またはWALファイルの保存専用のボリュームを専用にする必要があります。

次のパラメーターは固定され、オペレーターによって排他的に制御されます。

archive_command = /controller/manager wal-archive %p
archive_mode = on
full_page_writes = on
hot_standby = true
listen_addresses = *
port = 5432
restart_after_crash = false
ssl = on
ssl_ca_file = /controller/certificates/client-ca.crt
ssl_cert_file = /controller/certificates/server.crt
ssl_key_file = /controller/certificates/server.key
unix_socket_directories = /controller/run
wal_level = logical
wal_log_hints = on

固定パラメーターは最後に追加されるため、YAML構成を介してユーザーがオーバーライドすることはできません。これらのパラメーターは、正しいWALアーカイブとレプリケーションに必要です。

レプリケーション設定¶

primary_conninfo 、 restore_command 、および recovery_target_timeline パラメーターは、クラスター内のインスタンスの状態に応じて、オペレーターによって自動的に管理されます。

primary_conninfo = host=cluster-example-rw user=postgres dbname=postgres
recovery_target_timeline = latest

ログ制御設定¶

オペレーターはPostgreSQLにCSV形式でログを出力することを要求し、インスタンスマネージャーは自動的に解析してJSON形式で出力します。このため、PostgreSQLのすべてのログ設定は固定されており、変更できません。

詳細については、ロギングを参照してください。

共有プリロードライブラリ¶

PostgreSQLのshared_preload_libraries オプションは、サーバーの起動時にプリロードする1つ以上の共有ライブラリをコンマ区切りのリストの形式で指定するために存在します。通常、PostgreSQLで使用され、システム全体のほとんどのデータベースセッションで利用できる必要がある拡張機能をロードします（例、 pg_stat_statements ）。

CloudNativePGでは、 shared_preload_libraries オプションはデフォルトで空です。 shared_preload_libraries のコンテンツをオーバーライドできますが、専門のPostgresユーザーのみがこのオプションを利用することをお勧めします。

重要

指定されたライブラリが見つからない場合、サーバーは起動に失敗し、CloudNativePGは自己修復の試行を妨げ、手動介入が必要になります。 shared_preload_libraries のコンテンツを直接管理する予定がある場合は、 shared_preload_libraries の拡張機能と設定の両方を常にテストしてください。

CloudNativePGは、最も使用されているPostgreSQL拡張機能のいくつかのshared_preload_libraries オプションのコンテンツを自動的に管理できます（詳細については、以下のマネージド拡張機能セクションを参照してください）。

具体的には、オペレーターは、構成パラメーターがマネージドライブラリのいずれかを必要とすることに気付くとすぐに、必要なライブラリを自動的に追加します。オペレーターは、実際のパラメーターがそれを必要としないとすぐに、ライブラリを削除します。

重要

shared_preload_libraries からライブラリを削除するには、有効にするにはクラスター内のすべてのインスタンスを再起動する必要があることに常に注意してください。

.spec.postgresql.shared_preload_libraries を介して、文字列のリストとして追加のshared_preload_libraries を提供できます。オペレーターは、それらを自動的に管理するものとマージします。

マネージド拡張機能¶

前のセクションで予想されたように、CloudNativePGは、いくつかのよく知られてサポートされている拡張機能のshared_preload_libraries のコンテンツを自動的に管理します。現在のリストには以下が含まれます。

auto_explain
pg_stat_statements
pgaudit
pg_failover_slots

これらのライブラリの一部は、使用する前にデータベース内の追加オブジェクトを必要とします。通常、データベースで実行するCREATE EXTENSION コマンドで管理されるビューおよび/または関数（ DROP EXTENSION コマンドは通常、これらのオブジェクトを削除します）。

このようなライブラリの場合、CloudNativePGは、次のクエリで識別される、クラスター内の接続を受け入れるすべてのデータベースでの拡張機能の作成と削除を自動的に処理します。

SELECT datname FROM pg_database WHERE datallowconn

注釈

上記のクエリには、 template1 のようなテンプレートデータベースも含まれています。

`auto_explain` を有効にする¶

:ref:``auto_explain` を有効にする<auto_explain を有効にする>`

拡張機能は、 EXPLAIN （最適化されていないクエリを追跡するのに役立ちます）を手動で実行せずに、遅いステートメントの実行計画を自動的にログに記録する手段を提供します。

次の例の抜粋（完了するまでに10秒以上かかるクエリの実行計画を自動的にログに記録します）のように、 auto_explain. で始まるパラメーターを構成に追加することにより、 auto_explain を有効にできます。

# ...
postgresql:
  parameters:
    auto_explain.log_min_duration: "10s"
# ...

注釈

auto_explainを有効にすると、パフォーマンスの問題が発生する可能性があります。 the auto explain documentation を参照してください

`pg_stat_statements` を有効にする¶

:ref:``pg_stat_statements` を有効にする<pg_stat_statements を有効にする>`

拡張機能は、クエリのリアルタイムモニタリングのためにPostgreSQLで利用できる最も重要な機能の1つです。

次の抜粋例のように、 pg_stat_statements. で始まるパラメーターを構成に追加することにより、pg_stat_statements を有効にできます。

# ...
postgresql:
  parameters:
    pg_stat_statements.max: "10000"
    pg_stat_statements.track: all
# ...

前述のように、オペレーターはpg_stat_statements をshared_preload_libraries に自動的に追加し、各データベースでCREATE EXTENSION IF NOT EXISTS pg_stat_statements を実行し、 pg_stat_statements ビューに対してクエリを実行できるようにします。

`pgaudit` を有効にする¶

pgaudit 拡張機能は、標準のPostgreSQLロギング機能を介して、詳細なセッションおよび/またはオブジェクト監査ロギングを提供します。

CloudNativePGは、PostgreSQLクラスターでの PGAuditログを透過的かつネイティブにサポートしています。詳細については、: PGAuditログを参照してください

次の抜粋例のように、 pgaudit. で始まるパラメーターを構成に追加することにより、pgaudit を有効にできます。

#
postgresql:
  parameters:
    pgaudit.log: "all, -misc"
    pgaudit.log_catalog: "off"
    pgaudit.log_parameter: "on"
    pgaudit.log_relation: "on"
#

`pg_failover_slots` を有効にする¶

:ref:``pg_failover_slots` を有効にする<pg_failover_slots を有効にする>`

EDBによる拡張により、論理レプリケーションスロットがフェールオーバーシナリオに耐えられることが保証されます。フェールオーバーは通常、CloudNativePGの場合のように、物理ストリーミングレプリケーションを使用して実装されます。

pg_failover_slots. で始まるパラメーターを構成に追加することにより、pg_failover_slots を有効にできます。上記で説明したように、オペレーターはこれに応じてshared_preload_libraries オプションのpg_failover_slots エントリーを透過的に管理します。

状態の同期を参照してください

この拡張機能の詳細については。

さらに、 pg_failover_slots で使用する予定のデータベースごとに、各レプリカがプライマリに接続できるようにするエントリーをpg_hba セクションに追加する必要があります。たとえば、 pg_failover_slots でapp データベースを使用する場合は、 pg_hba セクションにこのエントリを追加する必要があります。

postgresql:
  pg_hba:
    - hostssl app streaming_replica all cert

`pg_hba` セクション¶

pg_hba は、ポッドで使用されるpg_hba.conf の作成に使用されるPostgreSQLホストベースの認証ルールのリストです。

最初の一致ルールが認証に使用されるため、オペレーターによって生成されたpg_hba.conf ファイルは、4つのセクションで構成されていると見ることができます。

1.固定ルール

2.ユーザー定義ルール

3.オプションのLDAPセクション

4.デフォルトルール

固定ルール：

local all all peer

hostssl postgres streaming_replica all cert
hostssl replication streaming_replica all cert

デフォルトのルール:

host all all all <default-authentication-method>

PostgreSQL 14から、 password_encryption データベースパラメーターのデフォルト値はscram-sha-256 に設定されます。そのため、このPostgreSQLバージョンからデフォルトの認証方法はscram-sha-256 です。

PostgreSQL 13以前では、デフォルトの認証方法としてmd5 が使用されます。

結果のpg_hba.conf は次のようになります。

  local all all peer

  hostssl postgres streaming_replica all cert
  hostssl replication streaming_replica all cert

  <user defined rules>
  <user defined LDAP>

  host all all all scram-sha-256 # (or md5 for PostgreSQL version <= 13)

`more information on `pg_hba.conf` <https://www.postgresql.org/docs/current/auth-pg-hba-conf.html>`__  については、PostgreSQLのドキュメントを参照してください。

クラスターマニフェスト内で、次の抜粋に示すように、 pg_hba 行がspec.postgresql.pg_hba のリスト項目として追加されます。

postgresql:
  pg_hba:
    - hostssl app app 10.244.0.0/16 md5

上記の例では、 app ユーザーがMD5パスワード認証（必要に応じてscram-sha-256 を使用できます）を使用して、安全なチャネル（hostssl ）を介してapp データベースへのアクセスを有効にしています。

LDAP構成¶

クラスター仕様のpostgres セクションの下には、 pg_hba.conf ファイルに追加されるルールに変換されるLDAP構成を定義するために使用可能なオプションのldap セクションがあります。

これは2つのモードをサポートします。LDAPセクションで server 、prefix 、およびsuffix を指定する必要があるsimple bind モードと、server 、baseDN 、binDN 、およびシークレットであるldapパスワードを含むbindPassword を指定する必要があるsearch+bind モード。さらに、 search+bind モードでは、 searchFilter またはsearchAttribute を指定するオプションがあります。 searchAttribute が指定されない場合、 uid のデフォルトが使用されます。

さらに、どちらのモードでも、 ldapschemeのscheme とport を指定できます。ただし、スキームもポートも必要ありません。

search+bindで入力されたこのセクションは、次のようになります。

postgresql:
  ldap:
    server: openldap.default.svc.cluster.local
    bindSearchAuth:
      baseDN: ou=org,dc=example,dc=com
      bindDN: cn=admin,dc=example,dc=com
      bindPassword:
        name: ldapBindPassword
        key: data
      searchAttribute: uid

構成の変更¶

Cluster リソースのpostgresql セクションを編集して、構成の変更を適用できます。

変更後、クラスターインスタンスはすぐに構成をリロードして変更を適用します。変更に再起動が必要なパラメーターが含まれる場合、オペレーターはローリングアップグレードを実行します。

動的共有メモリの設定¶

PostgreSQLは、: dynamic_shared_memory_type を介した動的共有メモリ管理のいくつかの実装をサポートしています

構成オプション。 CloudNativePGでは、次の2つの値のいずれかに自分自身を制限することをお勧めします。

posix ： shm_open を使用して割り当てられたPOSIX共有メモリに依存します（デフォルト設定）
sysv ：shmget を介して割り当てられたSystem V共有メモリに基づいています

PostgreSQLでは、この設定は並列クエリでのメモリ割り当てにとって特に重要です。詳細はこちら: thread from the `pgsql-general mailing list <https://www.postgresql.org/message-id/CA%2BhUKGJOj7qzDLxeFPVvto8YEWop6FSQoTYPO9Z6Ee%3Di-nPS_Q%40mail.gmail.com>`__ を参照してください。

POSIX共有メモリ¶

オペレーターが/dev/shm の下のshm と呼ばれる メモリバインドの``EmptyDir``ボリューム を自動的にマウントすることを考慮すると、ほとんどの場合、 posix のデフォルト設定で十分です。次のように、実行中のPostgresコンテナ内のそのようなボリュームのサイズを確認できます。

mount | grep shm

次の出力のようなものが得られるはずです。

shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size= **** **)

System V共有メモリ¶

Kubernetesクラスターの SHMMAX および SHMALL パラメーターの値が十分に高い場合、以下を設定することもできます。

dynamic_shared_memory_type: "sysv"

次を実行して、PostgreSQLコンテナ内からSHMMAX /SHMALL を確認できます。

ipcs -lm

例：

- ----- Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 18014398509465599
max total shared memory (kbytes) = 18014398509481980
min seg size (bytes) = 1

ご覧のとおり、非常に多数のmax total shared memory は、 dynamic_shared_memory_type をsysv に設定することを推奨しています。

別の方法は、次を実行することです。

cat /proc/sys/kernel/shmall
cat /proc/sys/kernel/shmmax

固定パラメーター¶

一部のPostgreSQL構成パラメーターは、オペレーターが排他的に管理する必要があります。オペレーターは、ユーザーがWebhookを使用して設定できないようにします。

ユーザーは、 postgresql セクションで次の構成パラメーターを設定することはできません。

allow_system_table_mods
archive_cleanup_command
archive_command
archive_mode
bonjour
bonjour_name
cluster_name
config_file
data_directory
data_sync_retry
event_source
external_pid_file
full_page_writes
hba_file
hot_standby
ident_file
jit_provider
listen_addresses
log_destination
log_directory
log_file_mode
log_filename
log_rotation_age
log_rotation_size
log_truncate_on_rotation
logging_collector
port
primary_conninfo
primary_slot_name
promote_trigger_file
recovery_end_command
recovery_min_apply_delay
recovery_target
recovery_target_action
recovery_target_inclusive
recovery_target_lsn
recovery_target_name
recovery_target_time
recovery_target_timeline
recovery_target_xid
restart_after_crash
restore_command
shared_preload_libraries
ssl
ssl_ca_file
ssl_cert_file
ssl_ciphers
ssl_crl_file
ssl_dh_params_file
ssl_ecdh_curve
ssl_key_file
ssl_max_protocol_version
ssl_min_protocol_version
ssl_passphrase_command
ssl_passphrase_command_supports_reload
ssl_prefer_server_ciphers
stats_temp_directory
synchronous_standby_names
syslog_facility
syslog_ident
syslog_sequence_numbers
syslog_split_messages
unix_socket_directories
unix_socket_group
unix_socket_permissions
wal_level
wal_log_hints

PostgreSQL設定¶

`postgresql` セクション¶

レプリケーション設定¶

ログ制御設定¶

共有プリロードライブラリ¶

マネージド拡張機能¶

`auto_explain` を有効にする¶

`pg_stat_statements` を有効にする¶

`pgaudit` を有効にする¶

`pg_failover_slots` を有効にする¶

`pg_hba` セクション¶

LDAP構成¶

構成の変更¶

動的共有メモリの設定¶

POSIX共有メモリ¶

System V共有メモリ¶

固定パラメーター¶

前のトピックへ

次のトピックへ

目次

PostgreSQL設定¶

postgresql セクション¶

レプリケーション設定¶

ログ制御設定¶

共有プリロードライブラリ¶

マネージド拡張機能¶

auto_explain を有効にする¶

pg_stat_statements を有効にする¶

pgaudit を有効にする¶

pg_failover_slots を有効にする¶

pg_hba セクション¶

LDAP構成¶

構成の変更¶

動的共有メモリの設定¶

POSIX共有メモリ¶

System V共有メモリ¶

固定パラメーター¶

`postgresql` セクション¶

`auto_explain` を有効にする¶

`pg_stat_statements` を有効にする¶

`pgaudit` を有効にする¶

`pg_failover_slots` を有効にする¶

`pg_hba` セクション¶