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

Введение

примечание

Эта страница переведена при помощи нейросети GigaChat.

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

Дополнительную справочную информацию смотрите:

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

Patroni находится в активной разработке и принимает вклад. Подробнее смотрите раздел Внесение вклада ниже.

Информация о новых релизах публикуется здесь.

Технические требования/Установка​

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

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

Узлы Patroni/PostgreSQL отделены от узлов DCS (за исключением случаев, когда Patroni самостоятельно реализует RAFT), поэтому требований к минимальному количеству узлов нет. Запуск кластера, состоящего из одного первичного узла и одного standby, вполне допустим. Позже можно добавить больше standby-узлов.

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

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

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

В следующем разделе предполагается, что репозиторий 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. Эта настройка гарантирует, что failover не произойдет, если реплика отстает от лидера более чем на определенное количество байт. Это значение следует увеличивать или уменьшать в зависимости от бизнес-требований. Также можно использовать синхронную репликацию для более строгих гарантий долговечности. Подробнее смотрите документацию по режимам репликации.

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

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

Тестирование решения высокой доступности​

Тестирование HA-решения — это трудоемкий процесс со множеством переменных. Это особенно верно для кроссплатформенных приложений. Потребуется обученный системный администратор или консультант для выполнения этой работы. Это не то, что можно подробно осветить в документации.

Тем не менее, ниже перечислены компоненты инфраструктуры, которые обязательно следует протестировать:

  • Сеть (сеть перед системой, а также сами сетевые интерфейсы [физические или виртуальные]);
  • Дисковый ввод-вывод;
  • Лимиты файлов (nofile в Linux);
  • ОЗУ. Даже если oomkiller отключен, недоступность ОЗУ может вызвать проблемы;
  • ЦП;
  • Конкуренция виртуализации (переподписка гипервизора);
  • Любые ограничения cgroup (вероятно, связанные с вышеперечисленным);
  • kill -9 любого процесса postgres (кроме postmaster!). Это decent-симуляция segfault.

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