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