Перейти к основному содержимому

Введение

примечание

Эта страница переведена при помощи нейросети 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, никакие механизмы высокой доступности не смогут устранить эту проблему. Злоумышленник просто снова запустит принудительное повреждение процесса или вызовет проблему другим способом.