Спроектируйте стратегию катастрофоустойчивости (DR) для управляемой базы данных критичного сервиса между active-active и active-passive мультирегиональными конфигурациями. Явного единственно верного решения здесь нет — обсудите, какие условия определяют выбор.

Короткий ответ

Выбор между active-active (оба региона принимают запись одновременно) и active-passive (один регион активен, второй — готовый к переключению резерв) зависит от требуемых RPO/RTO, допустимости конфликтов записи и стоимости содержания дублирующей ёмкости; единственно верного ответа нет, решение требует явного обсуждения компромиссов с владельцами бизнес-требований.

Как это работает подробнее

active-passive обычно проще — реплика в другом регионе получает данные асинхронно и «поднимается» только при объявлении аварии, с потенциальной потерей последних не реплицированных транзакций и временем на переключение; active-active требует либо распределённой СУБД с поддержкой мультирегиональной записи, либо явной стратегии разрешения конфликтов при записи в оба региона одновременно, что сильно усложняет модель согласованности данных.

Пример кода

example.txtКопировать

Active-passive: primary (eu-west-1) -> async replica (eu-central-1), promote вручную/по runbook
  RPO: до нескольких секунд потери данных, RTO: минуты на promote + переключение DNS
Active-active: распределённая БД с write-узлами в обоих регионах,
  конфликт-резолюция по last-write-wins или CRDT-подобной схеме
  RPO: ~0, RTO: ~0, но требует пересмотра модели данных приложения

Что использовать на практике

• Рекомендация. для большинства сервисов, где кратковременный простой при аварии приемлем, active-passive с чётко протестированной процедурой failover — разумный баланс стоимости и сложности; active-active оправдан, когда требуется near-zero RTO в обоих регионах одновременно и бизнес готов инвестировать в распределённую архитектуру данных.
• Проверка. выбранная архитектура должна быть подтверждена учебным (game day) тестом реального отказа одного региона с измерением фактических RPO/RTO, а не только проектной оценкой на бумаге.
• Компромисс. active-passive дешевле и проще эксплуатировать, но имеет более высокий RTO/RPO и риск нетестированного failover; active-active даёт лучшую доступность и балансировку нагрузки между регионами, но платит за это операционной сложностью, стоимостью двойной ёмкости и риском проблем консистентности при конфликтующей записи — выбор должен опираться на реальные бизнес-требования к простою и бюджет, а не на «лучшую практику» по умолчанию.

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

• Риск. выбирать active-active «на будущее» без реальной потребности в нулевом RTO, многократно увеличивая сложность системы
• Риск. настраивать active-passive, но никогда не тестировать реальный failover, обнаруживая проблемы процедуры только во время настоящей аварии
• Риск. не фиксировать явно согласованные RPO/RTO с бизнесом перед выбором архитектуры.