Лучший способ работать с наборами реплик в MongoDB, используя только 2 сервера

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

Если я правильно понимаю, у меня может быть 1 набор реплик с 2 узлами, по одному на каждом сервере. Теперь, чтобы отказоустойчивость переназначила новый первичный узел, мне нужен узел-арбитр.

Поскольку я все еще хочу использовать 2 сервера, если сервер, на котором находится узел арбитра, выйдет из строя, установить новый основной узел будет невозможно.

Решение, которое я придумал, состоит в том, чтобы иметь 3 узла арбитра. 1 на одном сервере и 2 на другом. Таким образом, если какой-либо сервер выйдет из строя, узел другого сервера, не являющийся арбитром, станет основным.

Это верно? Должен ли я использовать другое решение?

Спасибо! Игнасио.


mongodb replicaset fault-tolerance
person ignacioz    schedule 25.09.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

Первичные выборы не могут быть гарантированы при четном числе узлов. Вы должны либо допустить возможность отсутствия основного компьютера в вашем приложении (переход в режим только для чтения), либо добавить третий компьютер.

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

  1. Когда вторичный становится недоступным, первичный продолжает функционировать.
  2. Когда первичный становится недоступным, но арбитр все еще активен, вторичный становится первичным.
  3. Когда первичный и арбитр становятся недоступными (например, вся машина становится недоступной), тогда вторичный остается вторичным, а основного не будет.

Я обнаружил, что сценарий 3 встречается чаще, чем сценарий 2. Чтобы учесть это, вы можете использовать MongoMMS (или что-то еще) для мониторинга кластера, чтобы любые недоступности узлов (особенно сценарий 3) можно было исследовать как можно скорее.

person G-Wiz    schedule 25.09.2014