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

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

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

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

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

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

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

9
mongodb replication sharding sysadmin

4 ответов

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

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

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

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

10

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

1

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

0

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

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

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

0