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 の変更はクラスター全体に複製されません。
- カスタム設定の使用法のリファレンスはサンプルに含まれています。
cluster-example-custom.yaml を参照してください。
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` を適切に構成することはあなたの義務です。 CloudNativePGがレプリケーションスロットをサポートするまで、そして継続的なバックアップを実施していない場合、これが現時点でスタンバイが同期しなくなって次のようなエラーメッセージを返す場合から保護する唯一の方法です。これには、 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 のコンテンツを直接管理する予定がある場合は、常に拡張機能と設定の両方をテストしてください。
CloudNativePGは、最も使用されているPostgreSQL拡張機能のいくつかのshared_preload_libraries
オプションのコンテンツを自動的に管理できます(詳細については、以下の マネージド拡張機能 セクションを参照してください)。
具体的には、オペレーターは、構成パラメーターがマネージドライブラリのいずれかを必要とすることに気付くとすぐに、必要なライブラリを自動的に追加します。オペレーターは、実際のパラメーターが必要としないとすぐにライブラリを削除します。
重要
shared_preload_libraries からライブラリを削除するには、クラスター内のすべてのインスタンスを再起動する必要があることに常に注意してください。
.spec.postgresql.shared_preload_libraries
を介して追加のshared_preload_libraries
を文字列のリストとして提供できます。オペレーターはそれらを自動的に管理するものとマージします。
マネージド拡張機能¶
前のセクションで予想されたように、CloudNativePGは、いくつかのよく知られているサポートされている拡張機能のshared_preload_libraries
のコンテンツを自動的に管理します。現在のリストには次のものが含まれます。
auto_explainpg_stat_statementspgaudit
これらのライブラリの中には、使用する前にデータベース内に追加のオブジェクトが必要です。通常、データベースで実行するには
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ロギング機能を介して詳細なセッションおよび/またはオブジェクト監査ログを提供します。
次の例の抜粋のように、 pgaudit.
で始まるパラメーターを構成に追加することにより、 pgaudit
を有効にできます。
#
postgresql:
parameters:
pgaudit.log: "all, -misc"
pgaudit.log_catalog: "off"
pgaudit.log_parameter: "on"
pgaudit.log_relation: "on"
#
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のドキュメントを参照してください。
クラスターマニフェスト内では、次の抜粋に示すように、
spec.postgresql.pg_hba のリスト項目としてpg_hba
行が追加されます。
postgresql:
pg_hba:
- hostssl app app 10.244.0.0/16 md5
上記の例では、 app
ユーザーがMD5パスワード認証(必要に応じてscram-sha-256
を使用できます)を使用して、安全なチャネル(hostssl
)を介してアクセスできるようにしています。
LDAP構成¶
クラスター仕様のpostgres セクションには、 pg_hba.conf
ファイルに追加されるルールに変換するLDAP構成を定義するために使用できるオプションのldap
セクションがあります。
これは2つのモードをサポートします。LDAPセクションで server
、prefix 、およびsuffix
を指定する必要があるsimple bind モードと、 server
、baseDN 、binDN
、およびシークレットであるldap_tran_9を指定する必要があるsearch+bind
モード。さらに、 search+bind モードには、 searchFilter
またはsearchAttribute を指定するオプションがあります。
searchAttribute が指定されない場合、デフォルトのuid
が使用されます。
さらに、どちらのモードでも、 ldapschemeのscheme とport
を指定できます。ただし、スキームもポートも必要ありません。
search+bindで入力されたこのセクションは次のようになります。
postgresql:
parameters:
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_modsarchive_cleanup_commandarchive_commandarchive_modebonjourbonjour_namecluster_nameconfig_filedata_directorydata_sync_retryevent_sourceexternal_pid_filefull_page_writeshba_filehot_standbyident_filejit_providerlisten_addresseslog_destinationlog_directorylog_file_modelog_filenamelog_rotation_agelog_rotation_sizelog_truncate_on_rotationlogging_collectorportprimary_conninfoprimary_slot_namepromote_trigger_filerecovery_end_commandrecovery_min_apply_delayrecovery_targetrecovery_target_actionrecovery_target_inclusiverecovery_target_lsnrecovery_target_namerecovery_target_timerecovery_target_timelinerecovery_target_xidrestart_after_crashrestore_commandshared_preload_librariessslssl_ca_filessl_cert_filessl_ciphersssl_crl_filessl_dh_params_filessl_ecdh_curvessl_key_filessl_max_protocol_versionssl_min_protocol_versionssl_passphrase_commandssl_passphrase_command_supports_reloadssl_prefer_server_ciphersstats_temp_directorysynchronous_standby_namessyslog_facilitysyslog_identsyslog_sequence_numberssyslog_split_messagesunix_socket_directoriesunix_socket_groupunix_socket_permissionswal_levelwal_log_hints