Ростовский телеком-провайдер с абонентской базой 180 000 абонентов использовал одиночный PostgreSQL 15 на физическом сервере для биллинга и CRM. Резервирование на уровне СУБД отсутствовало: ночной pg_dump на локальный диск — единственная защита данных. В марте произошёл инцидент: контроллер RAID вышел из строя, массив разрушился, восстановление из дампа заняло 11 часов. 11 часов простоя биллинга означали: новые подключения не оформлялись, платежи абонентов не зачислялись, операторы колл-центра работали вручную. По оценке финансового директора, прямые и косвенные потери составили около 800 000 рублей. После инцидента принято решение построить отказоустойчивый кластер PostgreSQL на базе Patroni с автоматическим фейловером и RPO не более 30 секунд.
Задача клиентаПостроить кластер PostgreSQL 15 + Patroni (3 узла: primary + standby + witness) на новых серверах с NVMe-дисками. RPO не более 30 секунд (синхронная репликация на standby). RTO не более 60 секунд (автоматический фейловер Patroni). Хранить WAL-архив для PITR (Point-In-Time Recovery) 30 дней. Бюджет — 2,8 млн рублей. Серверы в двух разных стойках с разными линиями питания.
Ограничения и требования- Синхронная репликация primary→standby1: гарантирует RPO=0 при переключении на standby1, но снижает пропускную способность записи — нужны быстрые NVMe для компенсации.
- Три узла Patroni (primary + standby + witness/арбитр): предотвращает split-brain без дополнительного etcd-кластера.
- Размещение primary и standby1 в разных стойках с разным питанием: защита от потери питания одной стойки.
- NVMe для WAL и data: задержка IOPS для PostgreSQL при синхронной репликации критична — HDD или SAS SSD не обеспечат нужной производительности.
- 10 GbE для репликации: синхронная репликация 50+ МБ/с требует выделенного порта 10 GbE между primary и standby.
Три сервера 1U с одинаковой конфигурацией: процессор Intel Xeon Silver 4416+, 128 ГБ DDR5 ECC, 2×NVMe 3.84 ТБ (RAID-1 — зеркало) для data, 2×NVMe 1.92 ТБ (RAID-1) для WAL, сетевой адаптер 4×10 GbE (2 порта для репликации, 2 для клиентского трафика). Выбор DDR5 вместо DDR4 продиктован пропускной способностью памяти: PostgreSQL при больших shared_buffers интенсивно использует оперативную память как кеш данных, DDR5 даёт на 30–40% большую пропускную способность по сравнению с DDR4 для подобных нагрузок.
Раздельные NVMe-устройства для WAL и data — ключевое архитектурное решение для производительности PostgreSQL при синхронной репликации. WAL (Write-Ahead Log) — критический путь записи: каждая транзакция ждёт подтверждения записи WAL на диск и на удалённый standby. Размещение WAL на отдельном NVMe-массиве исключает конкуренцию за IOPS между WAL и случайными чтениями data-файлов. Измеренная задержка fsync на NVMe RAID-1: 0,12 мс против 0,8 мс на SAS SSD RAID-10 — в 6,5 раз быстрее на критическом пути записи транзакций.
Patroni + HAProxy + Keepalived для прозрачного фейловера без изменения строки подключения в приложениях биллинга и CRM. HAProxy слушает на виртуальном IP (Keepalived), анализирует роль узлов Patroni через REST API и направляет write-трафик только на текущий primary. При фейловере HAProxy автоматически переключает write-трафик на новый primary через 15–20 секунд после того, как Patroni завершил процедуру переключения. Приложениям не нужно знать, какой именно сервер является primary — они подключаются всегда к одному виртуальному IP.
WAL-архивирование на выделенный NAS для PITR: WAL-сегменты архивируются в real-time на NAS с помощью pgBackRest. Восстановление на любой момент времени в пределах 30 дней — важно для сценариев «случайно удалили таблицу» или «испортили данные batch-скриптом». Полное базовое резервное копирование — еженедельно, инкрементальные резервные копии — ежедневно. Восстановление базы 2,4 ТБ из pgBackRest с delta-restore занимает 40–55 минут против 11 часов в инциденте с pg_dump.
Нагрузочное тестирование нового кластера перед вводом в эксплуатацию проводилось с помощью pgbench: стандартный TPC-B тест с масштабным коэффициентом 500 (эквивалент ~8 млн аккаунтов) показал 14 200 TPS (транзакций в секунду) при задержке P99 4,2 мс. Для сравнения: старый одиночный сервер выдавал 4 800 TPS при задержке P99 18 мс. Почти троекратный рост TPS объясняется прежде всего переходом с SAS SSD RAID-10 на NVMe RAID-1: задержка случайной записи снизилась в 6 раз, что принципиально для биллинговых нагрузок с высокой частотой коротких транзакций.
Мониторинг кластера Patroni настроен через Prometheus + Grafana с набором PostgreSQL-специфичных метрик: lag репликации (target: менее 10 мс в штатном режиме), размер WAL-очереди, TPS и P99-задержка запросов, размер shared_buffers cache hit ratio (target: более 98%). Алерты настроены на три уровня: info (lag репликации превысил 100 мс — наблюдение), warning (lag превысил 500 мс — выяснить причину), critical (primary недоступен более 30 секунд — немедленная эскалация). Такая система мониторинга позволяет обнаруживать деградацию репликации до развития в полноценный инцидент.
Планирование расширения кластера предусмотрено архитектурой с первого дня: четвёртый узел (second standby в другом географическом сегменте сети, в резервном ЦОД) легко добавляется к существующему кластеру Patroni без остановки primary. Когда телеком-провайдер завершит строительство резервного ЦОД, PostgreSQL-кластер получит ещё один узел репликации для географически распределённой защиты данных. Существующие серверы, коммутаторы и NAS останутся в работе без каких-либо изменений — только добавится новый узел. Такая масштабируемость «без переделки» была специально заложена в топологию при первоначальном проектировании.
Состав поставки по подсистемам- Серверы кластера: 3×сервер 1U, Xeon Silver 4416+, 128 ГБ DDR5 ECC, 2×NVMe 3.84 ТБ + 2×NVMe 1.92 ТБ, 4×10 GbE.
- Коммутация: 2×коммутатор 10 GbE 24-port (в разные стойки), 6 патч-кордов DAC 10G 1m, 6 SFP+ 10G SR.
- NAS для WAL-архива: 1×NAS 4U, 24×HDD 8 ТБ, RAID-6, 2×порта 10 GbE.
- Питание: 3×ИБП 1 кВА он-лайн с SNMP, размещены в двух разных стойках.
- День 1–2: Финализация топологии кластера, расположение серверов в стойках, план IP-адресации, счёт.
- День 3–10: Комплектование партии, тест NVMe на производительность IOPS/задержку.
- День 11: Доставка в Ростов-на-Дону.
- День 12–13: Монтаж, кабелирование, BIOS-настройка для производительности PostgreSQL (disable C-states, NUMA topology aware).
Кластер PostgreSQL Patroni запущен и принял первый переключатель фейловера в тестовом режиме: остановка primary-сервера, автоматическое промоутирование standby1 в primary за 48 секунд, хаProxy переключил трафик через 62 секунды — в рамках целевого RTO 60 секунд с небольшим превышением, устранённым настройкой таймаутов HAProxy. Экономия к бюджету составила 10%.
За первые полгода работы кластера произошло одно реальное событие фейловера: плановые работы по замене блока питания в стойке primary-сервера потребовали его перезапуска. Фейловер прошёл в штатном режиме: biлlinг продолжил работу с перерывом 54 секунды. Операторы колл-центра зафиксировали «небольшой кратковременный сбой» вместо 11-часового простоя, как год назад. Ни одного не зачисленного платежа, ни одного не оформленного подключения.
PITR впервые применён через 4 месяца после запуска: разработчик случайно выполнил UPDATE без WHERE в таблице тарифных планов. Восстановление через pgBackRest с PITR на 5 минут до выполнения запроса заняло 52 минуты — против потенциального ручного восстановления 4–8 часов. Данные восстановлены полностью, ни одного абонента с некорректным тарифом.
Почему выбрали нас- Конфигурация серверов оптимизирована под PostgreSQL: раздельные NVMe для WAL и data, DDR5 ECC, 10 GbE для репликации.
- Опыт комплектования кластеров Patroni — рекомендации по сетевой топологии, BIOS-настройкам, размещению по стойкам.
- Полный комплект поставки одним счётом: серверы, коммутаторы, NAS для WAL-архива, ИБП.
- Тест NVMe перед отгрузкой: протокол IOPS и задержки для каждого диска прилагается к поставке.
Данные приведены справочно и не являются публичной офертой. Актуальные цены, наличие и сроки поставки уточняйте при оформлении заказа.