Postgres Pro: Архитектура кластеров
Кластер в контексте Postgres Pro представляет собой группу серверов баз данных, работающих совместно для обеспечения непрерывной работы и распределения нагрузки. Основные компоненты кластера:
- Ведущий узел (Leader): основной сервер, принимающий запросы на запись и чтение.
- Ведомые узлы (Followers): реплики, синхронизирующиеся с ведущим узлом и обслуживающие запросы на чтение.
- Распределенная система конфигурации (DCS): обеспечивает координацию между узлами, хранение конфигурации и управление выборами лидера.
- Механизмы репликации: обеспечивают синхронизацию данных между узлами.
Типы кластеров Postgres Pro
1. Кластер с высокой доступностью на основе Patroni
Patroni — это инструмент для управления кластером PostgreSQL с высокой доступностью. Он использует потоковую репликацию и DCS (например, etcd или Consul) для координации узлов.
Особенности:
- Автоматическое переключение роли ведущего узла при сбоях.
- Поддержка синхронной и асинхронной репликации.
- REST API для управления кластером.
- Интеграция с системами мониторинга.
Риски и меры по их снижению:
-
Split-brain: разделение кластера на несколько активных лидеров.
- Меры: использование надежной DCS и настройка кворума для выборов лидера.
- Задержки в репликации: могут привести к устаревшим данным на ведомых узлах.
- Меры: использование синхронной репликации для критичных данных.
2. Встроенная высокая доступность (BiHA)
BiHA — это встроенная в Postgres Pro Enterprise технология для обеспечения высокой доступности без использования внешних инструментов.
Особенности:
- Использование физической потоковой репликации.
- Автоматическое переключение ролей узлов при сбоях.
- Поддержка кворума и выборов лидера.
- Возможность использования ведомых узлов для чтения и резервного копирования.
Риски и меры по их снижению:
-
Сбой лидера: может привести к недоступности записи.
- Меры: настройка автоматического выбора нового лидера и регулярное тестирование сценариев отказа.
- Сетевые сбои: могут нарушить репликацию.
- Меры: использование резервных сетевых каналов и мониторинг состояния сети.
3. Мульти-мастер кластер (Multimaster)
Multimaster — это решение для создания кластера с несколькими активными узлами, каждый из которых может принимать запросы на запись и чтение.
Особенности:
- Синхронная логическая репликация между узлами.
- Использование алгоритма консенсуса (например, Paxos) для разрешения конфликтов.
- Поддержка масштабирования по горизонтали.
Риски и меры по их снижению:
-
Конфликты при записи: одновременные изменения одних и тех же данных на разных узлах.
- Меры: использование механизмов разрешения конфликтов и строгих правил консистентности.
- Сложность настройки: необходимость тщательной конфигурации всех узлов.
- Меры: использование официальной документации и инструментов автоматизации.
Настройка и эксплуатация кластера
1. Инициализация кластера:
- Используйте initdb для создания нового кластера данных.
- Настройте postgresql.conf и pg_hba.conf для обеспечения безопасности и производительности.
2. Настройка репликации:
- Определите тип репликации (синхронная или асинхронная) в зависимости от требований к консистентности и производительности.
- Настройте параметры wal_level, max_wal_senders, hot_standby и другие, связанные с репликацией.
3. Мониторинг и обслуживание:
- Используйте инструменты мониторинга (например, pg_stat_replication, pg_stat_activity) для отслеживания состояния кластера.
- Планируйте регулярные резервные копии с использованием pg_probackup или других инструментов.
- Проводите регулярные проверки и тестирования сценариев отказа для обеспечения готовности к непредвиденным ситуация
Практическое развертывание кластера Postgres Pro с Patroni
Что включает:
- установка Patroni на каждом узле (обычно 3+ узла);
- установка Consul или etcd в качестве DCS;
- настройка systemd-юнитов, чтобы Postgres запускался через Patroni;
- настройка restapi в Patroni для healthcheck;
- настройка HAProxy (или PgBouncer) для балансировки между ведущим и ведомыми узлами.
Совет:
- на каждом узле нужно postgres, patroni, etcd, pgbouncer;
- обязательны firewall-правила между узлами (порты 5432, 2379, 2380, 8008).
PgBouncer и его роль в кластере
Что делает:
- предоставляет единый адрес подключения;
- управляет пулами соединений (особенно важно для 1С и BI);
- снижает нагрузку на Postgres, если приложение открывает слишком много коротких сессий.
Совет:
- используйте режим transaction, а не session;
- настройте перезапуск pgbouncer через patroni callback при failover.
Варианты отказоустойчивости
|
Решение |
Уровень отказоустойчивости |
Особенности |
|---|---|---|
|
Patroni + etcd |
Высокий |
Лидер выбирается автоматически |
|
BiHA (в Enterprise) |
Средний |
Встроен, не требует внешних зависимостей |
|
Multimaster (EOL) |
Высокий (ранее) |
Устарел, не рекомендован к новым внедрениям |
Рекомендация: Patroni — де-факто стандарт, даже в средах с сертифицированной ОС. BiHA подходит для изолированных сред (без доступа к etcd/consul).
Backup и PITR в кластере
Инструменты:
- pg_probackup (с ptrack или без);
- barman (если используете vanilla PostgreSQL);
- custom scripts с basebackup.
Советы:
- делайте бэкапы с ведомой реплики (standby);
- обязательно включите archive_mode = on, wal_level = replica;
- используйте отдельные диски/каталоги под WAL и backup.
Обеспечение консистентности при failover
Проблема:
- приложение может отправить запись в старого лидера, если DNS или прокси не обновился.
Решение:
- используйте vip-manager, keepalived, haproxy или pgbouncer с Patroni callback;
- приложение должно быть чувствительно к кодам read-only transaction.
Масштабирование на чтение
- для BI или отчётности создаются ведомые реплики;
- BI-инструменты направляются на них через read-only connection pool;
- реплики также можно использовать для выполнения pg_probackup, VACUUM, REINDEX.
Кластеры в Kubernetes (Postgres-Operator)
Postgres Pro можно разворачивать в Kubernetes, если использовать:
- Zalando Postgres Operator;
- Crunchy Data Operator (не поддерживает все функции Postgres Pro);
- или кастомные Helm-чарты с StatefulSet + PVC.
Риски:
- не все расширения и подходы совместимы;
- важно работать с CSI-драйверами и PodDisruptionBudget.
Кейсы использования кластеров Postgres Pro
- Резервная БД для 1С: один узел под боевую базу, один — под реплику в отчётах BI.
- DWH в ритейле: Postgres Pro + Patroni, где ETL-загрузка на ведущем, BI — на ведомых.
- Кластер в банке: с полной автоматизацией failover через Patroni + Zabbix + Telegram нотификации.
Тестирование и контроль кластера
- используйте patronictl list, patroni get-config, pg_stat_replication;
- в HAProxy используйте option httpchk GET /patroni;
- проверяйте pg_is_in_recovery() на стороне приложения;
- логируйте все pg_promote, failover, restart через журнал событий.
Чек-лист: готовность к запуску кластера Postgres Pro в прод
1. Архитектура и конфигурация
- Используется 3+ узла (1 master, 2+ replica).
- Включён Patroni, etcd/consul/ZooKeeper или BiHA.
- Установлены pgbouncer или HAProxy для управления подключениями.
- Настроены роли доступа (REPLICATION, monitor, app, admin).
-
postgresql.conf содержит:
- wal_level = replica
- hot_standby = on
- max_wal_senders ≥ количество реплик
- archive_mode = on (если используется PITR)
- У всех узлов корректно работают pg_hba.conf и listen_addresses.
2. Безопасность и доступ
- Включено шифрование соединений (SSL).
- Ограничен доступ к 5432, REST API Patroni и etcd по firewall.
- Все пароли (postgres, replicator, patroni) — в .pgpass или secrets-хранилище.
- Система логирования перенаправлена в journald или rsyslog.
3. Мониторинг и резервное копирование
- Установлен pg_stat_statements, pg_stat_activity, pgpro_stats.
- Установлен pg_probackup, настроены full + ptrack-резервные копии.
- Настроены метрики для Prometheus/Grafana или Zabbix.
- Проверена отправка алертов (например, Telegram, email, webhook).
4. Аварийные сценарии
- Проведено тестирование failover (см. ниже).
- Проверена работа read-only запросов на репликах.
- Убедились, что BI-инструменты умеют переподключаться при смене master.
- Убедились, что после failback реплики автоматически подтягивают WAL.
Тесты отказоустойчивости (failover/failback)
Сценарий 1. Прерывание Master-сервера
Цель: убедиться, что кластер корректно определяет отказ и выбирает нового лидера.
Шаги:
- Отключите ведущий узел:
systemctl stop patroni
или
iptables -A INPUT -p tcp --dport 5432 -j DROP
- Подождите 10–30 секунд и выполните:
patronictl list
Ожидаемый результат:
- Новый лидер выбран.
- Реплики обновили конфигурацию и синхронизацию.
- PgBouncer/Haproxy перенаправили соединения.
Сценарий 2. Split Brain (отказ DCS)
Цель: убедиться, что узлы не принимают решений без quorum.
Шаги:
- Остановите etcd или consul:
systemctl stop etcd
- Попробуйте выполнить команду patronictl switchover.
Ожидаемый результат:
- Команда завершится с ошибкой.
- Никакой failover не произойдет.
Сценарий 3. Потеря реплики
Цель: убедиться, что потеря ведомой реплики не влияет на работу master.
Шаги:
- Остановите реплику:
systemctl stop patroni
-
Проверьте:
- приложение продолжает работать;
- master не переключился;
- нагрузка осталась стабильной.
- Верните реплику в строй:
systemctl start patroni
Ожидаемый результат:
- Реплика подтянулась через WAL.
- Не было переключения ролей.
Сценарий 4. Принудительное переключение лидера (Switchover)
Цель: протестировать управление вручную, как при плановом обновлении.
Шаги:
- Выполните:
patronictl switchover --master old-node --candidate new-node
-
Убедитесь:
- клиент переподключился (pgbouncer/haproxy);
- состояние реплик актуально;
- записи не потеряны.
Сценарий 5. Восстановление кластера из бэкапа
Цель: проверить возможность восстановления после критического отказа.
Шаги:
- Удалите кластер:
rm -rf /var/lib/postgresql/data/*
- Восстановите:
pg_probackup restore --instance main --recovery-target-time='...' --remote-host=...
- Подключите к Patroni или BiHA.
Ожидаемый результат:
- кластер запущен в корректном состоянии;
- WAL-дельта восстановлена;
- приложение снова работает.
Дополнительно: документация и best practices
- Документация Patroni
- Postgres Pro High Availability Guide
- Проверяйте pg_is_in_recovery() при всех переключениях
- Логируйте timeline после switchover для подтверждения правильности работы
Postgres Professional — это российская промышленная СУБД, созданная на базе открытого PostgreSQL, но значительно расширенная для корпоративного применения. В отличие от классического PostgreSQL, решения от Postgres Professional включают в себя поддержку российских ГОСТов и сертификацию ФСТЭК, повышенную надёжность, оптимизации под высоконагруженные системы (в том числе 1С и DWH), инструменты резервного копирования, мониторинга и отказоустойчивости. За платформой стоит команда ядра PostgreSQL в России, что гарантирует актуальность, стабильность и экспертную техническую поддержку 24/7.
Для компаний, которым важно не просто использовать PostgreSQL, а внедрить его на уровне корпоративных стандартов — с гарантией, сопровождением, документированными улучшениями и адаптацией под российское законодательство — Postgres Pro Enterprise становится логичным выбором. Это не просто бесплатная база данных, а полноценный продуктовый стек, совместимый с BI, аналитикой, ERP, 1С и другими системами, в том числе импортозамещёнными.
