Репликация mongoDB + шардинг на 2 сервера разумный?

Question

Рассмотрим следующую настройку:

Есть 2 физических сервера, которые настроены как обычный набор репликации mongodb (включая процесс арбитра, поэтому автоматический переход на другой ресурс будет работать правильно).

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

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

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

Есть ли недостатки этой установки, кроме общих издержек на установку и количества процессов (mongos / configservers / арбитры)?

Answer 1

Это определенно сработает. Я задал вопрос на IRC-канале #mongodb немного назад о том, было ли плохой идеей запускать несколько процессов mongod на одной машине. Ответ был «пока у вас есть ОЗУ / ЦП / пропускная способность, сходите с ума».

Стоит отметить, что если вы ищете высокопроизводительные операции чтения и не возражаете против того, что записи выполняются немного медленнее, вы можете:

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

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

Answer 2

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

Answer 3

В этой ситуации я бы в первую очередь пересмотрел шардинг и просто сделал его набором точных реплик из 2 машин (+1 арбитр).

Answer 4

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

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

http://www.markus -gattol.name / ws / mongodb.html # do_i_need_an_arbiter