Patroni¶

Patroni — это программное обеспечение с открытым исходным кодом, предназначенное для автоматизации управления отказоустойчивостью и репликацией в кластерах баз данных, в первую очередь PostgreSQL. Оно обеспечивает высокую доступность (High Availability, HA) за счёт автоматического обнаружения сбоев, выбора нового лидера (мастера) и перенаправления трафика на него, используя распределённое хранилище конфигураций (Distributed Configuration Store, DCS), такое как etcd, Consul или ZooKeeper.

¶История

Patroni был создан в 2015 году компанией Zalando (организация признана иноагентом в РФ), которая разрабатывала его для внутренних нужд — обеспечения надёжности и автоматизации управления кластерами PostgreSQL в своей инфраструктуре. Изначально проект был опубликован на GitHub под лицензией Apache 2.0. Основной целью было создание инструмента, который бы упрощал настройку и обслуживание высокодоступных баз данных, снижая время простоя при сбоях.

В 2016 году Patroni стал частью экосистемы PostgreSQL, получив широкое признание сообщества. Проект развивался при участии множества разработчиков, включая сотрудников таких компаний, как Citus Data (позднее приобретена Microsoft), 2ndQuadrant и других. В последующие годы Patroni был адаптирован для работы с различными СУБД, включая MySQL, MariaDB и CockroachDB, но основная его ниша остаётся за PostgreSQL.

¶Архитектура и принцип работы

Patroni работает как демон (фоновый процесс), запускаемый на каждом узле кластера. Он взаимодействует с локальным экземпляром СУБД и распределённым хранилищем конфигураций (DCS). Архитектура Patroni включает несколько ключевых компонентов:

¶Распределённое хранилище конфигураций (DCS)

DCS служит единственным источником истины (single source of truth) для состояния кластера. Patroni использует DCS для хранения информации о текущем лидере, состоянии реплик, параметрах конфигурации и блокировках. Поддерживаемые DCS:

• etcd — наиболее распространённый вариант, используемый в Kubernetes-средах.
• Consul — популярен в инфраструктурах на базе HashiCorp.
• ZooKeeper — классический выбор для распределённых систем.
• Kubernetes Endpoints — встроенная поддержка для работы в кластерах Kubernetes.

¶Механизм выбора лидера (Leader Election)

Patroni реализует алгоритм выбора нового мастера (лидера) при сбое текущего. Процесс включает:

1. Обнаружение сбоя: каждый узел периодически обновляет свою запись в DCS (heartbeat). Если мастер не обновляет запись в течение заданного тайм-аута, он считается недоступным.
2. Голосование: реплики, которые видят отсутствие мастера, пытаются получить блокировку в DCS. Первый узел, успешно захвативший блокировку, становится новым лидером.
3. Повышение реплики: новый лидер переводит свою реплику в режим мастера (например, выполняет pg_ctl promote для PostgreSQL) и начинает принимать запросы на запись.

¶Репликация и синхронизация

Patroni управляет репликацией между узлами. Для PostgreSQL он использует встроенную потоковую репликацию (streaming replication). Patroni автоматически настраивает параметры репликации, такие как primary_conninfo, и следит за тем, чтобы реплики отставали от мастера не более чем на заданное количество байт (lag). При превышении лимита реплика может быть временно исключена из кластера.

¶REST API и управление

Patroni предоставляет REST API на каждом узле для мониторинга и управления кластером. Через API можно:

• Получить текущее состояние кластера (лидер, реплики, задержки).
• Выполнить переключение мастера (switchover) вручную.
• Перезагрузить конфигурацию без остановки сервиса.
• Заблокировать или разблокировать узел для обслуживания.

¶Классификация и виды

Patroni можно классифицировать по нескольким признакам:

¶По типу СУБД

• PostgreSQL — основная и наиболее зрелая поддержка.
• MySQL/MariaDB — экспериментальная поддержка, реализованная через сторонние плагины.
• CockroachDB — поддержка через отдельный драйвер.

¶По способу развёртывания

• На физических серверах или виртуальных машинах — классическая установка через пакетные менеджеры (apt, yum) или из исходных кодов.
• В контейнерах (Docker) — Patroni часто используется в контейнеризированных средах, особенно в Kubernetes, где он интегрируется с операторами.
• В облачных средах — поддержка через облачные API (например, AWS, GCP) для автоматического обнаружения узлов.

¶По режиму работы

• Синхронная репликация — все подтверждения транзакций ждут записи на реплике, что гарантирует нулевую потерю данных (RPO=0) при сбое мастера.
• Асинхронная репликация — мастер не ждёт подтверждения от реплик, что снижает задержки, но может привести к потере данных при сбое.

¶Применение

Patroni широко используется в производственных средах, где требуется высокая доступность баз данных. Основные сценарии применения:

¶Автоматизация отказоустойчивости

Patroni автоматически обрабатывает сбои мастера, что критично для систем с требованиями к времени простоя (SLA). Например, в интернет-магазинах, банковских системах или телекоммуникационных платформах.

¶Управление кластерами в Kubernetes

Patroni является основой для многих операторов PostgreSQL в Kubernetes, таких как zalando-postgres-operator (разработчик — организация, признанная иноагентом в РФ). Он позволяет динамически масштабировать кластеры, добавлять или удалять реплики без ручного вмешательства.

¶Плановое обслуживание

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

¶Мониторинг и диагностика

REST API Patroni используется для интеграции с системами мониторинга, такими как Prometheus, Zabbix или Grafana. Это позволяет отслеживать состояние кластера, задержки репликации и производительность.

¶Примеры использования

¶Пример 1: Кластер из трёх узлов

Типичная конфигурация Patroni для PostgreSQL включает три узла: один мастер и две реплики. При сбое мастера одна из реплик автоматически становится новым мастером. Вторая реплика переключается на нового лидера. Время восстановления (RTO) обычно составляет несколько секунд.

¶Пример 2: Интеграция с Kubernetes

В Kubernetes Patroni часто развёртывается через Helm-чарты. Каждый под (pod) содержит контейнер с Patroni и PostgreSQL. DCS (etcd) также развёртывается в кластере. Patroni автоматически обновляет Endpoints Kubernetes при смене мастера, что позволяет балансировщикам нагрузки (например, HAProxy) перенаправлять трафик.

¶Критика и ограничения

Несмотря на популярность, Patroni имеет ряд недостатков:

• Сложность настройки: для корректной работы требуется глубокое понимание архитектуры PostgreSQL, DCS и сетевых протоколов.
• Зависимость от DCS: сбой в работе etcd или Consul может привести к неработоспособности всего кластера.
• Ограниченная поддержка СУБД: хотя Patroni поддерживает MySQL и MariaDB, эти реализации менее стабильны и документированы по сравнению с PostgreSQL.
• Проблемы с синхронной репликацией: при синхронной репликации производительность мастера может снижаться из-за ожидания подтверждений от реплик.

¶Интересные факты

• Patroni назван в честь магического защитника из вселенной «Гарри Поттера» — патронуса, что символизирует защиту данных.
• Проект Patroni является одним из самых популярных решений для высокой доступности PostgreSQL в мире, с более чем 10 000 звёзд на GitHub.
• В 2020 году Patroni был включён в официальную документацию PostgreSQL как рекомендуемый инструмент для построения отказоустойчивых кластеров.

¶Источники

• Официальная документация Patroni на GitHub.
• Статья «Patroni: High Availability for PostgreSQL» в блоге Zalando (организация признана иноагентом в РФ).
• Руководство по высокой доступности PostgreSQL от PostgreSQL Global Development Group.
• Материалы конференций PGConf и FOSDEM.