レプリカのイメージングとブートストラップ¶
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 を生成します(または、PostgreSQL12以上を実行している場合は、Postgres構成でリカバリ設定を設定します)。通常、このようなリカバリ構成には、 promote に設定された recovery_target_timeline とともに、少なくとも1つの recovery_target_* パラメータが含まれている必要があります。
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_recover
api-url: https://barman-host:7480
barman-server: my_server
ssh-command: ssh postgres@patroni-host
注釈
patroni_barman_recover では、バックアップAPIを通じてリモート barman recover を実行できるように、BarmanホストにBarmanと pg-backup-api の両方が構成されている必要があります。上の例では、使用可能なパラメータのサブセットを使用しています。 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_recover
api-url: https://barman-host:7480
barman-server: my_server
ssh-command: ssh postgres@patroni-host
basebackup:
max-rate: '100M'
注釈
patroni_barman_recover では、バックアップAPIを通じてリモート barman recover を実行できるように、BarmanホストにBarmanと pg-backup-api の両方が構成されている必要があります。上の例では、使用可能なパラメータのサブセットを使用しています。 patroni_barman_recover --help を実行すると、詳細情報を取得できます。
create_replica_methods は、使用可能なレプリカ作成メソッドとその実行順序を定義します。Patroniは、0を返す最初のメソッドで停止します。各メソッドは、実行するコマンドとそのコマンドに渡す必要があるカスタムパラメーターをリストする構成ファイル内に個別のセクションを定義する必要があります。すべてのパラメータは --name=value 形式で渡されます。ユーザー定義のパラメーターの他に、Patroniはクラスター固有のパラメーターをいくつか提供します。
- --scope
このレプリカが属するクラスター
- --datadir
レプリカのデータディレクトリへのパス
- --role
常に「レプリカ」
- --connstring
クローン作成元のクラスターメンバーに接続するための接続文字列(プライマリまたは他のレプリカ)。接続文字列内のユーザーは、SQLおよびレプリケーションプロトコルコマンドを実行できます。
特別な no_leader パラメータが定義されている場合、実行中のリーダーやレプリカがない場合でも、Patroniはレプリカ作成メソッドを呼び出すことができます。その場合、接続文字列には空の文字列が渡されます。これは、以前に実行していたクラスターをバイナリバックアップから復元する場合に便利です。
特別な keep_data パラメータが定義されている場合、Patroniは復元を呼び出す前にPGDATAフォルダーをクリーンアップしないように指示されます。
特別な no_params パラメータが定義されている場合、パラメータをカスタムコマンドに渡すことが制限されます。
basebackup メソッドは特殊なケースです。 create_replica_methods メソッドの中に明示的にリストすることは可能ですが、 create_replica_methods が空の場合に使用されます。このメソッドは、 pg_basebackup を使用して新しいレプリカを初期化し、 clonefrom タグを持つレプリカがない限り、ベースバックアップはリーダーから取得されます。その場合、そのようなレプリカの1つがpg_basebackupのオリジンとして使用されます。設定なしで動作します。ただし、 basebackup 構成セクションを指定することは可能です。他のメソッド設定と同じルールが適用されます。つまり、長い(--付き)オプションのみを指定する必要があります。すべてのパラメータが意味をなすわけではありません。接続文字列をオーバーライドしたり、tar圧縮または圧縮されたベースバックアップを作成するオプションを提供したりすると、patroniはそのバックアップからレプリカを作成できなくなります。 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は次のイベントループサイクル中にすべてのメソッドを順番に再試行します。
スタンバイクラスタ¶
もう1つの利用可能なオプションは、リモートノードから複製されたスタンバイノードのみを含む「スタンバイクラスタ」を実行することです。このタイプのクラスターには次のものがあります。
「スタンバイリーダー」。リモートノードから複製する点を除けば、通常のクラスターリーダーとほぼ同じように動作します。
カスケードレプリカ。スタンバイリーダーから複製されます。
スタンバイリーダーはDCSのリーダーロックを保持し、更新します。リーダーのロックが期限切れになると、カスケードレプリカは選挙を実行してスタンバイから別のリーダーを選択します。
スタンバイクラスターとその複製元のプライマリクラスターの間にはそれ以上の関係はありません。特に、同じDCSを使用する場合、同じDCSスコープを共有してはなりません。これらは、レプリケーション情報以外にはお互いに何も知りません。また、スタンバイクラスターは、プライマリクラスターの Patroniリスト または Patroniリスト 出力に表示されません。
柔軟性を高めるため、「standby_cluster」セクションに「create_replica_methods」キーを指定することで、クラスターが「スタンバイモード」のときにレプリカとリカバリWALレコードを作成する方法を指定できます。これは、クラスターが切り離されて通常のクラスターとして機能する場合のレプリカの作成とは異なります。これは、「postgresql」セクションの「create_replica_methods」によって制御されます。「standby」と「normal」の両方の`create_replica_methods`は、`postgresql`セクションのキーを参照します。
このようなクラスターを構成するには、patroni構成でセクション 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 が指定されていない場合はそのデフォルト値のレプリケーションスロットを維持できます。