Patroni 4.0 и PostgreSQL 18: тестируем автоматический switchover под нагрузкой и разбираем новый мониторинг кластера

Patroni 4.0 вышел в октябре 2025-го с двумя главными вещами: нативная поддержка PostgreSQL 18 и переработанный механизм switchover. Мы сопровождаем несколько HA-кластеров на Patroni, и обновление прошли на двух из них - не потому что горело, а потому что накопилось достаточно вопросов по поведению switchover под нагрузкой, и 4.0 давал повод их проверить.

Что изменилось в 4.0

Из changelog сразу бросаются в глаза три вещи.

Поддержка PostgreSQL 18. Patroni 3.x с PG18 формально работал, но там были нюансы с определением версии и с некоторыми параметрами, которые появились в PG18 (тот же io_method, которого в 17-й не было). В 4.0 это приведено в порядок: конфигурация PG18-специфичных параметров проходит без ворнингов, REST API отдаёт корректную версию.

Улучшенный switchover. В 3.x при плановом switchover (не аварийном failover, а именно плановой смене primary) кластер иногда вёл себя неприятно под нагрузкой: новый primary мог задержаться с принятием записи на несколько секунд дольше, чем хотелось. В 4.0 доработали порядок шагов - primary сначала дожидается применения всего WAL на целевой реплике, потом только отдаёт роль. Звучит очевидно, но в 3.x это не всегда выдерживалось при высоком темпе записи.

Новые поля в /patroni endpoint. REST API вернул несколько дополнительных полей о состоянии репликации и lag. Мелочь, но наши дашборды это задело.

Как мы тестировали switchover

Один из кластеров - три ноды (primary + два standby), PostgreSQL 17.4, Patroni 3.3. Нагрузка - реальная, OLTP-профиль, пишет несколько приложений. Обновление до Patroni 4.0 само по себе прошло без происшествий: это обновление агента, не Postgres, rolling restart нод занял минуты.

После обновления решили проверить switchover под нагрузкой - не в окно обслуживания, а в рабочие часы при реальном трафике. Риск осознанный, кластер не production первой категории, но живой.

Процедура простая: patronictl -c /etc/patroni.yml switchover --master <текущий-primary> --candidate <целевой-standby> --force. Смотрели на три вещи:

• Время недоступности для записи - промежуток между тем, как старый primary перестал принимать транзакции, и тем, как новый начал.
• Поведение клиентских соединений - у нас PgBouncer перед кластером, HAProxy перед PgBouncer-ами смотрит на healthcheck Patroni.
• Consumer lag на читающих приложениях - реплики в этот момент тоже недоступны на несколько секунд.

Результат: суммарное окно, когда запись была недоступна, оказалось меньше, чем мы видели на Patroni 3.x при аналогичном тесте несколько месяцев назад. Конкретные секунды не называем - это зависит от lag реплики в момент switchover и от железа - но разница ощутимая, и поведение стало предсказуемее. В 3.x бывало, что при высоком темпе WAL время увеличивалось нелинейно; в 4.0 за несколько прогонов такого не видели.

Одно наблюдение: HAProxy с healthcheck по /master endpoint переключился корректно, но с небольшой задержкой относительно фактического switchover - это штатное поведение, healthcheck-интервал у нас 2 секунды. Клиентские соединения через PgBouncer получили ошибку подключения на это окно и переподключились. Приложения, написанные с retry логикой на транзакционных ошибках, это пережили прозрачно. Приложения без retry - нет, но это уже не вопрос Patroni.

Мониторинг: что пришлось поправить

Новые поля в /patroni endpoint - это хорошо, но наши Prometheus-экспортёры брали метрики через patroni_exporter (open-source, не официальный). Старая версия экспортёра просто игнорировала незнакомые поля. Новая версия, совместимая с Patroni 4.0 API, появилась практически одновременно с релизом - обновили, пересобрали.

Что добавили в дашборды после обновления:

• patroni_last_timeline_change_time - метка времени последней смены timeline. В 3.x этого не было в удобном виде; теперь можно видеть на графике когда был последний switchover/failover.
• patroni_replication_lag по каждой реплике - было и раньше, но теперь значение точнее коррелирует с реальным состоянием, потому что 4.0 считает lag иначе при высоком темпе WAL.
• Алерт на долгий lag при switchover. Добавили временной алерт - если switchover идёт больше N секунд, это сигнал что что-то пошло не так. Раньше такого алерта не было, switchover был редкой операцией и мы надеялись на глаза. Теперь автоматика.

Одна неожиданность: в 4.0 поменялся формат поля role в /patroni для случая когда нода в состоянии replica и при этом находится в режиме synchronous_standby. Раньше это было одно строковое значение, теперь там объект. Наш старый парсер в exporter это не обрабатывал - поймали в тесте, а не в production, что хорошо.

Что по PostgreSQL 18

Пока оба обновлённых кластера работают на PG17 - переход на PG18 отдельная история, мы его готовим. Но уже проверили, что Patroni 4.0 корректно поднимает кластер на PG18 RC в тестовом окружении, и что параметры PG18 в postgresql.conf через секцию parameters patroni.yml проходят без проблем. Конфигурация io_method = io_uring принимается и применяется, ворнингов нет.

Где мы сейчас

Patroni 4.0 в нашем случае - это плановое обновление без драмы. Switchover стал чуть предсказуемее, мониторинг потребовал небольшой доработки экспортёра и дашбордов - часа три работы в сумме. Ничего, что заставило бы пожалеть об обновлении.

Если вы сопровождаете HA-кластеры PostgreSQL через Patroni - рекомендуем проверить версию patroni_exporter, который используете: вероятно, потребуется обновление вместе с Patroni 4.0, иначе часть новых метрик просто не придёт.

Кластеры на managed PostgreSQL у нас обновляются планово - следующая волна перейдёт на 4.0 в ноябре после закрытия текущего спринта по тестированию.