Рецепт 20. Тонкий контроль кластеров Postgres через readiness probes

Оригинал: CNPG Recipe 20 — Finer Control of Postgres Clusters with Readiness Probes — 25 июня 2025.

Продолжение Рецепта 19 о пробах: теперь — readiness. Цель та же: гарантировать, что только полностью готовые и догнанные инстансы (особенно реплики) принимают трафик и попадают в кандидаты на promotion.

Что такое readiness probes

Readiness-проба определяет, может ли уже работающий контейнер принимать трафик. В отличие от startup-пробы (отрабатывает один раз при инициализации), readiness работает всю жизнь контейнера — после успешного старта.

Параметры стандартные: failureThreshold, periodSeconds, successThreshold, timeoutSeconds.

Почему это важно для Postgres

Readiness-проба не пускает клиентский трафик на инстансы, которые ещё не готовы: подождать, пока пройдёт recovery, доиграется WAL, реплика догонит источник. В CloudNativePG идея шире: понятие «готов» влияет ещё и на то, может ли реплика стать primary при failover’е.

Дефолтная конфигурация

CloudNativePG задаёт фиксированный дефолт:

failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5

Стратегия по умолчанию — pg_isready. После трёх подряд провалов с шагом в 10 секунд контейнер маркируется как «not ready». Полная кастомизация — через .spec.probes.readiness.

Полная кастомизация

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: freddie
spec:
  instances: 3

  storage:
    size: 1Gi

  probes:
    readiness:
      periodSeconds: 10
      failureThreshold: 6

Каждые 10 секунд, шесть провалов подряд (минута) — и под объявляется «not ready». Настройки применяются одинаково ко всем подам PostgreSQL — независимо от роли primary/standby.

Стратегии

Те же три стратегии, что и в startup-пробах, через .spec.probes.readiness.type:

• pg_isready (по умолчанию) — стандартная проверка готовности слушать соединения.
• query — минимальный SQL-ping в локальную БД postgres.
• streaming — для реплик: «готова» = активно стримит WAL с primary с лагом ≤ maximumLag.

Пример с query:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: freddie
spec:
  instances: 3

  storage:
    size: 1Gi

  probes:
    startup:
      type: query
      periodSeconds: 5
      failureThreshold: 120
    readiness:
      type: query
      periodSeconds: 10
      failureThreshold: 6

Readiness на репликах

Тонкость: для реплик readiness в CloudNativePG влияет ещё и на promotion. Идея — не повышать в primary реплики, которые отстают. Это сохраняет целостность данных при failover’е.

Расширенный пример с синхронной репликацией и streaming-пробой:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: freddie
spec:
  instances: 3

  storage:
    size: 1Gi

  postgresql:
    synchronous:
      method: any
      number: 1

  probes:
    startup:
      type: streaming
      maximumLag: 32Mi
      periodSeconds: 5
      failureThreshold: 120
    readiness:
      type: streaming
      maximumLag: 0
      periodSeconds: 10
      failureThreshold: 6

Readiness-проба отрабатывает каждые 10 секунд, допустимы 6 провалов подряд. maximumLag: 0 — реплики с любым лагом считаются «not ready».

Подводный камень: flapping

При синхронной репликации Postgres ждёт ack хотя бы от одной standby перед COMMIT. На сетях с переменчивой latency (например, между AZ) такая жёсткая readiness-проба может «мигать» (flapping) — реплика быстро переключается между ready/not ready состояниями.

Последствия:

• реплика выпадает из read-сервиса;
• реплика не годится в кандидаты на promotion.

Эффект может быть терпимым, но операционно его нужно понимать. Тюнить под своё окружение и tolerance — обязательно до прод-деплоя.

Главный вывод

Дефолтные пробы хороши для большинства сценариев. Для primary хватает pg_isready, для реплик стоит подумать о более жёстких проверках. Стратегия streaming + maximumLag + синхронная репликация — это мощная связка для чёткой гарантии консистентности и предотвращения promotion отстающей реплики.

Универсального рецепта нет: тюнить нужно по конкретному окружению.

См. также Рецепт 19 (startup), Рецепт 13 и Рецепт 16.