2016-07-07 3 views
0

Документация JGroups (http://www.jgroups.org/manual/html/index.html) гласит, что при использовании протокола обнаружения FD текущий координатор группы отвечает за обновление представления кластера, когда узел кластера умирает, но он не ясен из документацию о том, что делается, когда сам координатор группы умирает.
Например, у нас есть кластер {A, B, C, D}, а узел A является координатором здесь. Теперь, если новый член «E» хочет присоединиться, координатор запускает протокол JOIN и позволяет E присоединиться к кластеру, и если член, скажем, «C», выйдет из строя, соседи «C» будут транслировать подозрительное сообщение и протокол GMS координатора исключает «C» и передает новый вид членам кластера. Это понятно. Но в случае смерти самого координатора группы тогда (по какой-то логике) следующий член в этой точке зрения принимает на себя роль координатора.jgroups - обнаружение сбоев при смерти координатора группы

  • Мой вопрос: как следующий участник узнает о новом View?
  • Это канал, который становится координатором на данный момент и устанавливает новый вид для членов, и каждый член проверяет, является ли новым координатором или нет, проверив первый или самый старый элемент на вид?

ответ

0

Прежде всего, вы смотрите устаревшую документацию; новый - http://www.jgroups.org/manual/index.html.

Когда координатор умирает, вторая строка вступает в силу и становится новым координатором. Поэтому, если B получает сообщение SUSPECT(A), он знает, что ему нужно взять на себя ответственность за то, что сработала ошибка (A).

Обратите внимание, что FD_ALL или FD_ALL2 являются предпочтительными по сравнению с FD, если вы используете UDP в качестве транспорта.

+0

Спасибо @Bela. Извините за устаревшую документацию. Но у меня все еще мало сомнений. ", если B получает сообщение SUSPECT (A), он знает, что он должен взять на себя, когда сработала ошибка (A)." - это означает, что B становится координатором, а затем B будет использовать VERIFY_SUSPECT и в конечном итоге исключить A из кластера и опубликовать новое представление {B, C, D} членам. Это так? Но в этом случае, если будет найдено, что после использования VERIFY_SUSPECT, А жив, тогда что будет с координацией? – Sayan

+0

B не возьмет верх –

+0

Могу ли я также задать вопрос, связанный с этим. Что делать, если B также падает? Если список участников идет как A, B, C, D ... и оба текущих координатора и несколько следующих кандидатов одновременно сбой, как работает система? Заранее спасибо, –

Смежные вопросы