Кейс: split-brain из-за потери сети между Redis Sentinel

Сетевой партишн разделил дата-центры: DC-1 и DC-2 перестали видеть друг друга. Мастер Redis жил в DC-1, реплики и большинство Sentinel-процессов — в DC-2. Sentinel в DC-2 набрали кворум, решили, что мастер недоступен, и промоутнули реплику в новый мастер.

Проблема в том, что старый мастер в DC-1 не упал — он просто не видел Sentinel из DC-2. Клиенты, у которых соединение с DC-1 сохранилось, продолжали писать в старый мастер как ни в чём не бывало. Несколько минут в кластере существовали два мастера одновременно, оба принимали запись.

Когда сеть восстановилась, старый мастер переключился в реплику нового — и все записи, сделанные в него за это окно, потерялись без предупреждения: репликация просто перезатёрла его данные данными нового мастера.

Что спросят следом: как предотвратить этот сценарий. Один из ответов — min-replicas-to-write в связке с min-replicas-max-lag: мастер отказывается принимать запись, если не может подтвердить её нужному числу реплик. Это не убирает partition полностью, но сужает окно, в котором старый мастер молча принимает потерянные позже записи.

Sentinel решает, кто мастер, по кворуму видимости — не по факту, жив ли старый мастер физически. На partition это создаёт окно, где два узла одновременно уверены, что они главные.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки