Оригинал: CNPG Recipe 19 — Finer Control Over Postgres Startup with Probes — 17 июня 2025.
В CloudNativePG 1.26 появилась расширенная поддержка startup-проб. Это даёт более точный контроль над тем, когда инстанс Postgres считается «стартовавшим», — особенно важно для реплик, которые могут долго догонять primary через WAL replay.
Что такое startup probes
Startup probes появились в Kubernetes 1.20. Они нужны для рабочих нагрузок, которым нужно много времени на инициализацию. Документация описывает их как пробы, которые «откладывают выполнение liveness и readiness до тех пор, пока приложение реально не поднялось».
Конфигурируется через стандартные параметры:
failureThreshold— сколько последовательных провалов считать инициализацию неудачной;periodSeconds— интервал между пробами;successThreshold— сколько успехов нужно подряд;timeoutSeconds— таймаут одной пробы.
Почему это важно для Postgres
Время старта PostgreSQL в HA-сетапах сильно меняется. Recovery и WAL replay — особенно для реплик — могут занимать минуты или больше. Без правильной startup-пробы Kubernetes начинает рестартовать инстансы преждевременно: liveness срабатывает, под убивается, кластер не сходится.
Реализация в CloudNativePG
Два режима конфигурации:
Базовый режим — .spec.startDelay
Поле .spec.startDelay (по умолчанию 3600 секунд) автоматически рассчитывает остальные параметры пробы:
periodSeconds: 10successThreshold: 1timeoutSeconds: 5failureThreshold:startDelay / periodSeconds
То есть startDelay: 3600 даёт запас в час на старт инстанса с шагом проверки в 10 секунд.
Продвинутый режим — .spec.probes.startup
Полный контроль через секцию .spec.probes.startup — там можно прицельно менять каждый параметр и выбирать стратегию пробы.
Стратегии startup-пробы
pg_isready (по умолчанию)
Стандартная утилита PostgreSQL для проверки готовности принимать соединения. Лёгкая, быстрая, проверяет только сетевую готовность.
query
Выполняет минимальный SQL-ping в локальную БД postgres. Это уже не просто «принимаешь соединения», но и «отвечаешь на запросы». Хорошо ловит ситуации, когда сетевой listener поднялся, а внутренние подсистемы ещё не готовы.
streaming (только для реплик)
Самая интересная стратегия. Реплика считается «стартовавшей», только когда:
- активно стримит WAL с primary,
- лаг репликации укладывается в порог
maximumLag(в байтах).
То есть реплика не объявляется готовой, пока реально не догонит источник. Это особенно ценно для отказоустойчивости: при failover’е такая реплика становится primary без неприятных сюрпризов в виде огромного отставания.
Главный вывод
streaming-стратегия заслуживает серьёзного внимания для прод-окружений. Она гарантирует, что реплика достигла осмысленной синхронизации до того, как объявить себя готовой. Это даёт более предсказуемые failover-сценарии и меньше неприятных сюрпризов на стороне приложений после переключения primary.
См. также Рецепт 13 о синхронной репликации и Рецепт 16 про новую опцию dataDurability — вместе со startup-пробами они формируют достаточно богатый набор инструментов для тонкой настройки HA в CloudNativePG.