PostgreSQL RTO и RPO: настройка отказоустойчивости с Patroni

Отметим: когда сервис лежит час, а recovery занимает сутки — это катастрофа. Платёжный шлюз, обрабатывающий 10 000 транзакций в минуту, при простое в 30 минут теряет не только выручку, но и доверие клиентов. Средняя стоимость часа простоя для e-commerce — более 1 000 000 рублей. RTO (Recovery Time Objective) и RPO (Recovery Point Objective) — параметры, которые определяют, как быстро вы встанете после сбоя и сколько данных потеряете. Мы настраиваем инфраструктуру PostgreSQL так, чтобы эти метрики соответствовали бизнес-требованиям: от cold standby до multi-region active-active. Наши инженеры имеют более 10 лет опыта в PostgreSQL и более 50 успешных проектов по внедрению отказоустойчивых кластеров.

Какие проблемы решаем

• Неопределённые SLA. Без формальных RTO/RPO вы не можете гарантировать клиентам время восстановления. Штрафы по договорам растут, а репутация страдает.
• Ручное восстановление. При сбое администратор вручную поднимает реплику — это часы простоя. Автоматический failover сокращает RTO до секунд.
• Потеря данных. Редкие бэкапы (раз в сутки) означают RPO = 24 часа. При сбое вы теряете дневные транзакции. WAL-архивирование каждые 5 минут снижает RPO до 5 минут.
• Избыточные затраты. Погоня за нулевым RTO без анализа бизнеса приводит к переплате. Мы помогаем найти баланс стоимость/надёжность.

Как определить RTO и RPO для вашего бизнеса?

Первый шаг — оценка стоимости простоя. Используем простой калькулятор:

class RtoCalculator: def calculate_downtime_cost(self, hourly_revenue, churn_per_hour, penalty, clv, customers): costs = { 'lost_revenue': hourly_revenue, 'churn': (churn_per_hour/100)*customers*clv, 'sla_penalties': penalty, 'labor': 500 } total = sum(costs.values()) if total > 100000: return '< 5 min (active-active)' elif total > 10000: return '< 15 min (hot standby)' else: return '< 1 h (warm standby)' 

Почему Patroni — лучший выбор для PostgreSQL?

Patroni с etcd обеспечивает failover за 30 секунд — в 10 раз быстрее ручного восстановления. Он управляет конфигурацией, автоматически переключает трафик и не теряет данные при правильной настройке синхронной репликации. Это стандарт для High Availability в PostgreSQL.

Как мы это делаем

Кейс: Корпоративная CRM на PostgreSQL 15. Требовались RTO < 30 минут и RPO < 5 минут. Развернули Patroni на трёх нодах, pgBackRest для WAL-архивирования в S3, HAProxy для маршрутизации. После тестового сбоя (kill primary) failover занял 18 секунд, потеря данных — 0 (синхронная репликация). Документация по восстановлению была передана команде.

# postgresql.conf wal_level = replica archive_mode = on archive_command = 'pgbackrest --stanza=main archive-push %p' checkpoint_timeout = 5min max_wal_senders = 10 wal_keep_size = 1GB # pgbackrest.conf [global] repo1-type=s3 repo1-s3-bucket=myapp-wal-archive repo1-retention-full=4 repo1-retention-diff=14 [main] pg1-path=/var/lib/postgresql/data 

Patroni: автоматический failover (RTO < 30 сек)

# patroni.yml scope: postgres-cluster name: pg-node-1 restapi: listen: 0.0.0.0:8008 etcd3: hosts: etcd1:2379,etcd2:2379,etcd3:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 max_lag_on_failover: 1048576 postgresql: parameters: wal_level: replica hot_standby: on archive_command: 'pgbackrest --stanza=main archive-push %p' 

HAProxy: маршрутизация с учётом роли

frontend postgres_write bind *:5432 default_backend postgres_primary backend postgres_primary option httpchk GET /master server pg-node-1 check port 8008 frontend postgres_read bind *:5433 default_backend postgres_replicas backend postgres_replicas balance roundrobin option httpchk GET /replica server pg-node-1 check port 8008 

Как мониторить RTO/RPO?

Мониторинг — ключ к соблюдению SLA. В таблице приведены метрики, которые нужно отслеживать:

Настраиваем Prometheus + alertmanager. При нарушении RPO дежурная команда получает уведомление. Это позволяет реагировать до того, как сбой повлияет на бизнес.

Что делать при нарушении RPO?

Типичные ошибки при проектировании отказоустойчивости:

• Отсутствие тестов failover. Мы проводим хаос-инжиниринг: симулируем отказ ноды, сети, диска. Только так можно подтвердить реальные RTO/RPO.
• Игнорирование задержек репликации. При синхронном режиме latency между дата-центрами не должна превышать 10 мс.
• Неправильная ротация бэкапов. pgBackRest с retention (full/diff) гарантирует, что старые бэкапы не перезаписываются. Восстановление на любую точку во времени.

Мы составляем чек-лист для дежурных: действия при сбое, порядок promotion, контакты вендора.

Процесс работы

1. Аудит — инвентаризация текущей инфраструктуры, нагрузка, бюджет.
2. Расчёт — определяем целевые RTO/RPO вместе с вами.
3. Проектирование — выбираем архитектуру (Patroni + etcd, pgBackRest, HAProxy).
4. Реализация — развёртывание, конфигурация, тестирование failover.
5. Тест — симулируем сбои, измеряем реальные RTO/RPO.
6. Документация и обучение — runbook по инцидентам, обучение дежурных.

Что входит в настройку под ключ

• Настройка Patroni с etcd/Consul для автоматического failover
• pgBackRest — full/differential backup, WAL-архивирование в S3 или локальное хранилище
• HAProxy — интеллектуальная маршрутизация (write/read split)
• Мониторинг — Prometheus экспортер для lag, алерты при нарушении RPO
• Документация — план восстановления, конфиги, проверочные листы
• Обучение — 2 часа workshop для вашей команды

Сроки и гарантии

Настройка под ключ для типового кластера (3 ноды) занимает 3–5 рабочих дней. Результат — достижение целевых RTO/RPO, подтверждённое нагрузочным тестированием. Мы сертифицированные инженеры с более чем 10 годами опыта в PostgreSQL. Гарантируем SLA на время восстановления.

Экономия от внедрения автоматического failover может составлять от 100 000 до 500 000 рублей в месяц за счёт предотвращения простоев. Свяжитесь с нами для расчёта вашего случая. Закажите консультацию — мы подберём оптимальную архитектуру под ваш бюджет и требования.