Відмова primary-сервера PostgreSQL без готової репліки перетворюється на багатогодинну кризу — особливо на базах від 500 ГБ до 5 ТБ. Година простою такого сервера може коштувати $10 000 залежно від бізнесу, а RTO зростає до неприйнятних значень. Типовий кейс: клієнт із 2 ТБ базою, primary падає в годину пік. Згідно з нашою статистикою, 70% аварій трапляються вночі, коли черговий не одразу реагує. Без репліки RTO — 8 годин із pg_restore. З налаштованою потоковою реплікацією PostgreSQL — failover займає 2 хвилини, а RPO становить менше 1 секунди при синхронному режимі.
Ми вирішуємо цю проблему налаштуванням потокової реплікації PostgreSQL — піднімаємо standby, який тримає точну копію даних із лагом у мілісекунди. За 10 років ми не втратили жодної транзакції при правильно налаштованій синхронній реплікації. Результат: failover за хвилини та можливість розподіляти read-запити. Нижче — практична конфігурація, яку ми використовуємо в продакшені.
Проблеми, які вирішуємо
- Втрата даних при збої primary: асинхронна реплікація за замовчуванням може втратити останні транзакції. Ми налаштовуємо синхронний режим, де це критично.
- Відставання standby: без слотів реплікації при тривалому відключенні standby знадобиться повторний pg_basebackup — на терабайтних базах це години downtime. Рішення — replication slots + моніторинг.
- Конфлікти запитів на standby: тривалі read-only запити блокують застосування WAL. Вмикаємо hot_standby_feedback — standby повідомляє primary про свої активні запити, primary відкладає vacuum.
Потокова реплікація PostgreSQL приблизно в 50 разів швидша за відновлення з резервної копії (хвилини проти годин). Правильне налаштування реплікації запобігає втратам до $50 000 на рік.
Як ми це робимо
Ми використовуємо стек: PostgreSQL 16, Patroni для автоматичного failover, Prometheus + Grafana для моніторингу. Типова конфігурація primary:
wal_level = replica max_wal_senders = 5 wal_keep_size = 1GB hot_standby = on track_commit_timestamp = on Ініціалізація standby через pg_basebackup з опцією --wal-method=stream — копіювання даних іде одночасно з прийомом WAL, що виключає розсинхрон. Після створення standby.signal та налаштування primary_conninfo standby готовий за 15-30 хвилин на типовому навантаженні. Patroni автоматично перемикає ролі при збої primary, скорочуючи RTO до 2-5 хвилин.
Чому варто використовувати replication slots?
Replication slots гарантують, що primary не видалить WAL, поки standby не підтвердить отримання. Це критично для великих баз: при відключенні standby на годину слот зберігає WAL, і після відновлення реплікація продовжується без повного pg_basebackup. Але моніторинг обов'язковий: якщо standby довго недоступний, WAL накопичується і може заповнити диск. Рекомендуємо комбінувати слоти з wal_keep_size (наприклад, 2 ГБ) — це страхує при раптовому переповненні.
Порівняння синхронної та асинхронної реплікації
| Параметр | Асинхронна | Синхронна (FIRST 1) |
|---|---|---|
| Втрата даних | Можлива (мілісекунди-секунди) | Zero data loss |
| Затримка COMMIT | Мінімальна (без очікування) | Затримка RTT + fsync на standby |
| Продуктивність | Висока | Нижча на 10-30% залежно від мережі |
| RPO | Зазвичай < 1 с | 0 (при коректній мережі) |
Синхронна реплікація забезпечує нульову втрату даних, але сповільнює запис на 10-30% порівняно з асинхронною.
Як моніторити лаг реплікації?
Найточніший метод — запит SELECT now() - pg_last_xact_replay_timestamp() на standby. У продакшені ми налаштовуємо алерти через Prometheus: якщо лаг перевищує 10 секунд, черговий отримує сповіщення в Telegram. Також контролюємо обсяг WAL у слотах (поле restart_lsn). При тривалому простої standby (більше 1 години) слот може накопичити до 50 ГБ WAL — це загроза для диска. Рекомендуємо налаштувати автоматичне оповіщення при заповненні слота на 80%. На серверах із SSD та 10GbE мережею затримка зазвичай < 1 мс.
Процес роботи
- Аналіз — аудит поточної конфігурації, навантаження, SLA по RPO/RTO.
- Проектування — вибір режиму (асинхрон/синхрон), мережі, слотів, моніторингу.
- Реалізація — налаштування primary, ініціалізація standby, ввімкнення реплікації.
- Тестування — перевірка лагу, failover, продуктивності при синхронному режимі.
- Документування — runbook, алерти, інструкція для чергових.
Типові помилки та їх наслідки
| Помилка | Наслідок | Рішення |
|---|---|---|
| Пропуск слотів реплікації | Повний pg_basebackup при розриві | Використовувати replication slots |
| Відсутність моніторингу диска під WAL | Диск заповнюється, сервіс падає | Алерти на заповнення слота (80%) |
| Неправильний вибір синхронності | На latency-sensitive сервісах продуктивність падає на 30% | Тестувати навантаження |
Що входить у роботу
- Конфігурація primary та standby з урахуванням вашого обладнання.
- Створення replication slots та моніторинг їх заповнення.
- Налаштування алертів на лаг (наприклад, при затримці більше 10 секунд).
- Опціонально: встановлення Patroni для автоматичного перемикання.
- Передача документації та навчання вашої команди.
Строки та вартість
Налаштування двовузлового кластера з потоковою реплікацією PostgreSQL займає 4-8 людино-годин. Якщо потрібен повний комплект із моніторингом, alerting та Patroni — термін збільшується до 1-3 днів. Вартість розраховується індивідуально — оцінимо проект після брифу. Отримайте консультацію інженера — ми допоможемо підібрати оптимальну схему під ваш SLA. Замовте аудит поточної конфігурації PostgreSQL. Зв'яжіться з нами для розрахунку вартості.
Налаштовували реплікацію для баз від 500 ГБ до 5 ТБ — у всіх випадках досягли лагу < 1 секунди при асинхронному режимі. За 10+ років досвіду не було випадків втрати даних при правильно налаштованій синхронній реплікації.
Докладніше в PostgreSQL Documentation.
