# Введение
> Введение в Patroni, быстрый старт и основные концепции высокой доступности.
---
Индекс LLMS: [llms.txt](/ru/llms.txt)
---
Patroni — шаблон решений высокой доступности (HA) PostgreSQL на Python. Patroni возник как ответвление проекта [Governor](https://github.com/compose/governor) от Compose и содержит множество новых возможностей.
Дополнительные вводные материалы:
- [PostgreSQL HA with Kubernetes and Patroni](https://www.youtube.com/watch?v=iruaCgeG7qs) — доклад Джоша Беркуса на KubeCon 2016 (видео)
- [Публикация в техническом блоге Zalando за февраль 2016 года](https://engineering.zalando.com/posts/2016/02/zalandos-patroni-a-template-for-high-availability-postgresql.html)
--------
## Состояние разработки {#development-status}
Patroni активно разрабатывается и принимает вклады сообщества. Подробнее см. раздел [Участие в разработке](/ru/docs/patroni/contributing_guidelines#contributing_guidelines) ниже.
Сведения о новых выпусках публикуются [здесь](/ru/docs/patroni/releases#releases).
--------
## Технические требования и установка {#technical-requirementsinstallation}
Рекомендации по установке и обновлению Patroni на различных платформах приведены [здесь](/ru/docs/patroni/installation#installation).
--------
## Планирование количества узлов PostgreSQL {#planning-the-number-of-postgresql-nodes}
Узлы Patroni/PostgreSQL отделены от узлов DCS, кроме случая, когда Patroni самостоятельно реализует RAFT, поэтому требований к минимальному количеству узлов нет. Кластер из одного первичного и одного резервного сервера вполне работоспособен. Позднее можно добавить дополнительные резервные узлы.
**Кластеры из 2 узлов** (первичный и резервный сервер) широко распространены и обеспечивают автоматическое переключение при отказе с высокой доступностью. Учтите, что во время переключения избыточность временно отсутствует, пока отказавший узел не присоединится снова.
**Требования к DCS**: для надлежащего консенсуса и отказоустойчивости DCS (etcd, ZooKeeper, Consul) должен работать на **3 или 5 узлах**. Один кластер DCS может хранить сведения о сотнях или тысячах кластеров Patroni с разными сочетаниями пространства имён и области действия.
--------
## Запуск и настройка {#running-and-configuring}
В следующем разделе предполагается, что репозиторий 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](https://www.haproxy.org/), которая даёт приложению единую конечную точку для подключения к лидеру кластера. Для настройки выполните:
> haproxy -f haproxy.cfg
> psql --host 127.0.0.1 --port 5000 postgres
--------
## Конфигурация YAML {#yaml-configuration}
Полные сведения о параметрах etcd, consul и ZooKeeper приведены [здесь](/ru/docs/patroni/config/yaml#yaml). Пример см. в [postgres0.yml](https://github.com/patroni/patroni/blob/master/postgres0.yml).
--------
## Конфигурация через окружение {#environment-configuration}
Полные сведения о настройке и переопределении параметров через переменные окружения приведены [здесь](/ru/docs/patroni/config/env#env).
--------
## Выбор режима репликации {#replication-choices}
Patroni использует потоковую репликацию Postgres, которая по умолчанию асинхронна. В конфигурации асинхронной репликации Patroni можно задать `maximum_lag_on_failover`. Этот параметр не допускает переключение при отказе, если последователь отстаёт от лидера более чем на указанное число байтов. Значение следует повышать или понижать в соответствии с требованиями бизнеса. Для более строгих гарантий долговечности можно также использовать синхронную репликацию. Подробнее см. [документацию по режимам репликации](/ru/docs/patroni/replication_modes#replication_modes).
--------
## Приложения не должны использовать суперпользователей {#applications-should-not-use-superusers}
При подключении из приложения всегда используйте пользователя без прав суперпользователя. Для правильной работы Patroni нужен доступ к базе данных. Использование суперпользователя в приложении может занять весь пул соединений, включая зарезервированные для суперпользователей параметром `superuser_reserved_connections`. Если Patroni не сможет обратиться к первичному серверу из-за заполненного пула, поведение окажется нежелательным.
--------
## Тестирование решения HA {#testing-your-ha-solution}
Тестирование решения HA — длительный процесс со множеством переменных, особенно для кроссплатформенного приложения. Для этой работы нужен подготовленный системный администратор или консультант; подробно рассмотреть её в документации невозможно.
Обязательно протестируйте следующие элементы инфраструктуры:
- Сеть (как сеть перед системой, так и сами физические или виртуальные сетевые интерфейсы)
- Дисковый ввод-вывод
- Ограничения файлов (nofile в Linux)
- RAM. Даже при отключённом oomkiller нехватка RAM может вызвать проблемы.
- CPU
- Конкуренция за ресурсы виртуализации (переподписка гипервизора)
- Любые ограничения cgroup, вероятно связанные с предыдущим пунктом
- `kill -9` любого процесса postgres, кроме postmaster. Это приемлемая имитация ошибки сегментации.
Не следует выполнять `kill -9` для процесса postmaster: это не имитирует реальный сценарий. Если инфраструктура настолько небезопасна, что злоумышленник может выполнить `kill -9`, никакие механизмы HA не исправят ситуацию. Злоумышленник просто снова завершит процесс или нарушит работу иным способом.
---
Обратные ссылки:
- [Преобразование существующего кластера](/ru/docs/patroni/existing_data/)