パトローニRESTAPI¶
Patroniには豊富なRESTAPIがあり、リーダーレース中にPatroni自体によって使用され、フェイルオーバー/スイッチオーバー/再初期化/再起動/リロードを実行するために Patroni ツールによって使用され、HTTPヘルスチェックを実行するためにHAProxyまたはその他の種類のロードバランサーによって使用されます。、もちろんモニタリングにも使用できます。以下にPatroniRESTAPIエンドポイントのリストを示します。
ヘルスチェックエンドポイント¶
すべてのヘルスチェック GET リクエストに対して、PatroniはノードのステータスとHTTPステータスコードを含むJSONドキュメントを返します。JSONドキュメントが必要ない場合、または必要ない場合は、 GET の代わりに HEAD または OPTIONS メソッドを使用することを検討してください。
PatroniRESTAPIへの次のリクエストは、Patroniノードがリーダーロック付きのプライマリとして実行されている場合にのみ、HTTPステータスコード 200 を返します。
GET /GET /primaryGET /read-write
GET /standby-leader:PatroniノードがGET /standby-leaderのリーダーとして実行されている場合にのみ、HTTPステータスコードGET /standby-leaderを返します。GET /leader:Patroniノードがリーダーロックを持っている場合、HTTPステータスコードGET /leaderを返します。前の2つのエンドポイントとの主な違いは、PostgreSQLがprimaryとして実行されているかstandby_leaderとして実行されているかが考慮されていないことです。GET /replica:レプリカのヘルスチェックエンドポイント。Patroniノードがrunning状態にあり、ロールがreplicaで、noloadbalanceタグが設定されていない場合にのみ、HTTPステータスコードGET /replicaを返します。GET /replica?lag=<max-lag>:レプリカチェックエンドポイント。replicaからのチェックに加えて、レプリケーションの待ち時間もチェックし、指定された値を下回っている場合にのみステータスコードGET /replica?lag=<max-lag>を返します。DCSからのキーcluster.last_leader_operationは、パフォーマンス上の理由から、リーダーwalの位置とレプリカ上のレイテンシーの計算に使用されます。max-lagはバイト(整数)または人間が判読できる値で指定できます。16KB、64MB、1GB。GET /replica?lag=1048576GET /replica?lag=1024kBGET /replica?lag=10MBGET /replica?lag=1GB
GET /replica?tag_key1=value1&tag_key2=value2:レプリカチェックエンドポイント。さらに、ユーザー定義タグkey1およびkey2と、yaml構成管理のGET /replica?tag_key1=value1&tag_key2=value2セクション内のそれぞれの値もチェックします。タグがインスタンスに定義されていない場合、またはyaml設定内の値がクエリ値と一致しない場合は、HTTPステータスコード503が返されます。次のリクエストでは、リーダーまたはスタンバイリーダーのステータスをチェックしているため、Patroniはユーザー定義のタグを適用せず、無視されます。
GET /?tag_key1=value1&tag_key2=value2GET /leader?tag_key1=value1&tag_key2=value2GET /primary?tag_key1=value1&tag_key2=value2GET /read-write?tag_key1=value1&tag_key2=value2GET /standby_leader?tag_key1=value1&tag_key2=value2GET /standby-leader?tag_key1=value1&tag_key2=value2
GET /read-only:上記のエンドポイントと似ていますが、プライマリも含まれます。GET /synchronousまたはGET /sync:Patroniノードが同期スタンバイとして実行されている場合にのみ、HTTPステータスコードGET /synchronousを返します。GET /read-only-sync:上記のエンドポイントと似ていますが、プライマリも含まれます。GET /asynchronousまたはGET /async:Patroniノードが非同期スタンバイとして実行されている場合にのみ、HTTPステータスコードGET /asynchronousを返します。GET /asynchronous?lag=<max-lag>またはGET /async?lag=<max-lag>:非同期スタンバイチェックエンドポイント。asynchronousまたはasyncからのチェックに加えて、レプリケーション待機時間もチェックし、指定された値を下回っている場合にのみステータスコードGET /asynchronous?lag=<max-lag>を返します。DCSからのキーcluster.last_leader_operationは、パフォーマンス上の理由から、リーダーwalの位置とレプリカ上のレイテンシーの計算に使用されます。max-lagはバイト(整数)または人間が判読できる値で指定できます。16KB、64MB、1GB。GET /async?lag=1048576GET /async?lag=1024kBGET /async?lag=10MBGET /async?lag=1GB
GET /health:PostgreSQLが稼働している場合にのみ、HTTPステータスコードGET /healthを返します。GET /liveness:Patroniハートビートループが適切に実行されている場合はHTTPステータスコードGET /livenessを返し、最後の実行がプライマリでttl秒以上前である場合、またはレプリカで2*ttlを超えている場合はGET /livenessを返します。livenessProbeに使用できます。GET /readiness:Patroniノードがリーダーとして実行されている場合、またはPostgreSQLが稼働している場合に、HTTPステータスコードGET /readinessを返します。リーダー選挙(OpenShift)にKubernetesエンドポイントを使用できない場合、エンドポイントはreadinessProbeに使用できます。
readiness エンドポイントと liveness エンドポイントはどちらも非常に軽量であり、SQLを実行しません。プローブは、リーダーキーの有効期限が切れる頃に失敗し始めるように構成する必要があります。デフォルト値の ttl 、つまり 30s を使用すると、プローブの例は次のようになります。
readinessProbe:
httpGet:
scheme: HTTP
path: /readiness
port: 8008
initialDelaySeconds: 3
periodSeconds: 10
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
livenessProbe:
httpGet:
scheme: HTTP
path: /liveness
port: 8008
initialDelaySeconds: 3
periodSeconds: 10
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
監視エンドポイント¶
GET /patroni は、リーダーレース中にパトローニによって使用されます。監視システムでも使用できます。このエンドポイントによって生成されるJSONドキュメントは、ヘルスチェックエンドポイントによって生成されるJSONと同じ構造を持っています。
Example: 正常なクラスター
$ curl -s http://localhost:8008/patroni | jq .
{
"state": "running",
"postmaster_start_time": "2023-08-18 11:03:37.966359+00:00",
"role": "master",
"server_version": 150004,
"xlog": {
"location": 67395656
},
"timeline": 1,
"replication": [
{
"usename": "replicator",
"application_name": "patroni2",
"client_addr": "10.89.0.6",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
},
{
"usename": "replicator",
"application_name": "patroni3",
"client_addr": "10.89.0.2",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
}
],
"dcs_last_seen": 1692356718,
"tags": {
"clonefrom": true
},
"database_system_identifier": "7268616322854375442",
"patroni": {
"version": "3.1.0",
"scope": "demo",
"name": "patroni1"
}
}
Example: ロック解除されたクラスター
$ curl -s http://localhost:8008/patroni | jq .
{
"state": "running",
"postmaster_start_time": "2023-08-18 11:09:08.615242+00:00",
"role": "replica",
"server_version": 150004,
"xlog": {
"received_location": 67419744,
"replayed_location": 67419744,
"replayed_timestamp": null,
"paused": false
},
"timeline": 1,
"replication": [
{
"usename": "replicator",
"application_name": "patroni2",
"client_addr": "10.89.0.6",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
},
{
"usename": "replicator",
"application_name": "patroni3",
"client_addr": "10.89.0.2",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
}
],
"cluster_unlocked": true,
"dcs_last_seen": 1692356928,
"tags": {
"clonefrom": true
},
"database_system_identifier": "7268616322854375442",
"patroni": {
"version": "3.1.0",
"scope": "demo",
"name": "patroni1"
}
}
Example: Example: が有効になっているロック解除されたクラスター
$ curl -s http://localhost:8008/patroni | jq .
{
"state": "running",
"postmaster_start_time": "2023-08-18 11:09:08.615242+00:00",
"role": "replica",
"server_version": 150004,
"xlog": {
"location": 67420024
},
"timeline": 1,
"replication": [
{
"usename": "replicator",
"application_name": "patroni2",
"client_addr": "10.89.0.6",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
},
{
"usename": "replicator",
"application_name": "patroni3",
"client_addr": "10.89.0.2",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
}
],
"cluster_unlocked": true,
"failsafe_mode_is_active": true,
"dcs_last_seen": 1692356928,
"tags": {
"clonefrom": true
},
"database_system_identifier": "7268616322854375442",
"patroni": {
"version": "3.1.0",
"scope": "demo",
"name": "patroni1"
}
}
Example: Example: が有効になっているクラスター
$ curl -s http://localhost:8008/patroni | jq .
{
"state": "running",
"postmaster_start_time": "2023-08-18 11:09:08.615242+00:00",
"role": "replica",
"server_version": 150004,
"xlog": {
"location": 67420024
},
"timeline": 1,
"replication": [
{
"usename": "replicator",
"application_name": "patroni2",
"client_addr": "10.89.0.6",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
},
{
"usename": "replicator",
"application_name": "patroni3",
"client_addr": "10.89.0.2",
"state": "streaming",
"sync_state": "async",
"sync_priority": 0
}
],
"pause": true,
"dcs_last_seen": 1692356928,
"tags": {
"clonefrom": true
},
"database_system_identifier": "7268616322854375442",
"patroni": {
"version": "3.1.0",
"scope": "demo",
"name": "patroni1"
}
}
GET /metrics エンドポイントを通じて、PatroniメトリクスをPrometheus形式で取得します。
$ curl http://localhost:8008/metrics
# HELP patroni_version Patroni semver without periods. \
# TYPE patroni_version gauge
patroni_version{scope="batman",name="patroni1"} 020103
# HELP patroni_postgres_running Value is 1 if Postgres is running, 0 otherwise.
# TYPE patroni_postgres_running gauge
patroni_postgres_running{scope="batman",name="patroni1"} 1
# HELP patroni_postmaster_start_time Epoch seconds since Postgres started.
# TYPE patroni_postmaster_start_time gauge
patroni_postmaster_start_time{scope="batman",name="patroni1"} 1657656955.179243
# HELP patroni_master Value is 1 if this node is the leader, 0 otherwise.
# TYPE patroni_master gauge
patroni_master{scope="batman",name="patroni1"} 1
# HELP patroni_primary Value is 1 if this node is the leader, 0 otherwise.
# TYPE patroni_primary gauge
patroni_primary{scope="batman",name="patroni1"} 1
# HELP patroni_xlog_location Current location of the Postgres transaction log, 0 if this node is not the leader.
# TYPE patroni_xlog_location counter
patroni_xlog_location{scope="batman",name="patroni1"} 22320573386952
# HELP patroni_standby_leader Value is 1 if this node is the standby_leader, 0 otherwise.
# TYPE patroni_standby_leader gauge
patroni_standby_leader{scope="batman",name="patroni1"} 0
# HELP patroni_replica Value is 1 if this node is a replica, 0 otherwise.
# TYPE patroni_replica gauge
patroni_replica{scope="batman",name="patroni1"} 0
# HELP patroni_sync_standby Value is 1 if this node is a sync standby replica, 0 otherwise.
# TYPE patroni_sync_standby gauge
patroni_sync_standby{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_received_location Current location of the received Postgres transaction log, 0 if this node is not a replica.
# TYPE patroni_xlog_received_location counter
patroni_xlog_received_location{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_replayed_location Current location of the replayed Postgres transaction log, 0 if this node is not a replica.
# TYPE patroni_xlog_replayed_location counter
patroni_xlog_replayed_location{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_replayed_timestamp Current timestamp of the replayed Postgres transaction log, 0 if null.
# TYPE patroni_xlog_replayed_timestamp gauge
patroni_xlog_replayed_timestamp{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_paused Value is 1 if the Postgres xlog is paused, 0 otherwise.
# TYPE patroni_xlog_paused gauge
patroni_xlog_paused{scope="batman",name="patroni1"} 0
# HELP patroni_postgres_streaming Value is 1 if Postgres is streaming, 0 otherwise.
# TYPE patroni_postgres_streaming gauge
patroni_postgres_streaming{scope="batman",name="patroni1"} 1
# HELP patroni_postgres_in_archive_recovery Value is 1 if Postgres is replicating from archive, 0 otherwise.
# TYPE patroni_postgres_in_archive_recovery gauge
patroni_postgres_in_archive_recovery{scope="batman",name="patroni1"} 0
# HELP patroni_postgres_server_version Version of Postgres (if running), 0 otherwise.
# TYPE patroni_postgres_server_version gauge
patroni_postgres_server_version{scope="batman",name="patroni1"} 140004
# HELP patroni_cluster_unlocked Value is 1 if the cluster is unlocked, 0 if locked.
# TYPE patroni_cluster_unlocked gauge
patroni_cluster_unlocked{scope="batman",name="patroni1"} 0
# HELP patroni_postgres_timeline Postgres timeline of this node (if running), 0 otherwise.
# TYPE patroni_postgres_timeline counter
patroni_failsafe_mode_is_active{scope="batman",name="patroni1"} 0
# HELP patroni_postgres_timeline Postgres timeline of this node (if running), 0 otherwise.
# TYPE patroni_postgres_timeline counter
patroni_postgres_timeline{scope="batman",name="patroni1"} 24
# HELP patroni_dcs_last_seen Epoch timestamp when DCS was last contacted successfully by Patroni.
# TYPE patroni_dcs_last_seen gauge
patroni_dcs_last_seen{scope="batman",name="patroni1"} 1677658321
# HELP patroni_pending_restart Value is 1 if the node needs a restart, 0 otherwise.
# TYPE patroni_pending_restart gauge
patroni_pending_restart{scope="batman",name="patroni1"} 1
# HELP patroni_is_paused Value is 1 if auto failover is disabled, 0 otherwise.
# TYPE patroni_is_paused gauge
patroni_is_paused{scope="batman",name="patroni1"} 1
クラスターステータスエンドポイント¶
GET /clusterエンドポイントは、現在のクラスタートポロジと状態を説明するJSONドキュメントを生成します。
$ curl -s http://localhost:8008/cluster | jq .
{
"members": [
{
"name": "patroni1",
"role": "leader",
"state": "running",
"api_url": "http://10.89.0.4:8008/patroni",
"host": "10.89.0.4",
"port": 5432,
"timeline": 5,
"tags": {
"clonefrom": true
}
},
{
"name": "patroni2",
"role": "replica",
"state": "streaming",
"api_url": "http://10.89.0.6:8008/patroni",
"host": "10.89.0.6",
"port": 5433,
"timeline": 5,
"tags": {
"clonefrom": true
},
"lag": 0
}
],
"scope": "demo",
"scheduled_switchover": {
"at": "2023-09-24T10:36:00+02:00",
"from": "patroni1",
"to": "patroni3"
}
}
GET /historyエンドポイントは、クラスターのスイッチオーバー/フェイルオーバーの履歴を表示します。この形式は、pg_walディレクトリ内の履歴ファイルの内容とよく似ています。唯一の違いは、新しいタイムラインがいつ作成されたかを示すタイムスタンプフィールドです。
$ curl -s http://localhost:8008/history | jq .
[
[
1,
25623960,
"no recovery target specified",
"2019-09-23T16:57:57+02:00"
],
[
2,
25624344,
"no recovery target specified",
"2019-09-24T09:22:33+02:00"
],
[
3,
25624752,
"no recovery target specified",
"2019-09-24T09:26:15+02:00"
],
[
4,
50331856,
"no recovery target specified",
"2019-09-24T09:35:52+02:00"
]
]
構成エンドポイント¶
GET /config :動的構成の現在のバージョンを取得します。
$ curl -s http://localhost:8008/config | jq .
{
"ttl": 30,
"loop_wait": 10,
"retry_timeout": 10,
"maximum_lag_on_failover": 1048576,
"postgresql": {
"use_slots": true,
"use_pg_rewind": true,
"parameters": {
"hot_standby": "on",
"wal_level": "hot_standby",
"max_wal_senders": 5,
"max_replication_slots": 5,
"max_connections": "100"
}
}
}
PATCH /config :既存の構成を変更します。
$ curl -s -XPATCH -d \
'{"loop_wait":5,"ttl":20,"postgresql":{"parameters":{"max_connections":"101"}}}' \
http://localhost:8008/config | jq .
{
"ttl": 20,
"loop_wait": 5,
"maximum_lag_on_failover": 1048576,
"retry_timeout": 10,
"postgresql": {
"use_slots": true,
"use_pg_rewind": true,
"parameters": {
"hot_standby": "on",
"wal_level": "hot_standby",
"max_wal_senders": 5,
"max_replication_slots": 5,
"max_connections": "101"
}
}
}
上記のRESTAPI呼び出しは、既存の構成にパッチを適用し、新しい構成を返します。
ノードがこの構成を処理したことを確認してみましょう。まず、5秒ごとにログ行の出力を開始します(loop_wait=5)。/"max_connections/"の変更には再起動が必要なため、/"pending_restart/"フラグを公開する必要があります。
$ curl -s http://localhost:8008/patroni | jq .
{
"pending_restart": true,
"database_system_identifier": "6287881213849985952",
"postmaster_start_time": "2016-06-13 13:13:05.211 CEST",
"xlog": {
"location": 2197818976
},
"patroni": {
"version": "1.0",
"scope": "batman",
"name": "patroni1"
},
"state": "running",
"role": "master",
"server_version": 90503
}
パラメータの削除:
一部の設定を削除(リセット)したい場合は、 null でパッチを適用するだけです。
$ curl -s -XPATCH -d \
'{"postgresql":{"parameters":{"max_connections":null}}}' \
http://localhost:8008/config | jq .
{
"ttl": 20,
"loop_wait": 5,
"retry_timeout": 10,
"maximum_lag_on_failover": 1048576,
"postgresql": {
"use_slots": true,
"use_pg_rewind": true,
"parameters": {
"hot_standby": "on",
"unix_socket_directories": ".",
"wal_level": "hot_standby",
"max_wal_senders": 5,
"max_replication_slots": 5
}
}
}
上記の呼び出しにより、動的構成から postgresql.parameters.max_connections が削除されます。
PUT /config :既存の動的構成の完全な書き換えを無条件に実行することも可能です。
$ curl -s -XPUT -d \
'{"maximum_lag_on_failover":1048576,"retry_timeout":10,"postgresql":{"use_slots":true,"use_pg_rewind":true,"parameters":{"hot_standby":"on","wal_level":"hot_standby","unix_socket_directories":".","max_wal_senders":5}},"loop_wait":3,"ttl":20}' \
http://localhost:8008/config | jq .
{
"ttl": 20,
"maximum_lag_on_failover": 1048576,
"retry_timeout": 10,
"postgresql": {
"use_slots": true,
"parameters": {
"hot_standby": "on",
"unix_socket_directories": ".",
"wal_level": "hot_standby",
"max_wal_senders": 5
},
"use_pg_rewind": true
},
"loop_wait": 3
}
スイッチオーバーおよびフェイルオーバーのエンドポイント¶
切り替える¶
/switchover エンドポイントは、クラスターが正常な場合(リーダーがある場合)にのみ機能します。また、特定の時間にスイッチオーバーをスケジュールすることもできます。
/switchover エンドポイントを呼び出す場合、 /failover エンドポイントとは異なり、候補を指定できますが、必須ではありません。候補者が指定されていない場合、リーダーが退任した後、クラスターの適格なすべてのノードがリーダーレースに参加します。
POST リクエストのJSON本文で、 leader フィールドを指定する必要があります。 candidate フィールドと scheduled_at フィールドはオプションであり、特定の時間にスイッチオーバーをスケジュールするために使用できます。
状況に応じて、リクエストは異なるHTTPステータスコードと本文を返す場合があります。スイッチオーバーまたはフェイルオーバーが正常に完了すると、ステータスコード 200 が返されます。スイッチオーバーが正常にスケジュールされた場合、PatroniはHTTPステータスコード 200 を返します。何か問題が発生した場合、エラーステータスコード( 200 、 200 、または 200 のいずれか)が応答本文の詳細とともに返されます。
DELETE /switchover を使用すると、現在スケジュールされているスイッチオーバーを削除できます。
Example: は、正常なスタンバイへのスイッチオーバーを実行します。
$ curl -s http://localhost:8008/switchover -XPOST -d '{"leader":"postgresql1"}'
Successfully switched over to "postgresql2"
Example: 特定のノードへのスイッチオーバーを実行します
$ curl -s http://localhost:8008/switchover -XPOST -d \
'{"leader":"postgresql1","candidate":"postgresql2"}'
Successfully switched over to "postgresql2"
Example: は、特定の時間にリーダーからクラスター内の他の正常なスタンバイへのスイッチオーバーをスケジュールします。
$ curl -s http://localhost:8008/switchover -XPOST -d \
'{"leader":"postgresql0","scheduled_at":"2019-09-24T12:00+00"}'
Switchover scheduled
フェイルオーバー¶
/failover エンドポイントは、正常なノードがない場合に手動フェイルオーバーを実行するために使用できます(たとえば、すべての同期スタンバイが昇格できるほど正常でない場合は非同期スタンバイに)。ただし、クラスターにリーダーがない必要はありません。正常なクラスターでもフェイルオーバーを実行できます。
POST リクエストのJSON本文で、 candidate フィールドを指定する必要があります。 leader フィールドが指定されている場合、代わりにスイッチオーバーがトリガーされます。
Example:
$ curl -s http://localhost:8008/failover -XPOST -d '{"candidate":"postgresql1"}'
Successfully failed over to "postgresql1"
警告
このエンドポイントを使用する場合は Be very careful を使用します。これにより、特定の状況でデータ損失が発生する可能性があります。ほとんどの場合、 Be very careful は管理者のニーズを満たします。
POST /switchover エンドポイントと POST /failover エンドポイントは、それぞれ POST /switchover と POST /switchover によって使用されます。
DELETE /switchover は DELETE /switchover によって使用されます。
フェイルオーバー |
切り替える |
|
|---|---|---|
リーダーの指定が必要です |
いいえ |
はい |
候補者の指定が必要です |
はい |
いいえ |
一時停止中でも実行可能 |
はい |
はい(特定の候補者にのみ) |
スケジュール可能 |
いいえ |
はい(一時停止中でない場合) |
正常スタンバイ¶
スイッチオーバー中にリーダーレースに参加できるようにする、またはフェイルオーバー/スイッチオーバーの候補としてリーダーになるために、クラスターのメンバーが合格する必要があるチェックがいくつかあります。
PatroniAPI経由でアクセス可能であること。
nofailoverタグがtrueに設定されていません。Watchdogが完全に機能するようにします(構成で必要な場合)。
正常なクラスターでのスイッチオーバーまたは自動フェイルオーバーの場合は、最大レプリケーションラグ(
maximum_lag_on_failovermaximum_lag_on_failover)を超えません。正常なクラスターでのスイッチオーバーまたは自動フェイルオーバーの場合、
check_timelinecheck_timelineがtrueに設定されている場合は、クラスターのタイムラインよりも小さいタイムライン番号を持たないでください。-
スイッチオーバーの場合(候補がある場合とない場合の両方):
/syncキーメンバーにリストされます。正常なクラスターと異常なクラスターの両方でのフェイルオーバーの場合、このチェックは省略されます。
警告
- リーダーのいないクラスターで手動フェイルオーバーが行われる場合、次の場合でも候補者は昇格できます。
同期モードが有効な場合、これは
/syncキーメンバーには含まれません。その遅延が、許容される最大レプリケーション遅延を超えています。
タイムライン番号は、最後に知られているクラスタータイムラインよりも小さいです。
エンドポイントを再起動します¶
POST /restart:POST /restart呼び出しを実行すると、特定のノードでPostgresを再起動できます。POSTリクエストのJSON本文では、オプションでいくつかの再起動条件を指定できます。restart_pending :ブール値、
trueに設定すると、PatroniはPostgreSQL構成に変更を適用するために再起動が保留中の場合にのみPostgreSQLを再起動します。role :ノードの現在のロールがPOSTリクエストのロールと一致する場合にのみ再起動を実行します。
postgres_version :postgresの現在のバージョンがPOSTリクエストで指定されたバージョンよりも小さい場合にのみ再起動を実行します。
timeout :PostgreSQLが接続の受け入れを開始するまで待機する必要がある時間。
primary_start_timeoutをオーバーライドします。schedule :タイムゾーンを含むタイムスタンプ。将来のどこかで再起動をスケジュールします。
DELETE /restart:スケジュールされた再起動を削除します
POST /restart エンドポイントと DELETE /restart エンドポイントは、それぞれ POST /restart と POST /restart によって使用されます。
エンドポイントのリロード¶
POST /reload 呼び出しは、Patroniに構成ファイルを再読み込みして適用するように命令します。これは、 SIGHUP シグナルをPatroniプロセスに送信するのと同じです。再起動が必要なPostgresパラメータの一部( POST /reload など)を変更した場合でも、 POST /restart エンドポイントを呼び出すか、 POST /reload を使用してPostgresを明示的に再起動する必要があります。
リロードエンドポイントは パトロニトルリロード によって使用されます。
エンドポイントを再初期化する¶
POST /reinitialize :指定されたノード上のPostgreSQLデータディレクトリを再初期化します。レプリカ上でのみ実行が許可されます。呼び出されると、データディレクトリが削除され、 pg_basebackup または代替の POST /reinitialize が開始されます。
Patroniが障害が発生したPostgresを回復(再起動)しようとするループに入っている場合、呼び出しは失敗する可能性があります。この問題を解決するには、リクエスト本文に {/"force/":true} を指定します。
再初期化エンドポイントは Patroniの再起動 によって使用されます。