РАФТ избирательные ограничения

Я изучаю Raft с нуля с помощью Raft paper, и я не могу понять лидера избирательный процесс. Я прочитал в 5.4.1, что лидер должен иметь в своем журнале все зафиксированные записи кластера:

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

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

Но позже говорят, что кандидат хранит все зафиксированные записи, если они, по крайней мере, так же актуальны, как и любой другой журнал в большинстве. И механизм для определения этой актуальности - это сравнение индекса и срока последних записей. Журнал с более высоким сроком на последней записи будет более актуальным.

Не могло ли это привести к ситуации, когда лидер был избран без всех предыдущих заявленных записей? Например:

введите здесь описание изображения

В этом случае, если сервер 4 выйдет из строя, сервер 2 может стать лидером, поскольку у него есть запись с большим сроком, чем у большинства. Но в его журнале не было бы двух зафиксированных записей из условия 2. Верно? Я что-то неправильно понимаю, но могу понять, что это такое ...


replication distributed raft consensus voting-system
person vandermies    schedule 17.05.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вопрос в том, как логи вообще попали в такое состояние? Это невозможно.

Итак, это выглядит так:

* Server 2 is leader for term 1
* Server 1 is leader for term 2
* Server 2 (perhaps) is leader for term 3
* Server 4 is leader for term 4

Но сервер 2 не мог быть лидером для термина 3, потому что он не мог получить голоса на основании того факта, что последняя запись в его журнале была бы из термина 1. Если другой сервер был лидером для термина 3, он должен был написать запись для термина 3 в его журнале, если есть запись из термина 3 в журнале сервера 2. Но если бы была другая запись для термина 3 в журнале другого сервера, сервер с записями из термина 2 не мог бы быть выбран, поскольку их было бы только два. Даже если бы сервер 3 имел записи из термина 2 в своем журнале, он не мог быть выбран на этой позиции, потому что все еще были бы три других сервера с записями из термина 2 с более высокими индексами в журнале.

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

person kuujo    schedule 17.05.2016
comment
Я понимаю, что вы говорите, но у меня другой вопрос. Например, в примере, который вы только что изложили, я не понимаю, как сервер 2 может стать лидером для срока 3 (предположительно), когда, вероятно, были зафиксированы две первые записи условия 2. - person vandermies; 17.05.2016
comment
Сервер 2 не может стать лидером на срок 3. Во время выборов последний срок сервера 2 будет 1. Сервер 2 не может быть избран на срок 3, потому что большинство других серверов - сервер 1, 4 и 5 - имеют записи из срок 2 в их логах. Это моя точка зрения. Эта история невозможна. - person kuujo; 18.05.2016
comment
Хорошо, просто чтобы убедиться, что я понял: ограничение, которое гласит, что для того, чтобы стать лидером, сервер должен иметь все зафиксированные записи, затем реализуется косвенно, путем изучения терминов и индексов других журналов во время голосования. Ни какой переменной, которая говорит, какие записи зафиксированы? Это верно? - person vandermies; 18.05.2016
comment
Верно. То, что у лидера есть все предыдущие зафиксированные записи, является свойством алгоритма выборов, но фактический commitIndex никоим образом не участвует в алгоритме выборов. Фактически, для лидера вполне возможно быть избранным без некоторых записей, которые были сохранены на большинстве серверов. Вот почему приверженность не всегда определяется подсчетом копий, и именно поэтому лидеры должны зафиксировать запись из своего текущего срока, чтобы назвать записи из прошлых сроков совершенными. См. Рисунок 8 в документе Raft для объяснения этого. - person kuujo; 18.05.2016
comment
Голоса определяются исключительно на основе последнего срока подписчика, и, если сроки равны, это последний индекс. Индексы фиксации хранятся в памяти и стираются после сбоя, но серверы по-прежнему могут точно голосовать при восстановлении на основе своего индекса / срока журнала. - person kuujo; 18.05.2016