Первичные выборы "Рафт против МонгоДБ"

Ответ 1

Некоторые ключевые различия в консенсусном подходе, как и в MongoDB 2.4, заключаются в следующем:

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

• Плот имеет только три состояния node для рассмотрения: лидер (первичный), последователь (вторичный) или кандидат (назначенный первичный). MongoDB имеет дополнительные node состояния, чтобы рассмотреть возможность включения большего количества потенциальных состояний ошибки, таких как RECOVERING или SHUNNED узлы, или отложенные элементы набора реплик.

• В Raft каждый node может голосовать только за кандидата node один раз за период выборов. MongoDB позволяет выбирать голоса за node как часть конфигурации набора реплик, поэтому некоторые узлы могут быть без права голоса или, возможно, иметь несколько голосов (Примечание: устаревшая конфигурация с несколькими голосами устарела от ветвь развития MongoDB 2.5).

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

Для получения более подробной информации вы должны сравнить бумагу Raft В поисках понятного консенсусного алгоритма с документацией по MongoDB Replica Set Elections.