Мне нужен совет о том, что делать с набором первичных реплик, который отключается от сети (например, сбой сети центра обработки данных) в той степени, в которой мы повышаем одну из вторичных реплик до первичной для восстановления службы для приложения с использованием базы данных .
Должны ли мы перед повторным подключением к сети убивать mongodb, работающий на коробке, чтобы его можно было снова добавить в качестве вторичного? Или первичный отключился от режима изменения набора?
Что произойдет, если мы позволим серверу mongodb вернуться в сеть с mongodb, работающим в качестве основного, хотя и изолированным до повторного подключения?
Приносим извинения, если на этот вопрос есть ответ в других документах, которые я пытался найти, но, возможно, я не ищу правильные термины.
Мне нужен совет о том, что делать с набором первичных реплик, который отключается от сети (например, сбой в сети центра обработки данных) в той степени, в которой мы повышаем одну из вторичных реплик до первичной для восстановления обслуживания приложения с использованием базы данных .
Автоматическая отработка отказа - одна из неотъемлемых особенностей MongoDB. дизайн набора реплик, поэтому вам не придется вручную переключаться на вторичный сервер, если вы намеренно не изменили конфигурацию по умолчанию. Обе primary и secondary являются Государства-члены (или роли) в наборе реплик и должны отличаться от топологии главный / подчиненный, которая обычно требует ручного вмешательства для переключения при отказе.
Если текущий первичный узел недоступен для большинства настроенных членов с правом голоса в наборе реплик MongoDB, ожидаемый результат будет следующим:
Видеть Выборы набора реплик в руководстве MongoDB для получения дополнительной информации.
Должны ли мы перед повторным подключением к сети убивать mongodb, работающий на коробке, чтобы его можно было снова добавить в качестве вторичного? Или первичный отключился от режима изменения набора?
Изолированный элемент набора реплик, несущий данные, останется во вторичном состоянии, но будет отображаться как «не работоспособен / доступен», если вы установите флажок rs.status() на других членах набора реплик. Как правило, рекомендуется одинаково подготовить все ваши избираемые элементы, несущие данные, чтобы любой член мог взять на себя роль основного, если это необходимо (в отличие от специально подготовленного основного элемента).
Если вы хотите, чтобы ваша реплика восстанавливалась автоматически, вы должны оставить все участники работающими как есть, и они возобновят синхронизацию (если возможно) после восстановления подключения. В конфигурации по умолчанию изолированный член, который раньше был основным, возобновит синхронизацию как дополнительный. Если у вас есть сильные предпочтения относительно того, какой участник будет избран основным (например, в зависимости от местоположения центра обработки данных), вы можете изменить приоритет для членов набора реплик. Если предпочтительный первичный был изолирован, он присоединится к набору реплик в качестве вторичного и возобновит синхронизацию до тех пор, пока не достигнет достаточного уровня, чтобы иметь право стать первичным и инициировать выборы.
Предупреждение при возобновлении синхронизации заключается в том, что изолированные элементы должны по-прежнему иметь достаточное перекрытие с журнал операций репликации исправного члена набора реплик, чтобы отследить любую операцию записи, которая произошла, пока член был изолирован. Вторичный, журнал операций которого больше не пересекается с другими членами набора реплик, будет помечен как «устаревший» и должен быть повторно синхронизированный.
Что произойдет, если мы позволим серверу mongodb вернуться в сеть с mongodb, работающим в качестве основного, хотя и изолированным до повторного подключения?
Невозможно иметь изолированную первичную реплику, если вы принудительно не перенастроите свой набор реплик, чтобы не было других участников с правом голоса. В наборе реплик не может быть двух основных цветов. Если изолированный бывший первичный первичный элемент принимает любые записи, которые не были распространены на большинство членов набора реплик, эти записи будут откат (экспортируется на диск для административного вмешательства), когда бывший первичный восстанавливает соединение с другими членами набора реплик. Вы можете предпринять дополнительные шаги, чтобы избегать откатов, включая использование majority написать беспокойство.
Если вы новичок в наборах реплик MongoDB, я бы порекомендовал использовать конфигурацию по умолчанию и предоставление для включения автоматического переключения при отказе и восстановления. Ручное вмешательство может потребоваться только в исключительных обстоятельствах.