Высокая доступность · Восстановление после сбоев

Создано чтобы никогда не отключаться.

Каждый компонент работает горячим. Активный и резервный узлы БД непрерывно реплицируются. Виртуальный IP парит над кластером — keepalived следит за primary, и как только тот перестаёт отвечать, трафик идёт на standby до того, как средний зритель заметит буферизацию. Это не туториал Postgres, прибитый к SaaS — это первоклассная инфраструктура, о которой вашему оператору никогда не нужно думать.

99.999%
Цель уровня сервиса
<30s
Восстановление при failover
3×
Цели репликации
0
Требуемое действие оператора
§ AТопология
Анатомия кластера

Три узла, одна правда.

Пара БД активный/резервный реплицируется по приватной сети. Пара балансировщиков nginx участвует в VRRP для виртуального IP, парящего между ними. Кластер приложения читает через connection pool, который очищается и повторяет при перемещении primary. Каждая связь имеет двойной путь.

Топология · HA-Кластер-0013 nodes · vrrp v3
VIRTUAL IP10.0.0.100● PRIMARYdb-01writes · accepting○ STANDBYdb-02replicating · warmAPP CLUSTERtuse · ott · prism○ LB-Anginx · keepalivedvrrp master○ LB-Bnginx · keepalivedvrrp backupCLIENT TRAFFIC ↑ 12.4M CCV
§ BFailover
Прогулка менее 30 секунд

Что происходит, секунда за секундой.

Когда primary узел отказывает, восстановление происходит в 4 упорядоченных шага. Действие оператора: ноль. Нарушение на стороне клиента: короче TCP retransmit.

T+0s

Heartbeat потерян

Keepalived резервного узла перестаёт получать VRRP-объявления от primary. После 3 пропущенных маяков (~1.5с) standby повышает себя.

Обнаружение · 1.5с
T+2s

Повышение + STONITH

Новый primary огораживает старый узел — выключение через cloud API — и принимает записи. Направление репликации инвертируется; восстановленный узел присоединится как standby.

Повышение · 2с
T+5s

Виртуальный IP мигрирует

VRRP виртуальный IP переходит на NIC нового primary. Connection pool слоя приложения очищается; запросы в полёте повторяются против новой конечной точки.

Миграция VIP · 3с
T+<30s

Стабильное состояние

Сервис восстановлен. Восстановленный узел, когда доступен, синхронизируется и присоединяется как тёплый standby. Записи аудит-журнала записаны. Оператор получает одно уведомление — после факта.

Полное восстановление · 30с
§ CМатрица

Что сохраняется — и что нет.

Чтения
Непрерывные. Standby обслуживает read-реплики во время failover; клиенты никогда не видят прерывания в трафике чтения.
Записи
Кратко приостановлены (< 5 секунд) во время повышения. Записи в полёте повторяются connection pool'ом с ключами идемпотентности.
Сессии пользователей
На основе JWT, stateless. Сессии сохраняются через failover без повторной аутентификации.
Фоновые задачи
Очереди BullMQ поддержаны Redis и переживают failover. Текущие задачи завершаются на новом primary.
Live-потоки
Origin-серверы независимы от базы данных. Приём потока и доставка HLS не затрагиваются.
Панель оператора
Рендерится против нового primary в момент миграции VIP. Аудит-лог показывает событие failover.
§ ∞Поговорите с нами
Пилот управляемого HA-кластера