Рецепт 16. Баланс между durability и self-healing в синхронной репликации

Оригинал: CNPG Recipe 16 — Balancing Data Durability and Self-Healing with Synchronous Replication — 26 декабря 2024.

В CloudNativePG 1.25 появилась более тонкая настройка синхронной репликации PostgreSQL — опция dataDurability в .spec.postgresql.synchronous. Она закрывает архитектурный пробел, появившийся в 1.24, и наконец позволяет выбирать: строгая durability или продолжение работы при отказе реплик.

Что было не так в 1.24

В CloudNativePG 1.24 появился новый API для синхронной репликации, но возникла проблема:

• Старый подход (minSyncReplicas / maxSyncReplicas) — приоритет на self-healing: если синхронной реплики нет, оператор автоматически отключал sync-replication, и primary продолжал писать. Высокая доступность ценой возможной потери последних коммитов в DR-сценарии.
• Новый API в 1.24 — приоритет на data durability: PostgreSQL дефолтное поведение, при отсутствии sync-реплики запись подвешивается (COMMIT ждёт). Гарантия RPO = 0 ценой простоя.

Цитата автора:

«Первый вариант обычно нравится платформенным инженерам, ориентированным на self-healing и высокую доступность; второй ближе к ожиданиям DBA от синхронной репликации.»

Из-за такой полярности часть пользователей, опиравшихся на self-healing, не могла мигрировать на новый API без потери поведения.

dataDurability в 1.25

В новой версии в .spec.postgresql.synchronous появилось поле dataDurability с двумя режимами:

• required (значение по умолчанию) — строгая durability, как у нативного PostgreSQL и как в API 1.24.
• preferred — авто-отключение синхронной репликации, если ни одной sync-реплики нет; приоритет — на доступность primary, как в legacy minSyncReplicas / maxSyncReplicas.

Миграция со старого формата

Было (deprecated):

minSyncReplicas: 1
maxSyncReplicas: 1

Эквивалент в новом API с сохранением self-healing-поведения:

postgresql:
  synchronous:
    method: any
    number: 1
    dataDurability: preferred

Если же команда хочет строгую durability (RPO = 0 при любых обстоятельствах) — переключаемся на:

postgresql:
  synchronous:
    method: any
    number: 1
    dataDurability: required

Какой режим выбрать

• preferred — для платформ, где принято жертвовать durability ради доступности (типичные web-приложения, CMS, kibana-style сценарии). Self-healing продолжает работать: при отказе всех реплик primary остаётся доступным на запись.
• required — для финансовых данных, биллинга, критичных аудит-логов, где «потерять последний commit» нельзя ни при каких условиях. При отказе sync-реплик primary остановится — это сознательная цена за RPO = 0.

Связанные материалы

• Рецепт 13 — общий разбор синхронной репликации в CloudNativePG.
• «Делаю мир моей единой точкой отказа на PostgreSQL» — распределённые топологии и replica.primary / replica.source для switchover между регионами.