Как избежать потери внутреннего состояния мастера при переключении на новый мастер во время сетевого раздела - PullRequest
Новая
       35

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

0 голосов
/ 01 ноября 2018

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

В настоящее время моя система выглядит так:

  1. N разных узлов, каждый из которых идентичен. 1 главный узел, на котором работает простой веб-сервер.

  2. Все узлы обмениваются данными друг с другом, используя простой протокол сердцебиения, и каждый из них поддерживает глобальное состояние (количество доступных узлов, кто является основным, время простоя и время безотказной работы друг друга.)

  3. Если какой-либо узел не слышит от мастера в течение некоторого установленного времени, если возникает тревога. Если достигнуто согласие о том, что мастер не работает, новый мастер избирается.

  4. Если сеть узлов разделена.

    • Если мастер находится в вспомогательном разделе, он прекратит обслуживать запрос и сам отключится через заданный промежуток времени. Младшая группа не может выбрать мастера (некоторые минимальные узлы требуют принятия решения)
    • Новый мастер выбирается в главном разделе по истечении заданного времени, после того как старый мастер не слышит.

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

Это может привести к несогласованности данных в системе, если какой-либо клиент решил записать новые данные в старый мастер. Как мы избегаем этой проблемы. Буду рад, если кто-нибудь укажет мне правильное направление.

1 Ответ

0 голосов
/ 01 ноября 2018

Вместо того, чтобы принимать записи к ведущему узлу меньшинства, вам нужно просто отклонить записи на старый мастер в этом случае, и вы можете сделать это, пытаясь проверить его мастерство с большинством кластера при каждой записи. Если мастер находится на стороне меньшинства раздела, он больше не сможет связаться с большинством кластера и не сможет подтверждать запросы клиентов. Этот короткий период недоступности предпочтительнее потери подтвержденных записей в системах на основе кворума.

Вы должны прочитать бумагу Плот. Вы медленно продвигаетесь к реализации протокола Raft, и он, вероятно, ответит на многие вопросы, которые у вас могут возникнуть на пути.

...