Отказ 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.
