PATRONI_HA_CLUSTER_FAIL 1С:Предприятие и СУБД

Отказоустойчивый кластер PostgreSQL: настройка Patroni и etcd

Обновлено: 26.08.2026 · Официальная документация ↗

Кластер Patroni переходит в состояние Leader lock lost и разжалует Primary ноду (demote).
Ошибка DCS is not accessible: потеря связи с распределенным хранилищем etcd.
Реплики не могут войти в кластер из-за рассинхронизации таймлайнов после автоматического failover.

1. Базовая конфигурация ноды /etc/patroni/patroni.yml

scope: pg-cluster
namespace: /service
name: pg-node1

dcs:
  ttl: 30
  loop_wait: 10
  retry_timeout: 10
  maximum_lag_on_failover: 1048576 # 1MB
  etcd3:
    hosts:
      - 192.168.1.21:2379
      - 192.168.1.22:2379
      - 192.168.1.23:2379

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 192.168.1.11:5432
  data_dir: /var/lib/postgresql/16/main
  bin_dir: /usr/lib/postgresql/16/bin
  pgpass: /var/lib/postgresql/.pgpass
  authentication:
    replication:
      username: replicator
      password: ReplicatorPassword123
    superuser:
      username: postgres
      password: SuperuserPassword123

restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.11:8008

2. Управление и диагностика кластера через patronictl

# Просмотр топологии и статуса всех нод кластера
patronictl -c /etc/patroni/patroni.yml list

# Ручной контролируемый Switchover без простоя
patronictl -c /etc/patroni/patroni.yml switchover

# Переинициализация сбойной ноды после аварии
patronictl -c /etc/patroni/patroni.yml reinit pg-cluster pg-node2

3. Проверка здоровья кластера etcd

etcdctl endpoint health --endpoints=http://192.168.1.21:2379,http://192.168.1.22:2379,http://192.168.1.23:2379
etcdctl endpoint status --write-out=table

💡 Практика специалистов: Разворачивайте ноды etcd строго на нечетном количестве серверов (минимум 3) и изолируйте их от дисковой активности PostgreSQL, так как задержки ввода-вывода etcd (fsync) могут вызвать ложный делистинг лидера Patroni.

Частые вопросы (FAQ)

Как Patroni защищает кластер от Split-Brain при сетевом разделении?

Patroni использует кворум распределенного консенсуса etcd/Consul. Лидер обязан регулярно обновлять свою аренду (Leader Lock TTL). Если связь с большинством нод etcd потеряна, лидер самостоятельно перезапускает PostgreSQL в режиме Read-Only (демоут).

Зачем перед кластером Patroni ставят балансировщик HAProxy?

HAProxy опрашивает REST API Patroni на порту 8008: эндпоинт /primary возвращает HTTP 200 только для текущего мастера, а /replica — для ведомых нод, обеспечивая прозрачную маршрутизацию клиентских запросов.

Что произойдет, если реплика отстает больше значения maximum_lag_on_failover?

Patroni запретит автоматический промоут (выбор в качестве нового лидера) такой отставшей реплики, предотвращая потерю данных при аварии старого мастера.

Как временно отключить авто-фейловер на время проведения регламентных работ?

Переведите кластер в режим обслуживания (Pause Mode): patronictl -c /etc/patroni/patroni.yml pause.