Настройка кластера PostgreSQL + Patroni: Полное руководство и выбор лучшего дистрибутива Linux

🔥 Какой дистрибутив Linux лучше для PostgreSQL + Patroni?

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

---

🏆 ТОП-3 дистрибутива для Patroni + PostgreSQL

1️⃣ Debian/Ubuntu (рекомендовано)

✅ Почему?

• 📦 Огромное количество пакетов → PostgreSQL, Patroni, Etcd, HAProxy легко устанавливаются через APT.

• 🔒 Стабильность и безопасность → Обновления не ломают систему.

• 🚀 Простота настройки → Много документации, легко разворачивать.

• 🛠 LTS-поддержка → Ubuntu 22.04 LTS (до 2032 года), Debian 12 (до 2027 года).

📌 Минус:
🔹 Медленный цикл обновлений PostgreSQL (но можно ставить через репозиторий apt.postgresql.org).

🛠 Рекомендация:
🔹 Использовать Ubuntu Server 22.04 LTS или Debian 12.

---

2️⃣ CentOS Stream / AlmaLinux / Rocky Linux

✅ Почему?

• 🔥 Enterprise-уровень стабильности → Многие компании используют в продакшене.

• 🔒 SELinux по умолчанию (дополнительная безопасность).

• 📦 Есть пакеты Patroni, Etcd, PostgreSQL через dnf.

📌 Минус:
🔹 CentOS Stream — rolling-release, может быть нестабильным.
🔹 AlmaLinux/RockyLinux → новые версии PostgreSQL выходят с задержкой.

🛠 Рекомендация:
🔹 Если нужен стабильный RHEL-совместимый дистрибутив → AlmaLinux 9 или Rocky Linux 9.

---

3️⃣ Arch Linux (Manjaro) – для экспертов

✅ Почему?

• ⚡ Самые свежие пакеты PostgreSQL и Patroni.

• 🔧 Гибкость и полная кастомизация.

• 🔥 Rolling-release, всегда свежий софт.

📌 Минус:
🔹 Требует ручной настройки → не рекомендован для продакшена.
🔹 Частые обновления могут сломать PostgreSQL.

🛠 Рекомендация:
🔹 Только для тестов или личных проектов.

---

🔥 Вывод: Что выбрать?

Дистрибутив	Лучший сценарий использования
Ubuntu Server 22.04 LTS	🔥 Рекомендуется! Простота, стабильность, удобная установка.
Debian 12	📦 Отличный выбор для серверов, стабильный, безопасный.
AlmaLinux 9 / Rocky Linux 9	🏢 Идеально для Enterprise, RHEL-совместимость.
CentOS Stream 9	⚠ Можно использовать, но возможны неожиданные обновления.
Arch Linux / Manjaro	🔧 Только для тестов и экспертов.

✅ Лучший вариант для продакшена → Ubuntu 22.04 LTS или Debian 12!

❓ Почему нужен Patroni для PostgreSQL?

PostgreSQL сам по себе не имеет встроенного механизма автоматического failover (переключения лидера при сбоях).
Для высокодоступных кластеров нужны дополнительные инструменты.

🛠 Основные причины использования Patroni:

1. Автоматический failover (переключение лидера при сбоях).

2. Управление репликацией (создание и мониторинг реплик).

3. Обнаружение сбоев (активный мониторинг состояния).

4. Балансировка нагрузки (с HAProxy или PgBouncer).

5. Совместимость с Etcd/Consul/ZooKeeper (распределённое хранилище конфигурации).

---

🚀 Разбор основных проблем PostgreSQL и как их решает Patroni

📌 1. PostgreSQL не поддерживает автоматический failover

• PostgreSQL поддерживает репликацию, но не умеет автоматически переключаться на новую ноду при сбоях.

• Проблема: если primary (лидер) выйдет из строя, клиенты теряют соединение.

• Решение Patroni:
  ✅ Проверяет состояние лидера (через Etcd/Consul).
  ✅ Если лидер "упал" → автоматически выбирает нового лидера.
  ✅ Реплики автоматически переподключаются.

---

📌 2. Проблема "split-brain" (двойной лидер)

• Что это?
  Когда сеть между узлами ломается, две ноды могут считать себя лидерами.

• Чем это опасно?
  🔥 Данные могут разойтись → риск потери информации.

• Как решает Patroni?
  ✅ Использует Etcd как "истину" (DCS) → если нода не записана в Etcd, она не лидер.
  ✅ Если нода "потеряна" → Patroni убьёт PostgreSQL на ней, чтобы предотвратить split-brain.

---

📌 3. Нет удобного управления репликацией

• PostgreSQL поддерживает streaming-replication, но администрировать её сложно.

• Проблема: если лидер "упал", реплики не знают, что делать.

• Решение Patroni:
  ✅ Создаёт реплики автоматически.
  ✅ Автоматически переключает реплики в лидеры.
  ✅ Использует pg_rewind для быстрой синхронизации.

---

📌 4. PostgreSQL не поддерживает динамическое масштабирование

• Без Patroni, добавление новых реплик требует ручной настройки.

• Patroni решает это:
  ✅ Можно просто добавить новую ноду → она автоматически станет репликой.
  ✅ Если лидер "упал" → Patroni сам выберет реплику и продвинет её.

---

📌 5. Клиенты не знают, к кому подключаться при смене лидера

• Когда лидер меняется, IP-адрес нового лидера меняется.

• Проблема: клиентские приложения могут продолжать подключаться к старому (упавшему) лидеру.

• Решение Patroni:
  ✅ Использует HAProxy или PgBouncer, которые автоматически перенаправляют клиентов на активный лидер.
  ✅ haproxy.cfg следит за /master API Patroni и переключает соединение.

---

🔥 Вывод: Зачем нужен Patroni?

Проблема PostgreSQL	Как решает Patroni
❌ Нет автоматического failover	✅ Авто-переключение лидера
❌ Split-brain (двойной лидер)	✅ Контроль через Etcd/Consul
❌ Сложное управление репликацией	✅ Автоматическое управление
❌ Смена лидера ломает подключения	✅ HAProxy перенаправляет клиентов
❌ Нет динамического масштабирования	✅ Легко добавлять реплики

Patroni делает PostgreSQL отказоустойчивым, управляемым и автоматизированным! 🚀 

Настройка кластера PostgreSQL + Patroni включает установку и настройку Patroni, Etcd (или Consul) и HAProxy (опционально). Вот пошаговое руководство:

---

1. Установка необходимых компонентов

Установим PostgreSQL, Patroni, Etcd и (опционально) HAProxy.

Установите PostgreSQL и Patroni:

sudo apt update && sudo apt install -y postgresql postgresql-contrib python3-pip
pip install patroni

Установите Etcd:

sudo apt install -y etcd

Проверьте запуск:

systemctl enable --now etcd
systemctl status etcd

Редактируйте конфигурацию Etcd (/etc/default/etcd или /etc/etcd/etcd.conf):

ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://<IP>:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://<IP>:2379"
ETCD_INITIAL_CLUSTER="node1=http://<IP>:2380,node2=http://<IP>:2380,node3=http://<IP>:2380"
ETCD_INITIAL_CLUSTER_STATE="new"

Перезапустите Etcd:

systemctl restart etcd

---

2. Настройка Patroni на каждом сервере

Создайте конфигурационный файл /etc/patroni.yml:

scope: pg_cluster
namespace: /db/
name: node1

etcd:
  hosts: 192.168.1.1:2379,192.168.1.2:2379,192.168.1.3:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      use_slots: true
  initdb:
    - encoding: UTF8
    - data-checksums
  users:
    admin:
      password: "supersecret"
      options:
        - createrole
        - createdb

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 192.168.1.1:5432
  data_dir: /var/lib/postgresql/15/main
  pg_hba:
    - host replication replicator 0.0.0.0/0 md5
    - host all all 0.0.0.0/0 md5
  replication:
    username: replicator
    password: "replicatorpass"
  parameters:
    wal_level: replica
    hot_standby: "on"
    max_wal_senders: 10
    wal_keep_size: 64

Запустите Patroni:

patroni /etc/patroni.yml

Добавьте в автозапуск:

sudo systemctl enable patroni

---

3. Проверка состояния кластера

Запустите Patroni на всех узлах и проверьте статус:

patronictl -c /etc/patroni.yml list

Если кластер работает корректно, один из узлов должен быть лидером.

---

4. (Опционально) Настройка HAProxy для балансировки нагрузки

Установите HAProxy:

sudo apt install -y haproxy

Добавьте в /etc/haproxy/haproxy.cfg:

frontend postgres
    bind *:5000
    default_backend postgresql

backend postgresql
    mode tcp
    balance roundrobin
    option httpchk GET /master
    server node1 192.168.1.1:5432 check
    server node2 192.168.1.2:5432 check
    server node3 192.168.1.3:5432 check

Перезапустите HAProxy:

sudo systemctl restart haproxy

Теперь клиенты могут подключаться к HAProxy (IP:5000), который автоматически направит запросы к активному лидеру PostgreSQL.

---

Готово!

Теперь у вас настроен отказоустойчивый кластер PostgreSQL с автоматическим failover, управляемый Patroni и Etcd. 🚀

🔹 Patroni и Etcd: Принцип работы и настройка

📌 Patroni и его роль

Patroni — это система управления отказоустойчивым кластером PostgreSQL, обеспечивающая автоматическое переключение лидера (failover) и поддержку реплик.
Он взаимодействует с распределённым хранилищем конфигурации, таким как Etcd, Consul или ZooKeeper, для согласования состояния кластера.

Как работает Patroni?

1. Один сервер становится лидером (primary), другие — репликами (standby).

2. Лидер пишет своё состояние в Etcd.

3. Реплики следят за лидером через Etcd.

4. Если лидер выходит из строя, Patroni автоматически назначает нового лидера и обновляет конфигурацию.

5. При восстановлении прежнего лидера он становится репликой.

---

📌 Etcd и его роль

Etcd — это распределённое, надёжное key-value хранилище, используемое Patroni для хранения информации о состоянии кластера.

Как работает Etcd?

• Каждый узел Patroni записывает своё состояние в Etcd.

• Etcd поддерживает консенсус с помощью алгоритма Raft (решения принимаются большинством узлов).

• При падении лидера новый лидер определяется голосованием.

🔥 Как Patroni выполняет автоматическое переключение (failover) лидера?

Когда текущий лидер PostgreSQL выходит из строя, Patroni использует алгоритм выбора нового лидера. Вот как это происходит пошагово.

---

🚨 1. Обнаружение сбоя лидера

Каждый узел Patroni выполняет периодические проверки состояния (loop_wait, по умолчанию 10 сек).
Лидер обязан обновлять TTL (time-to-live) запись в Etcd. Если он перестаёт обновлять её (например, сервер завис, сеть оборвалась), Patroni понимает, что лидер недоступен.

🔍 Как Patroni обнаруживает сбой?

• Узлы Patroni запрашивают DCS (в нашем случае Etcd) на предмет актуального состояния лидера.

• Если в DCS нет обновлений от лидера в течение ttl (по умолчанию 30 сек) → узлы считают его упавшим.

---

⚖ 2. Начало голосования среди реплик

Когда сбой подтверждён, узлы Patroni инициируют процесс выбора нового лидера.

📌 Алгоритм выбора нового лидера:

1. Реплики анализируют свою лаг-задачу (отставание по журналу WAL).

2. Узел с наименьшим отставанием становится кандидатом.

3. Patroni записывает в Etcd:

   /db/leader → новый_лидер
   

   Это гарантирует, что все узлы знают о новом лидере.

🔍 Как Patroni решает, кто станет лидером?

• Проверяет, какая реплика ближе всего к актуальному WAL-логу.

• Использует use_pg_rewind для синхронизации, если необходимо.

---

⚡ 3. Реплика становится новым лидером

После голосования выбранная реплика превращается в новый primary (лидер):

✅ Выполняется команда:

SELECT pg_promote();

✅ В Patroni логах:

New leader elected: node2

✅ В Etcd запись /db/leader обновляется.

---

🔄 4. Переключение клиентов на нового лидера

После смены лидера:

1. Все другие реплики узнают о новом лидере через Etcd.

2. HAProxy или pgbouncer (если используется) автоматически перенаправляют трафик.

3. Старый лидер (если восстановится) проверяет DCS и становится новой репликой.

---

🛠 Пример симуляции сбоя лидера

Можно проверить, что происходит при падении лидера:

1. Определяем текущего лидера:

   patronictl -c /etc/patroni.yml list
   

2. Останавливаем лидера:

   sudo systemctl stop patroni
   

3. Ждём 30 секунд (ttl).

4. Проверяем, кто стал новым лидером:

   patronictl -c /etc/patroni.yml list
   

Вы увидите, что Patroni выбрал новую ноду как лидера!

---

🎯 Итог: Как Patroni автоматически меняет лидера?

1. Обнаруживает, что лидер "упал" (TTL истёк, проверка не пройдена).

2. Запускает выборы нового лидера (по отставанию WAL).

3. Продвигает реплику в лидеры с помощью pg_promote().

4. Обновляет информацию в DCS (Etcd).

5. Старый лидер (если восстановится) становится репликой.

Эта система позволяет без простоев переключать PostgreSQL-кластер! 🚀