mongoDB репликация + осколки на 2 серверах разумные?

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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