REST API Patroni

Patroni имеет богатый REST API, который используется самим Patroni во время выборов лидера, инструментом patronictl для выполнения failover/switchovers/reinitialize/restarts/reloads, HAProxy или любым другим балансировщиком нагрузки для выполнения HTTP-проверок здоровья, и, конечно, также может использоваться для мониторинга. Ниже приведен список конечных точек REST API Patroni.

Patroni предоставляет набор REST API, который используется для выбора ведущего узла (лидера) инструментом 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 /leader: возвращает код состояния HTTP 200, когда узел Patroni имеет блокировку лидера. Основное отличие от двух предыдущих конечных точек в том, что она не учитывает, работает ли PostgreSQL как primary или standby_leader.

• GET /replica?tag_key1=value1&tag_key2=value2: конечная точка проверки реплики. Метод проверяет пользовательские теги key1 и key2 и их соответствующие значения в разделе tags 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 лидера и вычисления задержки на реплике по соображениям производительности. Максимальная задержка указывается в байтах (целое число) или в значениях, удобных для чтения, например 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, если цикл опроса 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": "2024-08-28 19:39:26.352526+00:00",
  "role": "primary",
  "server_version": 160004,
  "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": "4.0.0",
    "scope": "demo",
    "name": "patroni1"
  }
}

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

$ curl -s http://localhost:8008/patroni | jq .

{
  "state": "running",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "role": "replica",
  "server_version": 160004,
  "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": "4.0.0",
    "scope": "demo",
    "name": "patroni1"
  }
}

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

$ curl -s http://localhost:8008/patroni | jq .

{
  "state": "running",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "role": "replica",
  "server_version": 160004,
  "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": "4.0.0",
    "scope": "demo",
    "name": "patroni1"
  }
}

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

$ curl -s http://localhost:8008/patroni | jq .

{
  "state": "running",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "role": "replica",
  "server_version": 160004,
  "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": 1724874295,
  "tags": {
    "clonefrom": true
  },
  "database_system_identifier": "7268616322854375442",
  "patroni": {
    "version": "4.0.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"} 040000
# 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"} 1724873966.352526
# 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_quorum_standby Value is 1 if this node is a quorum standby replica, 0 otherwise.
# TYPE patroni_quorum_standby gauge
patroni_quorum_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"} 160004
# 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"} 1724874235
# 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
# HELP patroni_postgres_state Numeric representation of Postgres state.
# Values: 0=initdb, 1=initdb_failed, 2=custom_bootstrap, 3=custom_bootstrap_failed, 4=creating_replica, 5=running, 6=starting, 7=bootstrap_starting, 8=start_failed, 9=restarting, 10=restart_failed, 11=stopping, 12=stopped, 13=stop_failed, 14=crashed
# TYPE patroni_postgres_state gauge
patroni_postgres_state{scope="batman",name="patroni1"} 5

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

• Конечная точка 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
      },
      {
        "name": "patroni2",
        "role": "replica",
        "state": "streaming",
        "api_url": "http://<IP-Address>:8008/patroni",
        "host": "<IP-Address>",
        "port": 5433,
        "timeline": 5,
        "tags": {
          "clonefrom": true
        },
        "receive_lag": 0,
        "receive_lsn": "0/4000060",
        "replay_lag": 0,
        "replay_lsn": "0/4000060",
        "lag": 0,
        "lsn": "0/4000060"
      }
    ],
    "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 .

{
  "database_system_identifier": "6287881213849985952",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "xlog": {
    "location": 2197818976
  },
  "timeline": 1,
  "dcs_last_seen": 1724874545,
  "database_system_identifier": "7408277255830290455",
  "pending_restart": true,
  "pending_restart_reason": {
    "max_connections": {
      "old_value": "100",
      "new_value": "101"
    }
  },
  "patroni": {
    "version": "4.0.0",
    "scope": "batman",
    "name": "patroni1"
  },
  "state": "running",
  "role": "primary",
  "server_version": 160004
}

Удаление параметров:

• Для удаления (сброса) настройки примените исправление с помощью 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 работает только при работоспособном кластере (наличие ведущего узла). Также позволяет запланировать переключение в заданное время.

При вызове конечной точки /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

Конечная точка /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, когда включен синхронный режим;
• отставание превышает максимально допустимое отставание репликации;
• номер временной шкалы меньше последней известной временной шкалы кластера.

Конечная точка перезапуска

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

• restart_pending: логическое значение, если установлено в true, Patroni перезапускает PostgreSQL только тогда, когда ожидается перезапуск для применения изменений в конфигурации PostgreSQL;

• role: выполнение перезапуска только в том случае, если текущая роль узла совпадает с ролью из запроса POST;

• postgres_version: выполнение перезапуска только в том случае, если текущая версия PostgreSQL меньше указанной в запросе POST;

• timeout: время ожидания перед тем, как PostgreSQL начнет принимать соединения. Переопределяет primary_start_timeout;

• schedule: временная метка с временной зоной для планирования перезапуска в будущем.

• DELETE /restart: удалить запланированный перезапуск

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

Конечная точка перезагрузки

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

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

Конечная точка реинициализации

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

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

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