Как спроектировать мультирегиональную БД для HA и DR?

Question

IT Interview Practice · Accepted Answer

Реплицируйте базу по регионам и выбирайте топологию по потребности: **active-passive** (один writer, тёплый standby, подхватывающий при failover) для простоты и строгой консистентности, либо **active-active** (несколько writer-ов) для низкой latency записи ценой разрешения конфликтов — затем выбирайте **sync против async репликации**, чтобы обменять durability на latency, и задайте явные цели **RPO/RTO**, управляющие failover.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive против active-active

**Active-passive** имеет один primary, обрабатывающий записи, и standby, которые только читают; при сбое вы **повышаете** standby. Это просто и избегает конфликтов записи, но пассивная ёмкость простаивает, а у failover есть зазор. **Active-active** позволяет каждому региону принимать записи ради локальной latency и без повышения при failover — но два региона могут одновременно править одну строку, поэтому вы *обязаны* разрешать конфликты (last-write-wins, CRDT или merge на уровне приложения). Большинство команд начинают с active-passive; active-active — для глобальной latency записи, которую иначе действительно не достичь.

## Sync против async репликации

Это ключевой компромисс durability/latency. **Синхронная:** primary ждёт подтверждения удалённой реплики перед коммитом — **RPO = 0** (нет потери данных при failover), но каждая запись платит cross-region round-trip latency (~десятки мс), и если реплика недоступна, записи стопорятся. **Асинхронная:** primary коммитит локально и отправляет изменения после — быстрые записи, но потеря региона может потерять последние несколько секунд (**RPO > 0**). Cross-region sync часто слишком медленный, поэтому многие запускают async и принимают малый RPO.

## Failover, RPO и RTO

- **RPO (Recovery Point Objective):** сколько данных вы можете потерять — задаётся sync против async.
- **RTO (Recovery Time Objective):** как долго до восстановления — задаётся тем, как быстро вы обнаруживаете сбой и повышаете.
- Failover = обнаружить (health checks) → повысить standby → перенаправить трафик (DNS/глобальный LB). Автоматизируйте, но защищайтесь от **split-brain** (оба региона считают себя primary) через кворум/fencing-токен.

## Взгляд с точки зрения интервью

Проверка: понимаете ли вы, что HA/DR — это **компромисс между консистентностью, latency и потерей данных**, а не «просто добавить реплику». Хорошо: active-passive со standby. Отлично: вы называете RPO/RTO, следствия sync-против-async и риск split-brain. Ловушка: утверждать, что async даёт нулевую потерю данных, или считать failover мгновенным и без потерь.

## Компромиссы и режимы отказа

- **Split-brain:** сетевой раздел повышает два primary → расходящиеся данные. Используйте кворум, fencing или witness-регион.
- **Failback труден:** после возврата старого primary сверка расходящихся записей ручная и подвержена ошибкам.
- **Стоимость:** истинная мультирегиональность примерно удваивает инфраструктуру и добавляет счета за cross-region egress-трафик.
- **Непротестированный failover отказывает:** DR, который никогда не отрабатывали, не сработает в реальном сбое — проводите game-days.

Active-passive против active-active

Sync против async репликации

Failover, RPO и RTO

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы