Выбор лидера Patroni при потери связи между ЦОДами

Мне кажется тут корень проблемы в том, что пользователи попадают во второй ЦОД. С точки зрения лидера он не доступен, и запросы на него должны или не попадать, или перенаправляться с него на доступный ЦОД.

Ожидалось, что лидеры patroni и etcd переедут в 3-ий ЦОД

Зачем им это делать? Они видят себя и третий ЦОД, с их точки зрения они в большинстве и ничего никуда переключать не нужно.

ведь связь от Patroni до 2/3 etcd

Наверно до 1/3 etcd? 2 то у вас не доступен с мастера.

Мне кажется тут корень проблемы в том, что пользователи попадают во второй ЦОД

Да, так и есть. И тут скорее проблема в том, что другие наши сервера при таком кейсе продолжают корректно работать, и ради одного кластера Patroni - полностью отключать ЦОД - в данный момент со стороны коллег выглядит не совсем корректным решением. Естественно, если не будет найден вариант, как это обойти, скорее всего остановимся на том, что всё что использует PostgreSQL будет отключено.

Они видят себя и третий ЦОД, с их точки зрения они в большинстве и ничего никуда переключать не нужно.

Да, с точки зрения, поведения кластера я понимаю, что это корректно. И по логам Patroni и etcd, я тоже наблюдаю, что и лидер Patroni продолжает корректно обновлять ключ, и лидер etcd, не меняется.

Но как подсказывают коллеги, тот же Redis Sentinel (не redis cluster) в таком случае уходит в 3-ий ЦОД. (Вроде бы даже слышал, что кластер Always On MSSQL умеет так, если его настроить.)

Наверно до 1/3 etcd?

Ошибка с моей стороны, имелось ввиду 2 из 3 серверов etcd)