Что такое Patroni для PostgreSQL?

Ответ

Patroni — это проект с открытым исходным кодом на Python для управления отказоустойчивыми (High Availability) кластерами PostgreSQL. Он не является частью PostgreSQL, а выступает как внешний оркестратор, автоматизирующий репликацию, переключение при отказе (failover) и восстановление (failback).

Ключевые принципы работы:

  1. Распределённое хранилище конфигурации (DCS): Patroni использует etcd, ZooKeeper или Consul как источник истины для хранения состояния кластера (кто мастер, кто реплики, конфигурация). Это предотвращает "split-brain" (ситуацию с двумя мастерами).
  2. Автоматический failover: Если мастер перестаёт отвечать, Patroni на основе консенсуса в DCS автоматически назначает новую мастер-реплику из числа синхронных или асинхронных.
  3. Управление PostgreSQL: Patroni напрямую управляет конфигурационными файлами PostgreSQL (postgresql.conf, pg_hba.conf) и его процессом, запуская/останавливая сервис.

Пример базовой конфигурации patroni.yml для узла:

scope: production-cluster  # Имя кластера
name: pg-node-1            # Уникальное имя узла

restapi:                   # API для управления и мониторинга
  listen: 0.0.0.0:8008
  connect_address: 10.0.1.1:8008

etcd:                      # Настройки DCS
  hosts:
    - 10.0.1.10:2379
    - 10.0.1.11:2379
    - 10.0.1.12:2379

bootstrap:                 # Конфигурация для инициализации нового кластера
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    postgresql:
      use_pg_rewind: true  # Использовать pg_rewind для быстрого восстановления старого мастера
      parameters:
        wal_level: logical
        hot_standby: "on"
        max_wal_senders: 10
        wal_keep_size: 1GB

postgresql:                # Параметры конкретного экземпляра PostgreSQL
  listen: 0.0.0.0:5432
  connect_address: 10.0.1.1:5432
  data_dir: /var/lib/postgresql/14/main
  bin_dir: /usr/lib/postgresql/14/bin

Преимущества в DevOps-практике:

  • Стандартизация: Конфигурация HA-кластера описывается в YAML.
  • Интеграция с оркестраторами: Существуют готовые Helm-чарты для Kubernetes и интеграции с Ansible.
  • Мониторинг через REST API: Легко интегрируется с Prometheus для сбора метрик о состоянии кластера и репликации.

Ответ 18+ 🔞

Давай разжую про эту штуку, Patroni, чтобы было понятно даже тому, кто в PostgreSQL только через pgAdmin заглядывал. Представь, что у тебя есть база данных — королева бала, мастер. И куча её подружек-реплик, которые с неё всё считывают. Всё бы ничего, но мастер — существо нежное, может в любой момент накрыться медным тазом. И тогда начинается ёперный театр: все реплики охуевают, приложения падают, а админы бегают с криками «какого хуя?!», пытаясь вручную назначить новую королеву. Доверия к этому процессу — ноль ебать.

Вот чтобы не было этой рутины, придумали Patroni. Это такой хитрая жопа на Python, которая всё делает за тебя. Она не внутри Постгреса, а снаружи, как надзиратель с умными глазами.

Как эта мартышлюшка работает, если по-простому:

  1. Ей нужен главный свидетель (DCS). Это типа общая тетрадь, куда все узлы смотрят. Используют etcd, ZooKeeper или Consul. В этой тетради записано, кто сейчас главный, а кто — нет. Это чтобы не возникла ситуация «хуй с горы», когда две реплики вдруг решают, что они обе мастера. С тетрадью такой фокус не прокатит — правда одна.

  2. Автоматический разбор полётов (failover). Упал мастер? Patroni, посмотрев в общую тетрадку, сам, без твоего участия, выбирает самую подходящую реплику и говорит: «Всё, чувак, теперь ты главный». И переключает на неё всю нагрузку. Красота.

  3. Полный контроль над PostgreSQL. Patroni — не просто советчик. Она впендюривает нужные настройки прямо в postgresql.conf, управляет запуском и остановкой сервиса. По сути, она им рулит.

Вот как выглядит кусочек её конфига, patroni.yml:

scope: production-cluster  # Имя нашей банды (кластера)
name: pg-node-1            # Моё уникальное имя в этой банде

restapi:                   # Рот, через который Patroni общается с миром (для мониторинга)
  listen: 0.0.0.0:8008
  connect_address: 10.0.1.1:8008

etcd:                      # Адреса тех самых «свидетелей» (DCS)
  hosts:
    - 10.0.1.10:2379
    - 10.0.1.11:2379
    - 10.0.1.12:2379

postgresql:                # Говорим, где наш Постгрес живёт и как к нему стучаться
  listen: 0.0.0.0:5432
  connect_address: 10.0.1.1:5432
  data_dir: /var/lib/postgresql/14/main

И почему это любят в DevOps?

  • Всё как код. Вся эта пиздопроебибна с высокой доступностью описывается в YAML-файлах. Положил в Git — и порядок.
  • Дружит с Kubernetes и Ansible. Для кубера есть готовые Helm-чарты, развернул — и кластер готов. Ебушки-воробушки, да и только.
  • Можно всё промонитьторить. У Patroni есть REST API, из которого Prometheus может тащить метрики: кто мастер, какая задержка репликации и т.д. Больше не надо гадать на кофейной гуще.

Короче, Patroni — это чтобы спать спокойно, а не бздеть каждую ночь, что база ляжет. Она за тебя эту работу и сделает, и проконтролирует. Волнение ебать — на нуле.