LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

2

Имеется следующая конфигурация: 3 ЦОДа (далее 1-ый, 2-ой, 3-ий) В Каждом ЦОДе, по: 2 сервера Postgres+Patroni 1 сервер etcd 1 сервер haproxy

Лидеры Patroni и etcd находятся в 1-ом ЦОДе. Сэмулировали разрыв соединения между 1-ым и 2-ым ЦОДами. При этом сами ЦОДы остаются в работоспособном состоянии и имеют стабильную связь с 3-им ЦОДом. Ожидалось, что лидеры patroni и etcd переедут в 3-ий ЦОД, но в итоге, в данном случае, они продолжают оставаться в 1-ом.

Возможно кто-то сталкивался с такой же проблемой и как-то её решал? Вообще судя по тому, как происходят выборы в Patroni - всё работает корректно, ведь связь от Patroni до 2/3 etcd - стабильная, и он стабильно и исправно обновляет ключ. Но у нас ситуация, что часть клиентов будут попадать во второй ЦОД, откуда начнут получать ошибки, о невозможности записать что-либо в БД.



Последнее исправление: EcksRay (всего исправлений: 1)

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

maxcom ★★★★★
()
Последнее исправление: maxcom (всего исправлений: 1)

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

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

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

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

Eshkin_kot ★★
()
Последнее исправление: Eshkin_kot (всего исправлений: 1)
Ответ на: комментарий от Eshkin_kot

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

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

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

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

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

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

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

EcksRay
() автор топика