レプリカのイメージングとブートストラップ¶
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
ブートストラップするクラスターインスタンスのデータディレクトリへのパス
これら2つの追加フラグを渡すことは、特別な no_params パラメーターを True に設定することにより無効にできます。
ブートストラップスクリプトが0を返した場合、Patroniはそれによって生成されたPostgreSQLインスタンスを構成して起動しようとします。中間ステップのいずれかが失敗するか、スクリプトがゼロ以外の値を返した場合、Patroniはブートストラップが失敗したと想定し、自分自身の後をクリーンアップし、初期化ロックを解放して別のノードにブートストラップする機会を与えます。
recovery_conf ブロックがカスタムブートストラップメソッドと同じセクションで定義されている場合、Patroniは新しくブートストラップされたインスタンスを開始する前に recovery.conf を生成します。通常、このようなrecovery.confには、 promote に設定された recovery_target_timeline とともに、 recovery_target_* パラメーターの少なくとも1つを含める必要があります。
keep_existing_recovery_conf が定義され、 True に設定されている場合、Patroniは既存の recovery.conf ファイルが存在しても削除しません。これは、適切な recovery.conf を生成するpgBackRestなどのツールを使用してバックアップからブートストラップする場合に役立ちます。
注釈
ブートストラップメソッドはチェーンされておらず、プライマリが失敗した場合にデフォルトのメソッドにフォールバックされません
レプリカの構築¶
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'
create_replica_methods は、使用可能なレプリカ作成方法とそれらの実行順序を定義します。Patroniは、0を返す最初のメソッドで停止します。各メソッドは、構成ファイルに個別のセクションを定義し、実行するコマンドとそのコマンドに渡す必要があるカスタムパラメーターをリストする必要があります。すべてのパラメーターは --name=value 形式で渡されます。ユーザー定義パラメーターに加えて、Patroniはクラスター固有のパラメーターをいくつか提供します。
- --scope
このレプリカが属するクラスター
- --datadir
レプリカのデータディレクトリへのパス
- --role
常に「レプリカ」
- --connstring
クローン元のクラスターメンバー（プライマリまたは他のレプリカ）に接続するための接続文字列。接続文字列内のユーザーは、SQLおよびレプリケーションプロトコルコマンドを実行できます。
特別な no_leader パラメーターが定義されている場合、定義されている場合、実行中のリーダーまたはレプリカがない場合でも、Patroniはレプリカ作成メソッドを呼び出すことができます。その場合、空の文字列が接続文字列に渡されます。これは、バイナリバックアップから以前に実行されていたクラスターを復元する場合に役立ちます。
特別な keep_data パラメーターが定義されている場合、定義されている場合、復元を呼び出す前にPGDATAフォルダーをクリーンアップしないようにPatroniに指示します。
特別な no_params パラメーターが定義されている場合、カスタムコマンドにパラメーターを渡すことを制限します。
basebackup メソッドは特殊なケースです。 create_replica_methods が空の場合に使用されますが、 create_replica_methods メソッドの中で明示的にリストすることは可能です。このメソッドは pg_basebackup で新しいレプリカを初期化します。 clonefrom タグが付いたレプリカがない限り、ベースバックアップはリーダーから取得されます。その場合、そのようなレプリカの1つがpg_basebackupのオリジンとして使用されます。構成なしで動作します。ただし、 basebackup 構成セクションを指定することは可能です。他のメソッド構成と同じルールが適用されます。つまり、ロング（--付き）オプションのみを指定する必要があります。接続文字列をオーバーライドするか、tarまたは圧縮されたベースバックアップを作成するオプションを提供する場合、パトニーはレプリカを作成できません。 basebackup セクションに渡されたパラメーターの名前または値に対して実行される検証はありません。また、WALフォルダーにシンボリックリンクが使用される場合、オプションとして正しい --waldir パスを指定するのはユーザー次第であることにも注意してください。ただし、このオプションはv10以降のみサポートされています。
ベースバックアップパラメーターは、マップ（キーと値のペア）または要素のリストとして指定できます。各要素は、キーと値のペアまたは単一のキー（値を受け取らないオプションの場合、たとえば、 --verbose ）。次の2つの例を考えてみましょう。
postgresql:
basebackup:
max-rate: '100M'
checkpoint: 'fast'
そして
postgresql:
basebackup:
- verbose
- max-rate: '100M'
- waldir: /pg-wal-mount/external-waldir
すべてのレプリカ作成メソッドが失敗した場合、Patroniは次のイベントループサイクル中にすべてのメソッドを順番に再試行します。
スタンバイクラスタ¶
もう1つの利用可能なオプションは、/"スタンバイクラスタ/"を実行することです。これには、リモートノードからレプリケートするスタンバイノードのみが含まれます。このタイプのクラスターには次のものがあります。
/"スタンバイリーダー/"。リモートノードからレプリケートすることを除いて、通常のクラスターリーダーとほとんど同じように動作します。
スタンバイリーダーから複製しているカスケードレプリカ。
スタンバイリーダーは、DCSのリーダーロックを保持および更新します。リーダーロックが期限切れになると、カスケードレプリカは選挙を実行してスタンバイから別のリーダーを選択します。
スタンバイクラスターとレプリケート元のプライマリクラスターの間にこれ以上の関係はありません。特に、同じDCSを使用する場合、同じDCSスコープを共有してはなりません。彼らは、レプリケーション情報を除いて、お互いに他に何も知りません。また、スタンバイクラスターは、プライマリクラスターの patronictl list または patronictl topology 出力に表示されません。
柔軟性のために、`standby_cluster`セクションで`create_replica_methods`キーを提供することにより、クラスターが「スタンバイモード」にあるときにレプリカを作成し、WALレコードをリカバリする方法を指定できます。クラスターがデタッチされ、`postgresql`セクションの`create_replica_methods`によって制御される通常のクラスターとして機能する場合、レプリカの作成とは異なります。`postgresql`セクションの/"standby/"と/"normal/"の両方の`create_replica_methods`参照キー。
このようなクラスターを構成するには、パトロニ構成でセクション standby_cluster を指定する必要があります。
bootstrap:
dcs:
standby_cluster:
host: 1.2.3.4
port: 5432
primary_slot_name: patroni
create_replica_methods:
- basebackup
これらのオプションはクラスターブートストラップ中に1回のみ適用され、後でそれらを変更する唯一の方法はDCSを使用することであることに注意してください。
Patroniは、リモートプライマリのPGDATAで`postgresql.conf`または`postgresql.conf.backup`を見つけることを想定しており、ベースバックアップ後に見つからない場合、起動しません。リモートプライマリがその`postgresql.conf`を他の場所に保持している場合、それをPGDATAにコピーするのはあなたの責任です。
スタンバイクラスターでレプリケーションスロットを使用する場合、プライマリクラスターにも対応するレプリケーションスロットを作成する必要があります。スタンバイクラスタの実装では自動的には行われません。プライマリクラスターでPatroniの永続的なレプリケーションスロット機能を使用して、 primary_slot_name 、または primary_slot_name が提供されていない場合はそのデフォルト値と同じ名前のレプリケーションスロットを維持できます。