В настоящее время у меня есть сервер A и сервер B, работающие со следующими экземплярами mongod:
Сервер А
Сервер B
Когда сервер A выходит из строя, сервер B не может выбрать себя в качестве основного, чтобы взять на себя все. Таким образом, все мое приложение отключается, поскольку база данных недоступна.
Мой вопрос: как я могу убедиться, что сервер B правильно берет на себя управление, когда сервер A выходит из строя, не увеличивая количество физических серверов?
Было бы хорошей идеей следующее?
Сервер А
Сервер B
Где я не добавил арбитра к B, потому что это сделало бы общее количество серверов одинаковым. Вопрос в том, является ли это наиболее эффективным способом позволить серверу B взять на себя управление, когда сервер A отключится? Или я могу удалить некоторые серверы, чтобы сэкономить RAM / CPU / HDD?
На самом деле неэффективно иметь арбитров на той же машине, что и ваши процессы mongod. У вас есть третий несвязанный сервер для работы Арбитра?
(Документировано здесь: http://www.mongodb.org/display/DOCS/Replica+Set+Tutorial#ReplicaSetTutorial-Runningwithtwonodes)
Запуск нескольких процессов mongod на одном сервере вызовет проблемы с производительностью. Кроме того, наличие двух используемых процессов mongod и арбитра на одной машине означает, что, если два физических сервера отключатся друг от друга, каждый из них выберет локальный первичный сервер.
Самый эффективный способ заставить сервер B взять на себя управление при отключении питания A - это переместить вашего текущего арбитра в B. Однако это будет означать, что A перестанет быть основным, если B откажет, потому что он не сможет сформировать большинство.
Есть два варианта - иметь другой экземпляр арбитра, готовый перейти на A / B и перенастроить набор, когда не удается добавить его в набор и удалить другого арбитра, или перезапустить A / B как автономный монгод вне реплики установить, пока другой не работает, и перенастроить, когда все снова станет здоровым.
С двумя машинами вы постоянно будете сталкиваться с этой проблемой, когда вам придется вручную вмешиваться, чтобы восстановить настройку. Каждое автоматическое решение, которое я могу придумать, предполагает наличие еще одной машины.