Ключевые выводы:

🔵Два ДЦ — это не «минус один от трёх». В такой топологии нельзя опереться на большинство, значит классические подходы из трёх площадок не работают «как есть».

🔵Асинхронная репликация с одним мастером требует аккуратной смены ролей: при лаге чтения возникают «хвосты» неподтверждённых операций, поэтому назначение нового мастера без строгого протокола чревато расхождением журналов.

🔵Active‑Standby схема, которую можно реализовать исключительно в двух датацентрах. Будучи простой для реализации, она позволяет фейловеру на уровне кластера Tarantool Cluster Federation обеспечивать быстрое переключение, при этом явно локализуя нагрузку в пределах одного кластера в одном DC.

🔵Внешний супервизор: к каждому узлу базы данных добавляется сервис-обертка, который захватывает лок во внешнем кворуме и начинает перевод в RW. Подход обеспечивает быстрое переключение в случае сбоя master узла. Решение особенно удачное в ситуациях, когда вы не code-owner ни СУБД, ни бизнес логики.

🔵Внешний координатор с кворумным локом в etcd даёт контролируемый фейловер. Координатор держит лок и объявляет, кто RW, а кто RO; карта кластера позволяет обеспечить мониторинг, консистентное переключение и механизм приоритетов выбора. Подход требует разработки нетривиальных механизмов, таких как fencing token и двухфазное назначение.