レプリカイメージングとブートストラップ
Patroniでは、新しいレプリカの作成をカスタマイズできます。また、新しい空のクラスターがブートストラップされているときに起こることの定義もサポートします。 2つの区別は明確に定義されています。Patroniは、クラスターのDCSに initialize キーが存在する場合にのみレプリカを作成します。 initialize キーがない場合 - Patroniは、初期化キーロックを取得する最初のノードでブートストラップを排他的に呼び出します。
ブートストラップ
PostgreSQLは、新しいクラスターを初期化するための initdb コマンドを提供し、Patroniはデフォルトでそれを呼び出します。特定の場合、特に既存のクラスターのコピーとして新しいクラスターを作成する場合、ビルトインメソッドをカスタムアクションに置き換える必要があります。 Patroniは、新しいクラスターをブートストラップするユーザー定義スクリプトの実行をサポートし、それらにいくつかの必要な引数、つまりクラスターの名前とデータディレクトリへのパスを提供します。これは、Patroni構成の bootstrap セクションで構成されます。例
bootstrap:
method: <custom_bootstrap_method_name>
<custom_bootstrap_method_name>:
command: <path_to_custom_bootstrap_script> [param1 [, ...]]
keep_existing_recovery_conf: False
no_params: False
recovery_conf:
recovery_target_action: promote
recovery_target_timeline: latest
restore_command: <method_specific_restore_command>
各ブートストラップメソッドは、少なくとも name および command を定義する必要があります。デフォルト動作をトリガーするために特別な initdb メソッドが使用できます。この場合、 method パラメーターを完全に省略できます。 command は、絶対パス、または patroni コマンドの場所を基準とした相対パスを使用して指定できます。構成ファイルで定義された固定パラメーターに加えて、Patroniは2つのクラスター固有のパラメーターを提供します。
- --scope
ブートストラップするクラスターの名前
- --datadir
ブートストラップするクラスターインスタンスのデータディレクトリへのパス
特別な no_params パラメーターを True に設定することにより、これら2つの追加フラグの受け渡しを無効にできます。
ブートストラップスクリプトが 0 を返す場合、Patroniは、自分自身が生成するPostgreSQLインスタンスを構成および起動しようとします。中間ステップのいずれかが失敗するか、スクリプトがゼロ以外の値を返した場合、Patroniはブートストラップが失敗したと想定し、自分自身の後にクリーンアップし、初期化ロックを解放して別のノードにブートストラップの機会を与えます。
recovery_conf ブロックがカスタムブートストラップ方法と同じセクションで定義されている場合、Patroniは、新しくブートストラップされたインスタンスを起動する前に recovery.conf を生成しますまたは、PostgreSQL > = 12を実行している場合はPostgres構成でリカバリ設定を設定します。通常、このようなリカバリ構成には、 promote に設定された recovery_target_action とともに、 recovery_target_* パラメーターの少なくとも1つが含まれる必要があります。
keep_existing_recovery_conf が定義され True に設定されている場合 、Patroniは既存の recovery.conf ファイルが存在する場合は削除しませんPostgreSQL <= 11。同様に、その場合、Patroniは既存の recovery.signal または standby.signal が存在する場合は削除せず、構成されたリカバリ設定PostgreSQL > = 12をオーバーライドしません。これは、適切なリカバリ構成を生成するpgBackRestのようなツールを使用してバックアップからブートストラップする場合に役立ちます。
それに加えて、カスタムブートストラップメソッド構成で通知された追加のキー/値ペアは、引数として --name=value 形式で command に渡されます。例
bootstrap:
method: <custom_bootstrap_method_name>
<custom_bootstrap_method_name>:
command: <path_to_custom_bootstrap_script>
arg1: value1
arg2: value2
設定済みの command が --arg1=value1 --arg2=value2 コマンドライン引数でさらに呼び出されるようにします。
注釈
ブートストラップメソッドはチェーンされず、プライマリメソッドに障害が発生した場合にデフォルトのメソッドにフォールバックされません
例として、次のような構成を使用してBarmanバックアップから新しいPatroniクラスターをブートストラップできます。
bootstrap:
method: barman
barman:
keep_existing_recovery_conf: true
command: patroni_barman --api-url https://barman-host:7480 recover
barman-server: my_server
ssh-command: ssh postgres@patroni-host
注釈
patroni_barman recover では、 BarmanホストでBarmanと pg-backup-api の両方を構成している必要があるため、バックアップAPIを介してリモート barman recover を実行できます。上記の例では、使用可能なパラメーターのサブセットを使用しています。 patroni_barman recover --help を実行すると、詳細情報を取得できます。
ビルディングレプリカ
Patroniは、新しいレプリカを作成するために実績のある pg_basebackup を使用します。その欠点の1つは、実行中のリーダーノードが必要であることです。もう1つは、バックアップデータの「オンザフライ」圧縮と、古いバックアップファイルのビルトインのクリーンアップの欠如です。 WAL-E 、 pgBackRest 、 Barman などの他のバックアップソリューション、または単に独自のスクリプトをローリングする人もいます。これらのすべてのユースケースに対応するために、Patroniは新しいレプリカのクローンを作成するカスタムスクリプトの実行をサポートしています。これらは postgresql 構成ブロックで構成されます。
postgresql:
create_replica_methods:
- <method name>
<method name>:
command: <command name>
keep_data: True
no_params: True
no_leader: 1
例 wal_e
postgresql:
create_replica_methods:
- wal_e
- basebackup
wal_e:
command: patroni_wale_restore
no_leader: 1
envdir: {{WALE_ENV_DIR}}
use_iam: 1
basebackup:
max-rate: '100M'
例 pgbackrest
postgresql:
create_replica_methods:
- pgbackrest
- basebackup
pgbackrest:
command: /usr/bin/pgbackrest --stanza=<scope> --delta restore
keep_data: True
no_params: True
basebackup:
max-rate: '100M'
例Barman
postgresql:
create_replica_methods:
- barman
- basebackup
barman:
command: patroni_barman --api-url https://barman-host:7480 recover
barman-server: my_server
ssh-command: ssh postgres@patroni-host
basebackup:
max-rate: '100M'
注釈
patroni_barman recover では、 BarmanホストでBarmanと pg-backup-api の両方を構成している必要があるため、バックアップAPIを介してリモート barman recover を実行できます。上記の例では、使用可能なパラメーターのサブセットを使用しています。 patroni_barman recover --help を実行すると、詳細情報を取得できます。
create_replica_methods は、使用可能なレプリカ作成方法とそれらの実行順序を定義します。 Patroniは、0を返す最初のメソッドで停止します。各メソッドは、構成ファイルの別のセクションを定義し、実行するコマンドとそのコマンドに渡すカスタムパラメーターをリストする必要があります。すべてのパラメーターは --name=value 形式で渡されます。ユーザー定義のパラメーターに加えて、Patroniはいくつかのクラスター固有のパラメーターを提供します。
- --scope
このレプリカが属するクラスター
- --datadir
レプリカのデータディレクトリへのパス
- --role
常に'レプリカ'
- --connstring
クローンを作成するクラスターメンバーに接続する接続文字列プライマリまたは他のレプリカ。接続文字列のユーザーは、 SQLおよびレプリケーションプロトコルコマンドを実行できます。
特別な no_leader パラメーターが定義されている場合、Patroniは実行中のリーダーやレプリカが存在しない場合でも、レプリカ作成メソッドを呼び出すことができます。その場合、空の文字列が接続文字列で渡されます。これは、以前に実行されていたクラスターをバイナリバックアップから復元する場合に役立ちます。
特別な keep_data パラメーターが定義されている場合、restoreを呼び出す前にPGDATAフォルダーをクリーンにしないようにPatroniに指示します。
特別な no_params パラメーターが定義されている場合、カスタムコマンドにパラメーターを渡すことを制限します。
basebackup メソッドは特殊なケースです。 create_replica_methods が空の場合に使用されますが、 create_replica_methods メソッド間で明示的にリストすることも可能です。このメソッドは、 pg_basebackup で新しいレプリカを初期化します。ベースバックアップは、 clonefrom タグを持つレプリカがない限りリーダーから取得されます。その場合、このようなレプリカのいずれかがpg_basebackupのオリジンとして使用されます。構成なしで動作します。ただし、 basebackup 構成セクションを指定することは可能です。他のメソッド構成と同じルールが適用されます。つまり、長い---付きオプションのみを指定する必要があります。すべてのパラメーターが意味をなすわけではありません。接続文字列をオーバーライドするか、作成するタールまたは圧縮されたベースバックアップにオプションを提供する場合、パトロニはそれからレプリカを作成できません。 basebackup セクションに渡されるパラメーターの名前または値に対して実行される検証はありません。また、シンボリックリンクがWALフォルダーに使用される場合、オプションとして正しい --waldir パスを指定するのはユーザーの責任であるため、レプリカのビルドアップまたは再初期化の後、シンボリックリンクが持続するようにしてください。ただし、このオプションはv10以降でのみサポートされています。
basebackupパラメーターをマップキーと値のペアまたは要素のリストとして指定できます。各要素は、キーと値のペアまたは単一のキー値を受け取らないオプション、たとえば --verbose の場合)。これらの2つの例を検討します。
postgresql:
basebackup:
max-rate: '100M'
checkpoint: 'fast'
そして
postgresql:
basebackup:
- verbose
- max-rate: '100M'
- waldir: /pg-wal-mount/external-waldir
すべてのレプリカ作成方法が失敗した場合、Patroniは次のイベントループサイクル中にすべての方法を順番に再試行します。