Рекомендуется установить нечетное число. Я сомневаюсь, что по мере того, как кто-то уходит из нечетного набора, у нас есть набор четных чисел. Количество членов колеблется между четными и нечетными, когда они уменьшаются один за другим. У нас всегда нет нечетного сценария участника. Может ли кто-нибудь объяснить, как работает голосование в MongoDB?
Голосование в MongoDB
comment
обычно хороший способ решить эту проблему - ввести abrtitar на сервер приложений специально для голосования.
- person Sammaye schedule 24.03.2013
Ответы (1)
Голосование осуществляется большинством членов с правом голоса.
Представьте набор реплик с тремя членами (с правом голоса). Предположим, что узел A является первичным, а узлы B+C — вторичными. Узел A выходит из строя, поэтому узлы B+C отправляются на выборы. Они по-прежнему составляют большинство (двое из трех). Выборы сначала определяются приоритетом. Если оба узла B и C имеют одинаковый приоритет, то побеждает тот, кто наиболее актуален в отношении отказавшего основного узла (oplog). Допустим, это узел B.
Как только узел A оживает, новых выборов не будет. Узел B остается главным, а узлы C+A теперь являются вторичными.
С другой стороны, если два узла выходят из строя, у вас нет большинства, поэтому набор реплик больше не может принимать обновления (применять записи) до тех пор, пока хотя бы один из двух отказавших серверов не станет активным (и не будет подключен к единственному серверу). выживший узел) снова.
Представьте теперь набор реплик с четырьмя участниками (с правом голоса). Допустим, узел A является первичным, а узлы B+C+D — вторичными. Узел A выходит из строя, поэтому узлы B+C+D отправляются на выборы. Они, конечно, составляют большинство (трое из четырех)
Однако, если два узла выходят из строя, у вас нет большинства (два из четырех), поэтому набор реплик снова находится в режиме только для чтения.
Вот почему рекомендуется нечетное число; Если вы теряете одного участника в наборе реплик из 3-х участников, это то же самое, что и потеря одного участника в наборе реплик из 4-х участников: вы по-прежнему получаете большинство кворума, и может быть избран новый первичный (RS все еще может избрать нового мастера путем большинство). С другой стороны, если вы потеряете двух участников в наборе реплик из 3-х участников или наборе реплик из 4-х участников (или n/2 участников в наборе реплик из n-членов) - опять же - последствия будут одинаковыми: ни один новый лидер не может быть избран. по выборам.
Итак, короче говоря, при наличии четного числа элементов в наборе реплик нет выигрыша в избыточности.
Подробнее см. внутреннюю информацию о выборах
person
Ori Dar
schedule
24.03.2013
Ключевым моментом является отсутствие усиления избыточности при равномерной настройке. Я понял. Большое спасибо :)
- person Srik; 24.03.2013
Теперь одна вещь поражает меня. Преимущество системы голосования, используемой в Mongo DB, также заключается в повышении доступности. Например: в конфигурации с 5 участниками режим только для чтения достигается, когда осталось только два участника. А в 11 членах это 5(›2). Я прав?
- person Srik; 24.03.2013
Еще раз спасибо за помощь :)
- person Srik; 24.03.2013
Думаю, у меня были те же проблемы с пониманием этого. Я подумал, что если у вас есть 3 узла, и один вышел из строя, что помешает другим 2 узлам голосовать за себя и вызвать тупиковую ситуацию. Прочитав ваш ответ, я теперь полагаю, что единственное, что имеет значение, — это соотношение живых узлов к живым + неработающим узлам (или 2/3 в вашем примере), поскольку все живые узлы будут голосовать за один и тот же узел. Это правильно?
- person Squirrl; 28.09.2013
Если оптимум и приоритет для всех реплик, что тогда происходит? По сути, если у вас есть набор вторичных узлов, пытающихся выбрать первичный, и все они синхронизированы с бывшим первичным, и все они имеют одинаковый приоритет, останутся ли они в тупике?
- person Tiberiu Savin; 13.11.2013
@TiberiuSavin: если четное количество узлов пытается проголосовать за новый первичный узел, даже если все они синхронизированы с последней записью в oplog (= оба могут быть избраны), они проголосуют и сделают выбор: один из них выбирается случайным образом.
- person Maxime Beugnet; 14.06.2016
@Srik: На самом деле это не совсем точно: ReplicatSet может иметь до 50 узлов, но только 7 членов с правом голоса. См. здесь: docs.mongodb.com/manual/ ядро/реплика-набор-выборы/. Таким образом, если у вас 50 участников, голосуют только 7. Если вы потеряете 4 из этих участников с правом голоса, вы перейдете в режим только для чтения, потому что вы больше не можете связаться с большинством участников с правом голоса, поэтому вы не можете начать раунд голосования.
- person Maxime Beugnet; 14.06.2016
Другой ключевой момент, который следует учитывать, — это то, что происходит при разделении сети. Если у вас есть четное количество узлов, скажем, 6, и сеть разделяется так, что они аккуратно разделены на две группы по 3, где первые три не могут связаться со вторыми тремя, у вас нет большинства — и вы не хотите один, потому что, если бы 3 узла могли выбрать новый первичный узел, у вас было бы два первичных узла. Это вполне возможно, если у вас первые 3 ноды в одном датацентре (или зоне AWS), а вторые 3 в другом. Это также тот случай, когда наличие одного арбитра, в идеале в третьей зоне, является хорошим вариантом, чтобы дать вам нечетное количество узлов.
- person Korny; 02.08.2016
кто определяет приоритет вторичных узлов?
- person Mithilesh Tipkari; 01.02.2019
