Patroni 構成
-
グローバル 動的構成 。 これらのオプションは DCS (分散構成ストア) に保存され、すべてのクラスター ノードに適用されます。動的構成は、patronictl_edit_config ツールまたは Patroni REST API を使用していつでも設定できます。変更されたオプションがスタートアップ コンフィギュレーションの一部ではない場合、オプションはすべてのノードに非同期的に (次のウェイクアップ サイクル時に) 適用され、その後リロードされます。構成を適用するためにノードの再起動が必要な場合 (コンテキストが postmaster で、値が変更された PostgreSQL パラメータ の場合)、これを示す特別なフラグ
pending_restartが members.data JSON に設定されます。さらに、ノードのステータスは"restart_pending": trueを表示することでこれを示します。 -
ローカル 設定ファイル (patroni.yml)。 これらのオプションは構成ファイルで定義され、動的構成より優先されます。
patroni.ymlは、SIGHUP を Patroni プロセスに送信するか、POST /reloadREST-API リクエストを実行するか、patronictl_reload を実行することで、実行時に (Patroni を再起動せずに) 変更および再ロードできます。ローカル構成は、単一の YAML ファイルまたはディレクトリのいずれかになります。ディレクトリの場合、そのディレクトリ内のすべての YAML ファイルがソートされた順序で 1 つずつロードされます。キーが複数のファイルで定義されている場合、最後のファイル内のキーが優先されます。 -
環境構成 。 環境変数を使用して、一部の「ローカル」構成パラメータを設定/上書きすることができます。環境構成は、動的環境で実行していて、一部のパラメーターが事前にわかっていない場合に非常に役立ちます (たとえば、
docker内で実行しているときに外部 IP アドレスを知ることはできません)。
重要なルール
PostgreSQL パラメータは Patroni によって制御されます
PostgreSQL パラメーターの一部は、プライマリーとレプリカで同じ値を保持する必要があります。これらについては、ローカルの patroni 設定ファイルまたは環境変数で設定された値は効果がありません。値を変更または設定するには、DCS の共有構成を変更する必要があります。以下は、そのようなパラメータの実際のリストとデフォルト値および最小値です。
- max_connections: デフォルト値 100、最小値 25
- max_locks_per_transaction: デフォルト値 64、最小値 32
- max_worker_processes: デフォルト値 8、最小値 2
- max_prepared_transactions: デフォルト値 0、最小値 0
- wal_level: デフォルト値 hot_standby、受け入れられる値: hot_standby、replica、logical
- track_commit_timestamp: デフォルト値はオフです
以下のパラメータの場合、PostgreSQL はプライマリーとすべてのレプリカ間で同じ値を必要としません。ただし、レプリカがいつでもプライマリーになる可能性を考慮すると、これらのパラメーターを異なる値に設定することはあまり意味がありません。したがって、Patroni は、これらの値の設定を 動的構成 に制限しています。
- max_wal_senders: デフォルト値 10、最小値 3
- max_replication_slots: デフォルト値 10、最小値 4
- wal_keep_segments: デフォルト値 8、最小値 1
- wal_keep_size: デフォルト値 128MB、最小値 16MB
- wal_log_hints: オン
これらのパラメーターは検証され、それらが正常であるか、最小値を満たしているかが確認されます。
Patroni によって制御される Postgres パラメーターは他にもいくつかあります。
- listen_addresses -
postgresql.listenまたはPATRONI_POSTGRESQL_LISTEN環境変数から設定されます - port -
postgresql.listenまたはPATRONI_POSTGRESQL_LISTEN環境変数から設定されます - cluster_name -
scopeまたはPATRONI_SCOPE環境変数から設定されます - hot_standby: on
安全のため、上記のリストのパラメータは postgresql.conf に書き込まれ、引数のリストとして postgres に渡され、(wal_keep_segments と wal_keep_size を除き) ALTER SYSTEM
すら超える最も高い優先順位が与えられます。
postgresql.listen や postgresql.data_dir のように、ローカルでのみ設定可能なパラメーターもいくつかあります。つまり、Patroni 設定ファイル 内で、または環境構成 の変数経由で設定します。ほとんどの場合、ローカル構成は動的構成をオーバーライドします。
ローカルまたは動的構成オプションを適用すると、次のアクションが実行されます。
- ノードはまず、
postgresql.base.confファイルがあるかどうか、またはcustom_confパラメーターが設定されているかどうかを確認します。 custom_confパラメータが設定されている場合、指定されたファイルが基本構成として使用され、postgresql.base.confとpostgresql.confは無視されます。custom_confパラメーターが設定されておらず、postgresql.base.confが存在する場合、名前が変更された “original” 構成が含まれており、基本構成として使用されます。custom_confもpostgresql.base.confもない場合、元のpostgresql.confはpostgresql.base.confに名前変更され、基本構成として使用されます。- 動的オプション (上記の例外を除く) は
postgresql.confにダンプされ、インクルードはpostgresql.confで基本構成 (postgresql.base.confまたはcustom_confのファイルのいずれか) に設定されます。したがって、インクルードが存在するかどうかを確認するために構成ファイルを再度読み取ることなく、新しいオプションを適用できます。 - Patroni がクラスターを管理するために必要な一部のパラメーターは、コマンド ラインを使用してオーバーライドされます。
- 再起動を必要とするオプションが変更された場合 (pg_settings のコンテキストとそれらのオプションの実際の値を確認する必要があります)、そのノードに pending_restart フラグが設定されます。このフラグは再起動時にリセットされます。
パラメータは次の順序で適用されます (ランタイムに最も高い優先順位が与えられます)。
- ファイル
postgresql.base.conf(または設定されている場合はcustom_confファイル) からパラメータをロードします - ファイル
postgresql.confからパラメータをロードします - ファイル
postgresql.auto.confからパラメータをロードします -o --name=valueを使用した実行時パラメーター
これにより、すべてのノードの構成 (2)、ALTER SYSTEM を使用した特定のノードの構成 (3) が可能になり、Patroni の実行に不可欠なパラメーターが強制されるようになります (4)。また、Patroni (1) を介さずに postgresql.conf を直接管理する構成ツールの余地も残ります。
共有メモリに関わる PostgreSQL パラメータ
PostgreSQL には、使用される共有メモリのサイズを決定するいくつかのパラメータがあります。
- max_connections
- max_prepared_transactions
- max_locks_per_transaction
- max_wal_senders
- max_worker_processes
これらのパラメータを変更するには、PostgreSQL の再起動が必要であり、スタンバイ ノードの共有メモリ構造をプライマリー ノードよりも小さくすることはできません。
前に説明したように、Patroni は、これらの値の変更を 動的構成 経由に限定します。通常、これは次のもので構成されます。
- patronictl_edit_config
(または REST API
/configエンドポイント経由) による変更の適用 - patronictl_restart
(または REST API
/restartエンドポイント経由) によるノードの再起動
注: PostgreSQL ノードの再起動は、patronictl_restart
コマンド、または REST API /restart エンドポイントを介して実行する必要があることに留意してください。Patroni デーモンの再起動による PostgreSQL の再起動の試み (たとえば systemctl restart patroni の実行) は、プライマリー ノードを再起動している場合、クラスター内でフェイルオーバーを引き起こす可能性があります。
ただし、これらの設定は共有メモリを管理するため、ノードを再起動するときは特に注意する必要があります。
-
これらの設定のいずれかの値を増加させたい場合:
- 最初にすべてのスタンバイを再起動します
- その後プライマリーを再起動します
-
これらの設定のいずれかの値を減少させたい場合:
- 最初にプライマリーを再起動します
- その後、すべてのスタンバイを再起動します
注: これらの設定のいずれかの値を減少させた後にすべてのノードを一度に再起動しようとすると、Patroni は変更を無視し、元の設定値でスタンバイを再起動するため、後でスタンバイを再度再起動する必要があります。Patroni は、スタンバイ ノードの pg_controldata で表示される値よりも低い値にこれらのパラメーターのいずれかを設定しようとすると、PostgreSQL が FATAL メッセージで終了するため、スタンバイが無限クラッシュ ループに陥るのを防ぐためにこれを行います。言い換えれば、プライマリーでのこれらの変更に関してスタンバイの pg_controldata がプライマリーと同期している場合にのみ、スタンバイの設定を減らすことができます。
詳細については、PostgreSQL 管理者の概要 を参照してください。
Patroni 構成パラメータ
また、次の Patroni 構成オプションは動的にのみ変更可能です:
- ttl: 30
- loop_wait: 10
- retry_timeout: 10
- maximum_lag_on_failover: 1048576
- max_timelines_history: 0
- check_timeline: false
- postgresql.use_slots: true
これらのオプションを変更すると、Patroni は DCS に保存されている構成の関連セクションを読み取り、その実行時の値を変更します。
Patroni ノードは、構成が変更されるたびに、DCS オプションの状態を、Postgres データ ディレクトリにあるファイル patroni.dynamic.json にダンプします。これらのオプションが DCS に完全に存在しない場合、または無効な場合、リーダーのみがオンディスク ダンプからこれらのオプションを復元できます。
構成の生成と検証
Patroni は、Patroni ローカル構成
の生成と検証のためのコマンドライン インターフェイスを提供します。 patroni 実行可能ファイルを使用すると、次のことが可能になります。
- サンプルのローカル Patroni 構成を作成します。
- ローカルで実行されている PostgreSQL インスタンスの Patroni 構成ファイルを作成します (例: Patroni の統合 の準備ステップとして)。
- 指定された Patroni 構成ファイルを検証します。
Patroni 構成のサンプル
説明
サンプルの Patroni 構成ファイルを yaml 形式で生成します。パラメータ値は 環境構成
を使用して定義されます。設定されていない場合は、Patroni で使用されるデフォルト値、または後でユーザーが定義すべき値のための #FIXME 文字列が使用されます。
一部のデフォルト値はローカル設定に基づいて定義されます。
- postgresql.listen:
gethostnameが返す現在のマシンのホスト名をgetaddrinfoで解決した IP アドレスと標準の5432ポート。- postgresql.connect_address:
gethostnameが返す現在のマシンのホスト名をgetaddrinfoで解決した IP アドレスと標準の5432ポート。- postgresql.authentication.rewind: PostgreSQL バージョンをバイナリから定義でき、そのバージョンが 11 以降である場合にのみ定義されます。
- restapi.listen:
gethostnameが返す現在のマシンのホスト名をgetaddrinfoで解決した IP アドレスと標準の8008ポート。- restapi.connect_address:
gethostnameが返す現在のマシンのホスト名をgetaddrinfoで解決した IP アドレスと標準の8008ポート。
パラメータ
configfile - 結果を保存するために使用される構成ファイルへのフルパス。指定しない場合、結果は stdout に送信されます。
実行中のインスタンスの Patroni 構成
説明
ローカルで実行されている PostgreSQL インスタンス用に Patroni 構成を yaml 形式で生成します。提供された DSN (優先されます) または PostgreSQL 環境変数
のいずれかが PostgreSQL 接続に使用されます。パスワードが指定されていない場合は、プロンプトから入力する必要があります。
ソース Postgres インスタンスで定義されたすべての非内部 GUC は、構成ファイル、postmaster コマンドライン、または環境変数のいずれで設定されたものであるかにかかわらず、次の Patroni 構成パラメーターのソースとして使用されます:
- scope:
cluster_nameGUC 値;- postgresql.listen:
listen_addressesおよびportGUC 値。- postgresql.data_dir:
data_directoryGUC 値;- postgresql.parameters:
archive_command、restore_command、archive_cleanup_command、recovery_end_command、ssl_passphrase_command、hba_file、ident_file、config_fileGUC 値。- bootstrap.dcs: 収集された他のすべての PostgreSQL GUC。
scope、postgresql.listen、または postgresql.data_dir が Postgres GUC から設定されていない場合は、それぞれの 環境構成
値が使用されます。
値の定義に適用されるその他のルールは次のとおりです。
- name:
PATRONI_NAME環境変数値 (設定されている場合)、そうでない場合は現在のマシンのホスト名。- postgresql.bin_dir: 実行中のインスタンスから収集された Postgres バイナリへのパス。
- postgresql.connect_address:
gethostnameが返す現在のマシンのホスト名をgetaddrinfoで解決した IP アドレスと、インスタンス接続に使用されるポートまたはportGUC 値。- postgresql.authentication.superuser: インスタンス接続に使用される構成。
- postgresql.pg_hba: ソース インスタンスの
hba_fileから収集された行。- postgresql.pg_ident: ソース インスタンスの
ident_fileから収集された行。- restapi.listen:
gethostnameが返す現在のマシンのホスト名をgetaddrinfoで解決した IP アドレスと標準の8008ポート。- restapi.connect_address:
gethostnameが返す現在のマシンのホスト名をgetaddrinfoで解決した IP アドレスと標準の8008ポート。
環境構成 を使用して定義された他のパラメーターも構成に含まれます。
パラメータ
configfile 結果を保存するために使用される構成ファイルへのフルパス。指定しない場合、結果は stdout に送信されます。
dsn GUC 値を取得するローカル PostgreSQL インスタンスのオプションの DSN 文字列。
Patroni 構成を検証する
説明
指定された Patroni 構成を検証し、失敗したチェックに関する情報を出力します。
パラメータ
configfile 確認する構成ファイルへのフルパス。指定されない場合、またはファイルが存在しない場合は、PATRONI_CONFIGURATION 環境変数からの読み取りを試みます。設定されていない場合は、Patroni 環境変数
からの読み取りを試みます。
--ignore-listen-port | -i configfile を検証するときに、すでに使用されている listen ポートのバインド失敗を無視するためのオプションのフラグ。
--print | -p 正常に検証された後にローカル構成 (環境構成のオーバーライドを含む) を出力するためのオプションのフラグ。
動的な構成設定は DCS に保存され、クラスター全体に適用されます。
Patroni YAML 構成オプションとセクションの完全なリファレンス。
Patroni 構成パラメーターをオーバーライドするための環境変数。