следовательно не может быть понятия "автоматический  force promote"    ... цель таймаутов в том чтобы выждать временное окно  после которого  автоматический штатный promote  станет безопасным

Форс промоут это же по сути автопромоут, но в ситуации когда мастер ушёл

это в вашей терминологии так...

Если ждать фенсинг таймаут, то у нас остановка сервиса

И мы не знаем момента, когда сервер ушёл, соответственно ждать будем от момента когда это обнаружили

именно,  здесь нет никакого противоречия,  главное чтобы временное окно было не меньше чем договоренности обоих сторон (координатора и мастер узла)

Если координатор видит что мастер не отвечает, он должен дожидаться фенсинг таймаута? Но этот таймаут уже заложен в таймаут ожидания ответа (+ попытки)

Фенсинг таймаут имеет смысл только для узла самого по себе

неважно что куда заложено,  главное что назначение нового мастера начнется не раньше чем через "временное окно"

нет  , выше описал..

Из описания выше я немного не понял, что значит "координатор видит что последняя запись доехала в кластер" -- это для частного случая, когда между мастером и остальным кластером сеть порвалась и координатор видит вклок мастера и вклоки остальных узлов?

это даже в доке уже написано

значит что небыло ниодной записи в мастер после того как он потерял связь... тоесть на нем просто небыло RW нагрузки,   а значит его можно безопасно возвращать в кластер

но это  эвристика чтобы не делать rejoin  , в общем случае  это rejoin...

типа может сеть у всех пропала сразу , что чаще всего и бывает ...

... поскольку возражений нет  продолжу свою мысль...


из описанного выше следует что  штатный  failover  заблокирован до тех пор пока не случится fencing (изоляция/самоизоляция)  узла.
Таким образом для поддержки внешнего fencing агента нужна ручка  которая  отключит ожидание (FENCING_TIMEOUT)  и разрешит выбрать нового мастера "прямо сейчас"  .


Как это примерно  можно реализовать:
 api fence(uuid узла + timestamp)
на такой запрос координатор  проверяет что такой uuid в это время действительно числится мастером,  после чего  сичтается "изолированным" что приводит к мгновенному выбору нового мастера.


Как это будет работать на практике:
k8s оператор  картриджа  слушает api кубера и как только тот ему говорит что пода была удалена    посылает fence в координатор.

Т.е.  например
рубанем тарантул,  
kubectl delete pods pod_name --grace-period=0 --force
он выхватит kill -9 (если процесс вообще есть)

оператор узнает об этом и тут же сообщает координатору о том что узел изолирован....

Сам же тарантул если вдруг включится  проверит что выход был "грязный" и не вернется в кластер без "разрешения" координатора...


Такким же образом в зависимости от платформы можно реализовать любой внешний fence agent

Привет! У нас в админке картридж кластера одна реплика постоянно переходит из состояния healthy в OperationError.
В логах у нее ничего подозрительного нет, в vshard.storage.info тоже все норм, алертов нет.
Куда смотреть?

require('membership').members() можешь показать?

можно в личку

@spiridonovaalex, пожалуйста, нажмите на кнопку ниже в течение указанного времени, иначе вы будете кикнуты. Спасибо! (240 сек)
При поддержке Золота Бородача