Вступление

Тот факт, что слово «арбитры» написано во множественном числе в первом предложении, имеет стилистические, а не технические причины.

У вас действительно должен быть не более 1 арбитра. Iirc, технически у вас может быть больше, но, честно говоря, я никогда не пробовал. Но давайте предположим, что вы могли бы ради объяснения ниже.

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

Резюме: для чего нужны арбитры?

Арбитр существует для обеспечения кворума на выборах.

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

Чтобы предотвратить это, в смесь добавляется арбитр. Арбитр не делает ничего, кроме как отслеживает, какой из доступных узлов, несущих данные, имеет самый последний доступный набор данных, и голосует за этого члена в случае выборов. Таким образом, с нашим набором реплик с двумя узлами, несущими данные, чтобы получить квалифицированное большинство голосов в случае выхода из строя 1 из узлов, формирующих набор реплик, нам нужен только 1 арбитр, поскольку 2/3 голосов обеспечивают квалифицированное большинство.

Арбитры за пределами 2 узлов, несущих данные

Если бы у нас был набор реплик с 3 узлами, несущими данные, нам не понадобился бы арбитр, поскольку у нас есть 3 участника с правом голоса, и если 1 участник выходит из строя, остальные все равно образуют квалифицированное большинство, необходимое для проведения выборов.

Немного более абстрактно, мы можем узнать, нужен ли нам арбитр, подставив количество голосов, присутствующих в наборе реплик, в следующую «формулу»

needArbiter = originalVotes - floor(originalVotes/2) <= originalVotes / 2

Если мы добавим дополнительного арбитра, количество голосов будет 4: 3 узла, несущие данные, и 1 арбитр. Один узел выходит из строя, без проблем. Второй узел выходит из строя, и набор реплик возвращается в вторичное состояние. Теперь давайте предположим, что один из двух нижних узлов является арбитром — мы будем в вторичном состоянии, в то время как узлы, несущие данные, смогут обеспечить кворум. Нам пришлось бы платить и содержать дополнительного арбитра без какой-либо выгоды от этого. Таким образом, чтобы снова обеспечить квалифицированное большинство, нам нужно было бы добавить еще одного арбитра (сейчас 2), без каких-либо преимуществ, кроме того факта, что два арбитра могут выйти из строя. По сути, вам понадобятся дополнительные арбитры, чтобы предотвратить ситуации, в которых существование арбитра, который вам не нужен, становится проблемой.

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

Вывод

Имхо, с 4 узлами, несущими данные, арбитр достигает предела полезности. Если вам нужен высокий коэффициент репликации, процент экономии денег при использовании арбитра по сравнению с узлом, несущим данные, становится все меньше и меньше. Помните, что следующим шагом будет 6 узлов, несущих данные, плюс арбитр, так что ваши затраты составят менее 1/6 ваших общих затрат.

В целом, чем больше у вас узлов, несущих данные (чем выше ваш «коэффициент репликации» в терминах Mongo), тем менее разумным становится иметь дополнительных арбитров. Как с технической точки зрения (вероятность отказа большинства узлов одновременно становится все ниже и ниже), так и с точки зрения бизнеса (при высоком коэффициенте репликации деньги, сэкономленные на арбитре, по сравнению с общими затратами становятся меньше). нереально маленький).

Мнемоника:

Наименьшее нечетное число равно 1.

У меня есть сценарий, в котором я думаю, что имеет смысл иметь более 1 арбитра.

Проблема

У меня есть 3 узла, несущие данные, в наборе реплик. Теперь я хочу распределить свой набор реплик географически, чтобы снизить риск сбоя в работе центра обработки данных.

3 Node Replicaset не решает проблему

• Первичный центр обработки данных => 2 узла, несущих данные

• Резервный центр обработки данных => 1 узел хранения данных

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

Набор реплик из 5 узлов

• Первичный центр обработки данных => 2 узла, несущих данные

• Резервный центр обработки данных => 1 узел хранения данных

• Третий центр обработки данных => 2 арбитра

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

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

Для нашего частного случая имеет смысл иметь 2 арбитров. Позвольте мне объяснить: у нас есть 3 центра обработки данных, но 1 из этих 3 центров обработки данных не подходит для размещения элементов, несущих данные. Вот почему мы размещаем в этом центре обработки данных 2 арбитра для каждого набора реплик. 3 элемента replSet, несущих данные, размещены в двух других центрах обработки данных (мы хотим иметь 3 вместо 2 элементов, несущих данные, по соображениям устойчивости). Если 1 из 3 центров обработки данных выходит из строя или недоступен из-за сетевого раздела, replSet по-прежнему может выбрать основной, поэтому он по-прежнему доступен для чтения и записи. Это было бы невозможно только с 1 или 0 арбитром. Следовательно, 2 арбитра могут иметь смысл.

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

|    |DC1  |DC2  |DC3  |
|----|-----|-----|-----|
|rs1 |m1,m2|m3   |a1,a2|
|rs2 |m1   |m2,m3|a1,a2|

Если один центр обработки данных выйдет из строя, какой член replSet станет основным?

• DC1 goes down:
  • rs1: m3
  • rs2: m2 or m3
• DC2 goes down:
  • rs1: m1 or m2
  • rs2: m1
• DC3 goes down:
  • rs1: m1,m2 or m3