REST API Patroni

примечание

Эта страница переведена при помощи нейросети GigaChat.

Patroni имеет большой набор REST API, который используется самим Patroni в процессе выбора ведущего узла (лидера) инструментом patronictl для выполнения аварийных переподключений/переинициализации/перезапусков/перезагрузок. Балансировщики нагрузки, такие как HAProxy, используют этот API для выполнения проверок работоспособности по HTTP, а также для мониторинга.

Конечные точки состояния работоспособности

Для всех запросов проверки работоспособности метод GET Patroni возвращает JSON-документ со статусом узла вместе с кодом состояния HTTP. Если получение JSON-документа не требуется, можно использовать методы HEAD или OPTIONS вместо GET.

Следующие запросы к Patroni REST API будут возвращать код состояния HTTP 200 только тогда, когда узел Patroni работает в качестве основного с блокировкой лидера:

• GET /.

• GET /primary.

• GET /read-write.

• GET /standby-leader: возвращает код состояния HTTP 200 только тогда, когда узел Patroni работает в качестве лидера в кластере standby.

• GET /leader: возвращает код состояния HTTP 200, когда у узла Patroni есть блокировка лидера. Основное отличие от двух предыдущих конечных точек заключается в том, что он не учитывает, работает ли PostgreSQL в качестве primary или standby_leader.

• GET /replica: конечная точка проверки состояния реплики. Метод возвращает код состояния HTTP 200 только тогда, когда узел Patroni находится в состоянии running, роль является replica и тег noloadbalance не установлен.

• GET /replica?lag=<max-lag>: конечная точка проверки реплики. В дополнение к проверкам из replica, он также проверяет задержку репликации и возвращает код состояния 200 только тогда, когда она ниже указанного значения. Ключ кластера .last_leader_operation из DCS используется для позиции Wal лидера и вычисления задержки на реплике по причинам производительности. Максимальная задержка может быть указана в байтах (целое число) или в читаемых человеком значениях, например 16 КБ, 64 МБ, 1 ГБ.

  • GET /replica?lag=1048576.
  • GET /replica?lag=1024kB.
  • GET /replica?lag=10MB.
  • GET /replica?lag=1GB.

• GET /replica?tag_key1=value1&tag_key2=value2: конечная точка проверки реплики. Метод также будет проверять пользовательские теги key1 и key2 и их соответствующие значения в разделе теги управления YAML-конфигурацией. Если метка не определена для экземпляра, или если значение в YAML-конфигурации не совпадает со значением запроса, то будет возвращен код состояния HTTP 503.

В следующих запросах, поскольку проверяется статус лидера или резервного лидера, Patroni не применяет ни один из заданных пользователем тегов, и они будут проигнорированы:

• GET /?tag_key1=value1&tag_key2=value2.

• GET /leader?tag_key1=value1&tag_key2=value2.

• GET /primary?tag_key1=value1&tag_key2=value2.

• GET /read-write?tag_key1=value1&tag_key2=value2.

• GET /standby_leader?tag_key1=value1&tag_key2=value2.

• GET /standby-leader?tag_key1=value1&tag_key2=value2.

• GET /read-only: аналогично приведенной выше конечной точке, но включает также первичную.

• GET /synchronous или GET /sync: возвращает код состояния HTTP 200 только тогда, когда узел Patroni работает в качестве синхронной резервной копии.

• GET /read-only-sync: аналогично приведенной выше конечной точке, но включает также первичную.

• GET /asynchronous или GET /async: возвращает код состояния HTTP 200 только тогда, когда узел Patroni работает в качестве асинхронной резервной копии.

• GET /asynchronous?lag=<max-lag> или GET /async?lag=<max-lag>: конечная точка асинхронной проверки готовности. В дополнение к проверкам из asynchronous или async, он также проверяет задержку репликации и возвращает код состояния 200 только тогда, когда она ниже указанного значения. Ключ кластера .last_leader_operation из DCS используется для позиции Wal лидера и вычисления задержки на реплике по причинам производительности. Max-lag может быть указан в байтах (целое число) или в значениях, удобных для чтения человеком, например 16 КБ, 64 МБ, 1 ГБ.

  • GET /async?lag=1048576
  • GET /async?lag=1024kB
  • GET /async?lag=10MB
  • GET /async?lag=1GB

• GET /health: возвращает код статуса HTTP 200 только тогда, когда PostgreSQL включен и работает.

• GET /liveness: возвращает код статуса HTTP 200, если heartbeat loop Patroni работает должным образом, и 503, если последний запуск был более чем ttl секунд назад на основном сервере или 2*ttl на реплике. Может использоваться для livenessProbe.

• GET /readiness: возвращает код статуса HTTP 200 при работе узла Patroni в качестве лидера или при включении и работе PostgreSQL. Эта конечная точка может использоваться для readinessProbe в случаях, когда невозможно использовать конечные точки Kubernetes для выборов лидера (OpenShift).

Обе конечные точки, 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 используется Patroni во время процессе выбора ведущего узла (лидера). Он также может использоваться системой мониторинга. JSON-документ, созданный этой конечной точкой, имеет ту же структуру, что и JSON, создаваемый конечными точками проверки работоспособности.

Пример работоспособного кластера:

$ 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": "{IP-Address}",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "{IP-Address}",
      "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"
  }
}

Пример разблокированной кластерной группы:

$ 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": "{IP-Address}",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "{IP-Address}",
      "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"
  }
}

Пример разблокированной кластерной группы с включенным режимом защиты от повреждения DCS:

$ 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": "{IP-Address}",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "{IP-Address}",
      "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"
  }
}

Пример кластерной группы с включенным режимом паузы:

$ 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": "{IP-Address}",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "{IP-Address}",
      "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"
  }
}

Извлеките показатели Patroni в формате Prometheus через конечную точку GET /metrics:

$ 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://{IP-Address}:8008/patroni",
      "host": "{IP-Address}",
      "port": 5432,
      "timeline": 5,
      "tags": {
        "clonefrom": true
      }
    },
    {
      "name": "patroni2",
      "role": "replica",
      "state": "streaming",
      "api_url": "http://{IP-Address}:8008/patroni",
      "host": "{IP-Address}",
      "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"
    }
  }
}

Приведенный выше вызов REST API изменяет существующую конфигурацию и возвращает новую конфигурацию.

Давайте проверим, что узел обработал эту конфигурацию. Прежде всего он должен начать печатать строки журнала каждые 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. Если узел кластера не указан, все подходящие узлы кластера примут участие в процессе выбора ведущего узла (лидера)после того, как ведущий узел упал.

В теле JSON-запроса POST необходимо указать поле leader. Поля candidate и scheduled_at являются необязательными и могут использоваться для планирования переключения в определенное время.

В зависимости от ситуации запросы могут возвращать разные коды состояния и тела HTTP. Код статуса 200 возвращается при успешном завершении переключения или обхода отказа. Если переключение было успешно запланировано, Patroni вернет код состояния HTTP 202. В случае возникновения проблемы будет возвращен код ошибки (один из 400, 412 или 503) с некоторыми подробностями в ответе.

DELETE /switchover может быть использован для удаления текущего запланированного переключения.

Пример выполнения переключения на любую работающую резервную копию:

$ curl -s http://localhost:8008/switchover -XPOST -d '{"leader":"postgresql1"}'
Successfully switched over to "postgresql2"

Пример выполнения переключения на определенный узел:

$ curl -s http://localhost:8008/switchover -XPOST -d \
        '{"leader":"postgresql1","candidate":"postgresql2"}'
Successfully switched over to "postgresql2"

Пример запланированного переключение с ведущего узла на любой другой работающий резервный узел в кластере в определенное время:

$ curl -s http://localhost:8008/switchover -XPOST -d \
        '{"leader":"postgresql0","scheduled_at":"2019-09-24T12:00+00"}'
Switchover scheduled

Отказоустойчивость

Конечная точка /failover может использоваться для выполнения ручного отказа при отсутствии работающих узлов (например, к асинхронному резерву, если все синхронные резервы недостаточно готовы для продвижения). Однако нет требования, чтобы у кластера не было ведущего узла — обход отказа может быть запущен и на работающем кластере.

В теле JSON-запроса POST необходимо указать поле кандидата. Если указано поле leader, то вместо него срабатывает переключение.

Пример:

$ curl -s http://localhost:8008/failover -XPOST -d '{"candidate":"postgresql1"}'
Successfully failed over to "postgresql1"

Предупреждение

Будьте очень осторожны при использовании этой конечной точки, так как это может привести к повреждению данных в определенных ситуациях. В большинстве случаев, конечная точка переключения удовлетворяет потребностям администратора.

Конечные точки POST /switchover и POST /failover используются соответственно командами patronictl switchover и patronictl failover.

DELETE /switchover используется командой patronictl flush cluster-name switchover.

Сравнение отказоустойчивости/переключения

	Отказоустойчивость	Переключение
Требуется указание лидера	нет	да
Требуется указать кандидата	да	нет
Может быть выполнен в паузе	да	да (только для определенного кандидата)
Может быть запланировано	нет	да (если не в паузе)

Работоспособный резерв

Существует несколько условий, которые узел кластера должен пройти, чтобы иметь возможность участвовать в процессе выбора ведущего узла (лидера) во время переключения или стать ведущим узлом в качестве кандидата на отказоустойчивость/переключение:

• быть доступным через Patroni API;

• не иметь nofailover тега, установленного на true;

• иметь полностью функциональный механизм мониторинга (если требуется – конфигурацией);

• в случае переключения в работоспособном кластере или автоматического отказа, не превышать максимальную задержку репликации (maximum_lag_on_failover параметр конфигурации);

• в случае переключения в работоспособном кластере или автоматического отказа не иметь номер временной шкалы меньше, чем временная шкала кластера, если check_timeline параметр конфигурации установлен на true;

• в синхронном режиме:

  • в случае переключения (как с кандидатом, так и без него) – быть включенным в ключевые составляющие /sync;
  • для отказа в обоих работоспособных и неработоспособных кластерах эта проверка опускается.

Предупреждение

В случае ручного отказа в кластере без лидера кандидат будет допущен к продвижению даже если:

• он не входит в состав ключевых составляющих /sync, когда включен синхронный режим;
• его отставание превышает максимально допустимое отставание репликации;
• у него номер временной шкалы меньше, чем последняя известная временная шкала кластера.

Перезапуск конечной точки

Перезапуск Postgres на определенном узле, выполняется вызовом POST /restart. В теле JSON-запроса POST возможно опционально указать некоторые условия для перезапуска:

• restart_pending: логическое значение, если установлено на true Patroni будет перезапускать PostgreSQL только тогда, когда перезапуск ожидается для применения некоторых изменений в конфигурации PostgreSQL;
• role: выполнять перезапуск только в том случае, если текущая роль узла совпадает с ролью из запроса POST;
• postgres_version: выполнить перезапуск только в том случае, если текущая версия postgres меньше указанной в запросе POST;
• timeout: сколько времени должны ожидать перед тем, как PostgreSQL начнет принимать соединения. Переопределяет primary_start_timeout;
• schedule: временная метка с временной зоной, запланировать перезапуск где-то в будущем.

Удаление запланированного перезапуска выполняется вызовом DELETE /restart.

Конечные точки POST /restart и DELETE /restart используются для patronictl перезапуск и patronictl flush cluster-name перезагрузка соответственно.

Перезагрузка конечной точки

Вызов POST /reload прикажет Patroni перечитать и применить файл конфигурации. Это эквивалентно отправке сигнала SIGHUP процессу Patroni. Если изменить некоторые параметры Postgres, требующие перезапуска (например, shared_buffers), все равно придется явно выполнить перезапуск Postgres, вызвав конечную точку POST /restart или с помощью patronictl перезагрузка.

Конечная точка reload используется программой patronictl перезагрузка.

Повторная инициализация конечной точки

POST /reinitialize: повторная инициализация каталога данных PostgreSQL на указанном узле. Разрешается выполнять только на репликах. После ее вызова будет удален каталог данных и запущен pg_basebackup или какой-то альтернативный метод создания реплики.

Вызов может завершиться неудачей, если Patroni находится в цикле попыток восстановления (перезапуска) сбойного Postgres. Чтобы решить эту проблему, можно указать {"force":true} в теле запроса.

Конечная точка повторной инициализации использует patronictl reinit.