Зачем нам нужен "арбитр" в репликации MongoDB?

Ответ 1

Я создал электронную таблицу, чтобы лучше проиллюстрировать эффект узлов Арбитра в наборе реплик.

Это в основном сводится к следующим пунктам:

1. При RS из 2 узлов данных потеря 1 сервера приводит к тому, что вы ниже минимума голосования (который "больше, чем N/2"). Арбитр решает это.
2. При наличии RS с четными узлами данных добавление Арбитра повышает вашу отказоустойчивость на 1, не давая возможности иметь 2 кластера для голосования из-за разделения.
3. С RS нечетных узлов данных добавление Арбитра позволило бы разделить для создания 2 изолированных кластеров с голосами "больше, чем N/2" и, следовательно, сценарий разделения мозга.

Выборы объяснены [в бедных] деталях здесь. В этом документе говорится, что РС может иметь 50 членов (четное число) и 7 членов с правом голоса. Я подчеркиваю "состояния", потому что это не объясняет, как это работает. Мне кажется, что если у вас произошел раскол с 4 участниками (все голосуют) с одной стороны и 46 участниками (3 голосуют) с другой, вы бы предпочли, чтобы 46 избрали основной, а 4 - читали. только кластер. Но это именно то, что мешает "ограниченному голосованию". В этой ситуации у вас фактически будет кластер из 4 участников с основным и кластером из 46 участников, который доступен только для чтения. Объяснение того, как это имеет смысл, выходит за рамки этого вопроса и находится за пределами моих знаний.

Ответ 2

Это действительно сводится к теореме CAP, согласно которой утверждается, что при равном количестве серверов по обе стороны раздела база данных не может поддерживать CAP (согласованность, доступность и допуск раздела). Арбитр специально предназначен для создания "дисбаланса" или большинства на одной стороне, чтобы в этом случае можно было выбрать первичное лицо.

Если вы получите четное количество узлов с любой стороны, MongoDB не выберет первичный, и ваш набор не будет принимать записи.

редактировать

Под любой стороной я имею в виду, например, 2 с одной стороны и 2 с другой. Мой английский там было нелегко понять.

Так что на самом деле я имею в виду обе стороны.

редактировать

Википедия представляет довольно хороший пример для объяснения CAP: http://en.wikipedia.org/wiki/CAP_theorem

Ответ 3

Арбитры - это необязательный механизм, позволяющий голосованию преуспеть, если у вас есть четное количество монгонов, развернутых в репликации. Арбитры - это легкий вес, предназначенный для развертывания на сервере, который НЕ является специальной репликой mongo, т.е. Основная роль сервера - это еще одна задача, например redis-сервер. Поскольку они светлые, они не будут мешать (заметно) с системными ресурсами.

Из документов:

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

• http://docs.mongodb.org/manual/core/replica-set-arbiter/
• http://docs.mongodb.org/manual/core/replica-set-elections/#replica-set-elections

Ответ 4

Необходимо иметь арбитра в репликации по следующим причинам:

• Репликация более надежна, если у нее нечетное количество наборов реплик. Incase, если есть четное количество наборов реплик, лучше добавить арбитра в репликации.
• Арбитры не хранят данные в них, и они просто должны голосовать на выборах, когда происходит сбой любого узла.
• Арбитр - это легкий процесс, он не потребляет много аппаратных ресурсов.
• Арбитры просто обмениваются данными учетных данных пользователя между набором реплик, которые зашифрованы.
• Голосование во время выборов, звуковые удары и данные конфигурации не шифруются при обмене данными между наборами реплик.
• Лучше запускать арбитр на отдельной машине, а не на любой реплике, установленной для сохранения высокой доступности.

Надеюсь это поможет !!!