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 гривень на місяць за рахунок запобігання простоям. Зв'яжіться з нами для розрахунку вашого випадку. Замовте консультацію — ми підберемо оптимальну архітектуру під ваш бюджет та вимоги.