[3.x] TDB (iproto): support synchro replication for 2 DC in supervised failover

[xuniq]

Jira issue: https://jira.vk.team/browse/TNTP-4457
Product: Tarantool DB
Since: tdb 3.1.0, tarantool 3.6.0
Root document: https://www.tarantool.io/en/tarantooldb/doc/latest/admin_guide/failover/
SME: @ a1div

MR: https://gitlab.corp.mail.ru/tarantool/tdb/tarantooldb/-/merge_requests/219

Details

[EE] Failover coordinator: synchronous replication for 2 DC topology
In previous releases, the failover coordinator supported synchronous replication for topologies with 3 and more data centers. With N instances within a replica set, the minimal quorum size could be N/2 + 1. Topologies with 2 data centers were not supported because the quorum size could not be dynamically decreased if connection to the second data center was lost. For example, in a minimal replica set of 2 instances the default quorum size is 2 (calculated as 2/2 + 1 = 2). If one of the instances fails, no new transactions can be committed, because it is impossible to get an ack from the second instance. So, new transactions are lost.

Now, for supervised failover, Tarantool supports synchronous replication for topologies with 2 data centers. The failover coordinator automatically decreases the quorum size if connection to the second data center is lost, and restores the cluster’s operability within the available data center. When connection to the second data center is up again, the failover coordinator automatically restores the normal quorum size. So, no transactions are lost.

Александр Кленов (22.01.2026 10:50):
Не совсем так. Есть важный момент. Эту схему называют "2.5 ЦОДа". Чтобы всё устойчиво работало, нужно чтобы хранилище конфигурации располагалось на трёх площадках. То есть данные мы храним в двух ЦОДах. Но при этом у нас есть третяя площадка для принятия решений.

Александр Кленов (22.01.2026 10:52):
В теории можно наверное и на 2 ДЦ, но я сомневаюсь, что будет работать.

Александр Кленов (22.01.2026 10:55):
Какую аварию не может пережить 2.5 ДЦ? Это важно понимать. 2.5 ДЦ не могут пережить вот такой сценарий:

• падает первый ДЦ, второй работает, фейловер понижает кворум до 1, кластер продолжает обслуживать клиентов
• поднимается первый ДЦ, начинается обогащение данными со второго, актуализация, кворум ещё 1
• не успев всё докачать, падает второй ДЦ, в этом случае кластер становится недоступен

Александр Кленов (22.01.2026 10:55):
Ну ещё сценарий когда падают оба ДЦ, тогда тоже отказ в обслуживании. В остальных сценариях всё будет работать

Александр Кленов (22.01.2026 10:56):
Я думаю стоит это прояснить