Введение

Patroni — шаблон решений высокой доступности (HA) PostgreSQL на Python. Patroni возник как ответвление проекта Governor от Compose и содержит множество новых возможностей.

Дополнительные вводные материалы:

• PostgreSQL HA with Kubernetes and Patroni — доклад Джоша Беркуса на KubeCon 2016 (видео)
• Публикация в техническом блоге Zalando за февраль 2016 года

Состояние разработки

Patroni активно разрабатывается и принимает вклады сообщества. Подробнее см. раздел Участие в разработке ниже.

Сведения о новых выпусках публикуются здесь .

Технические требования и установка

Рекомендации по установке и обновлению Patroni на различных платформах приведены здесь .

Планирование количества узлов PostgreSQL

Узлы Patroni/PostgreSQL отделены от узлов DCS, кроме случая, когда Patroni самостоятельно реализует RAFT, поэтому требований к минимальному количеству узлов нет. Кластер из одного первичного и одного резервного сервера вполне работоспособен. Позднее можно добавить дополнительные резервные узлы.

Кластеры из 2 узлов (первичный и резервный сервер) широко распространены и обеспечивают автоматическое переключение при отказе с высокой доступностью. Учтите, что во время переключения избыточность временно отсутствует, пока отказавший узел не присоединится снова.

Требования к DCS: для надлежащего консенсуса и отказоустойчивости DCS (etcd, ZooKeeper, Consul) должен работать на 3 или 5 узлах. Один кластер DCS может хранить сведения о сотнях или тысячах кластеров Patroni с разными сочетаниями пространства имён и области действия.

Запуск и настройка

В следующем разделе предполагается, что репозиторий Patroni клонирован с https://github.com/patroni/patroni . Потребуются примеры файлов конфигурации postgres0.yml и postgres1.yml. Если Patroni установлен через pip, получите эти файлы из репозитория git и замените ниже ./patroni.py командой patroni.

Для начала выполните следующие команды в разных терминалах:

> etcd --data-dir=data/etcd --enable-v2=true
> ./patroni.py postgres0.yml
> ./patroni.py postgres1.yml

После этого запустится кластер высокой доступности. Проверьте различные параметры файлов YAML и наблюдайте, как меняется поведение кластера. Завершите некоторые компоненты, чтобы увидеть реакцию системы.

Чтобы создать более крупный кластер, добавьте файлы postgres*.yml.

Patroni предоставляет конфигурацию HAProxy , которая даёт приложению единую конечную точку для подключения к лидеру кластера. Для настройки выполните:

> haproxy -f haproxy.cfg

> psql --host 127.0.0.1 --port 5000 postgres

Конфигурация YAML

Полные сведения о параметрах etcd, consul и ZooKeeper приведены здесь . Пример см. в postgres0.yml .

Конфигурация через окружение

Полные сведения о настройке и переопределении параметров через переменные окружения приведены здесь .

Выбор режима репликации

Patroni использует потоковую репликацию Postgres, которая по умолчанию асинхронна. В конфигурации асинхронной репликации Patroni можно задать maximum_lag_on_failover. Этот параметр не допускает переключение при отказе, если последователь отстаёт от лидера более чем на указанное число байтов. Значение следует повышать или понижать в соответствии с требованиями бизнеса. Для более строгих гарантий долговечности можно также использовать синхронную репликацию. Подробнее см. документацию по режимам репликации .

Приложения не должны использовать суперпользователей

При подключении из приложения всегда используйте пользователя без прав суперпользователя. Для правильной работы Patroni нужен доступ к базе данных. Использование суперпользователя в приложении может занять весь пул соединений, включая зарезервированные для суперпользователей параметром superuser_reserved_connections. Если Patroni не сможет обратиться к первичному серверу из-за заполненного пула, поведение окажется нежелательным.

Тестирование решения HA

Тестирование решения HA — длительный процесс со множеством переменных, особенно для кроссплатформенного приложения. Для этой работы нужен подготовленный системный администратор или консультант; подробно рассмотреть её в документации невозможно.

Обязательно протестируйте следующие элементы инфраструктуры:

• Сеть (как сеть перед системой, так и сами физические или виртуальные сетевые интерфейсы)
• Дисковый ввод-вывод
• Ограничения файлов (nofile в Linux)
• RAM. Даже при отключённом oomkiller нехватка RAM может вызвать проблемы.
• CPU
• Конкуренция за ресурсы виртуализации (переподписка гипервизора)
• Любые ограничения cgroup, вероятно связанные с предыдущим пунктом
• kill -9 любого процесса postgres, кроме postmaster. Это приемлемая имитация ошибки сегментации.

Не следует выполнять kill -9 для процесса postmaster: это не имитирует реальный сценарий. Если инфраструктура настолько небезопасна, что злоумышленник может выполнить kill -9, никакие механизмы HA не исправят ситуацию. Злоумышленник просто снова завершит процесс или нарушит работу иным способом.