Multi-AZ vs Read Replica — в чём разница?

Сравнительная таблица

Характеристика        Multi-AZ (classic)    Read Replica
------------------------------------------------------------
Цель                  HA / failover         Read scaling / DR
Репликация            Синхронная            Асинхронная
Lag                   Нет (sync)            Есть (sec–min)
Доступен для чтений   Нет (standby)         Да
Auto failover         Да (DNS flip)         Нет (ручное promote)
Cross-region          Нет                   Да
Cost                  +100% инстанса        +100% инстанса

Multi-AZ vs Read Replica: разные цели

Обе фичи создают вторую копию базы данных, но решают принципиально разные задачи. Multi-AZ — это High Availability (HA): защита от отказа инфраструктуры с автоматическим failover. Read Replica — это Read Scaling и иногда DR: снижение нагрузки на primary за счёт направления SELECT-запросов на реплику.

Multi-AZ

• Для классического RDS (non-Aurora): синхронная репликация на standby instance в другой AZ. При failover AWS меняет DNS CNAME primary endpoint на standby — обычно за 60–120 секунд.
• Standby недоступен для чтения приложением в классическом варианте. Он существует только для failover.
• Multi-AZ DB Cluster (новый вариант, 2022+) создаёт 2 readable standbys — это уже другая модель, нужно уточнять о каком варианте идёт речь.
• Backups и maintenance могут выполняться на standby, не влияя на primary.

Read Replica

• Асинхронная репликация WAL (PostgreSQL) или binlog (MySQL). Есть replication lag — от миллисекунд до минут при тяжёлой нагрузке.
• Приложение должно явно направлять read-only запросы на replica endpoint — автоматического роутинга нет.
• Read Replica можно promoted до standalone instance (DR или миграция), но это разрывает репликацию и требует ручного переключения.
• Поддерживает cross-region repliaction — полезно для disaster recovery с приемлемым RPO.

Aurora: другая модель

• Aurora replicas разделяют cluster storage с primary — lag минимален (обычно <10 мс).
• Reader endpoint балансирует трафик по всем replicas автоматически.
• При failover primary Aurora продвигает одну из replicas — занимает ~30 с.
• Aurora Global Database даёт cross-region replication с RPO <1 с.

Пример: создание Read Replica через AWS CLI

# Создать read replica для RDS PostgreSQL в другом регионе
aws rds create-db-instance-read-replica \
  --db-instance-identifier my-pg-replica \
  --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:my-pg-primary \
  --db-instance-class db.r6g.large \
  --region eu-west-1

# Проверить replication lag (в секундах) через CloudWatch
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=my-pg-replica \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-01T01:00:00Z \
  --period 60 \
  --statistics Average

Подводные камни

• Попытка читать с классического RDS Multi-AZ standby — он не имеет публичного endpoint и не принимает соединений от приложения.
• Read Replica с высоким lag нарушает read-after-write consistency: пользователь пишет данные и сразу читает старую версию с реплики.
• DNS caching при failover: если connection pool или приложение кэширует DNS дольше TTL (обычно 5 с для RDS), failover будет невидим долго — нужна явная настройка useDnsCache=false или аналог.
• Promoted read replica становится standalone — она не присоединяется автоматически к Multi-AZ; нужно вручную настроить HA для нового primary.
• Multi-AZ и Read Replica не исключают друг друга: production-паттерн — Multi-AZ primary + несколько read replicas.
• Maintenance window и automated backups на Multi-AZ standby снижают влияние на primary, но не устраняют его полностью.

• Использовать RDS standby для чтения.
• Считать read replica синхронной HA-копией.
• Не учитывать replication lag и app routing.

• Отличает availability от read scaling.
• Понимает standby/read replica usage.
• Учитывает failover behavior и replication lag.