Введение
Эта страница переведена при помощи нейросети GigaChat.
Patroni – это шаблон для решений PostgreSQL с высокой доступностью (HA) с использованием Python. Patroni изначально был частью проекта Governor от Compose. Он включает в себя новые функции.
Для примера развертывания на основе Docker с использованием Patroni смотрите Spilo, который в настоящее время используется в Zalando.
Для получения дополнительной справочной информации смотрите:
Для максимальной доступности Patroni поддерживает различные распределенные хранилища конфигурации, такие как ZooKeeper, etcd, Consul или Kubernetes. Инженеры баз данных, администраторы баз данных, инженеры DevOps и SRE, которые хотят быстро развернуть HA PostgreSQL в центрах обработки данных, или где-либо еще – найдут его полезным.
В документации Patroni называется «шаблоном», потому что он далек от того, чтобы быть универсальной системой репликации или подключаемым модулем. У него будут свои особенности. Используйте с умом. Существует множество способов обеспечения высокой доступности с помощью PostgreSQL (подробнее см. документацию по PostgreSQL).
В настоящее время поддерживаются следующие версии PostgreSQL: с 9.3 до 16.
Примечание (для пользователей Citus):
Начиная с версии 3.0, Patroni прекрасно интегрируется с расширением базы данных Citus для PostgreSQL. Пожалуйста, ознакомьтесь со страницей поддержки Citus в документации Patroni для получения дополнительной информации о том, как использовать высокую доступность Patroni вместе с кластером Citus.
Примечание (для пользователей Kubernetes):
Patroni может работать непосредственно поверх Kubernetes. Ознакомьтесь с главой Kubernetes в документации Patroni.
Состояние разработки
Patroni активно развивается и принимает сообщения об ошибках. Смотрите раздел Инструкция по тестированию для получения дополнительной информации.
Технические требования/Установка
Перейдите в раздел «Установка» для получения инструкций по установке и обновлению Patroni на различных платформах.
Планирование количества узлов PostgreSQL
Узлы Patroni/PostgreSQL отделены от узлов DCS (за исключением случаев, когда Patroni реализует RAFT самостоятельно), поэтому нет требований к минимальному количеству узлов. Запуск кластера, состоящего из одного основного и одного резервного узла, вполне приемлем. Можно добавить больше резервных узлов позже.
Запуск и настройка
Следующий раздел предполагает, что репозиторий 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 использует потоковую репликацию PostgreSQL, которая по умолчанию является асинхронной. Асинхронная конфигурация репликации Patroni позволяет использовать настройки maximum_lag_on_failover. Эта настройка гарантирует, что отказ не произойдет, если ведомый узел отстает от ведущего более чем на определенное количество байтов. Это значение следует увеличивать или уменьшать в зависимости от требований бизнеса. Возможно использование синхронной репликации для получения лучших гарантий устойчивости. Смотрите документацию о режимах репликации для подробностей.
Приложения не должны использовать суперпользователей
При подключении из приложения всегда используйте не суперпользователя. Patroni требует доступа к базе данных для правильной работы. Используя суперпользователя из приложения, можно использовать весь пул соединений, включая соединения, зарезервированные для суперпользователей, с настройкой superuser_reserved_connections. Если Patroni не может получить доступ к первичной системе, потому что пул соединений заполнен, поведение будет нежелательным.
Тестирование решения высокой доступности
Тестирование решения высокой доступности – это трудоемкий процесс со многими переменными. Это особенно актуально, учитывая межплатформенное приложение. Вам нужен обученный системный администратор или консультант, чтобы выполнить эту работу. Это не то, что мы можем подробно рассмотреть в документации.
Тем не менее вот некоторые части используемой инфраструктуры, которые необходимо обязательно протестировать:
- Сеть (сеть перед используемой системой, а также сами сетевые интерфейсы (физические или виртуальные)).
- Ввод-вывод диска.
- Ограничения файлов (nofile в Linux).
- Оперативная память. Если отключен oomkiller, отсутствие оперативной памяти может вызвать проблемы.
- Процессор.
- Конкуренция виртуализации (перераспределение гипервизора).
- Любое ограничение cgroup (скорее всего, связано с вышеупомянутым)
- Принудительное завершение любого процесса postgres (кроме postmaster!) с использованием команды
kill -9. Это довольно точная симуляция нарушения работы сегмента.
Нельзя запускать принудительное завершение процесса postmaster с использованием команды kill -9. Это действие не имитирует ни одну реальную ситуацию. Если есть опасения, что инфраструктура уязвима и злоумышленник может спровоцировать аварийное прекращение процесса с помощью команды kill -9, никакие механизмы высокой доступности не смогут устранить эту проблему. Злоумышленник просто снова запустит принудительное повреждение процесса или вызовет проблему другим способом.