Я новичок в mongodb и решаю здесь некоторые проблемы с DevOps.
У нас есть Saas-продукт b2b, развернутый на AWS, где нет сетевого эффекта между клиентами, и у некоторых клиентов есть гораздо большие базы данных, чем у других. В настоящее время они запускаются с одного центрального сервера mongodb, и у нас возникают серьезные проблемы с шумным соседом, нам нужно изолировать клиентов, у которых смехотворно большие коллекции контактов.
Мой вопрос: каков минимальный разумный сервер mongodb для настройки, в которой мы предоставляем отдельным крупным клиентам их собственный изолированный vpc в aws? Должен ли это быть набор реплик с 3 серверами, как указано в документации mongo, или можно разумно использовать один экземпляр ec2 в качестве производственного сервера mongo для небольшой базы данных?
Вы жестяная банка иметь производственную среду, работающую на одном экземпляре MongoDB. Под очень особые обстоятельства. Давайте посмотрим, что это за обстоятельства после того, как мы проясним некоторые вещи о наборах реплик.
Вопреки распространенному мнению, наборы реплик преследуют только одну главную цель: обеспечение доступности баз данных. Предположим, у вас есть только один экземпляр. Каждая работа по техническому обслуживанию, каждый сбой сервера, каждая ошибка в администрировании приведет к простою. Время простоя, которое влияет не только на ваши SLA (достаточно плохо), но вполне может привести к тому, что администратор баз данных выйдет из постели в 06:00 утра после вечеринки, и теперь он пытается получить достаточно высокий уровень кофеина. чтобы иметь возможность восстанавливать базы данных наполовину пьяными.
Более того: вы неизбежно потеряете все данные между резервным копированием и восстановлением службы. Во-первых, очевидно, что вы потеряете все данные между последней резервной копией и моментом, когда сервер стал недоступен. Тогда вы потеряете все данные, которые были бы сгенерированы во время простоя.
Теперь предположим, что у вас есть набор реплик с двумя узлами, несущими данные, и арбитром. Немного лучше. Ваш основной выходит из строя, выбирается другой узел, несущий данные, и благодаря автоматическому переключению на другой ресурс, который обеспечивают большинство драйверов, ваша служба продолжает работать без простоев и потери данных. Но: вы потеряли избыточность. Таким образом, чтобы снизить риск, один администратор базы данных снова встает с постели, которому теперь нужно продвинуть арбитра на узел, несущий данные, дождаться синхронизации данных, надеясь, что синхронизация будет быстрее, чем скорость изменения вашего data (если быть более точным: вы надеетесь, что ваше окно журнала операций репликации больше, чем время, необходимое для синхронизации данных). В противном случае синхронизация данных завершится ошибкой, и вам придется закрыть приложение, чтобы синхронизация прошла успешно. Что вы выиграли с этой настройкой, так это то, что вы можете выбрать, когда закрыть приложение для восстановления избыточности.
Боковое примечание: если скорость изменения данных превышает окно журнала операций репликации, следует выполнить сегментирование. Всегда проследите за тем, чтобы окно журнала операций репликации было достаточно большим.
Теперь предположим, что у вас есть три узла передачи данных, как было предложено. Даже когда один сервер выходит из строя (или обновляется и т. Д.), У вас все еще есть избыточность. Один узел выходит из строя ночью? Спи сладко!
Принимая во внимание вышесказанное, вы можете иметь единую производственную среду, если и только если вы
В большинстве известных мне серьезных бизнес-приложений ответ на одно или несколько из этих условий - «Нет».
Да, при условии, что вы можете жить с тем фактом, что потеря одного узла, несущего данные, будет стоить вам избыточности. И что в этом случае вам, скорее всего, придется повторно синхронизировать данные, что требует от вас близко контролировать окно журнала операций репликации и Чтобы убедиться время, необходимое для повторной синхронизации, подходит.
Учитывая разницу в цене между экземпляром арбитра и узлом, несущим данные, вопрос управления рисками заключается в том, выбираете ли вы между настройкой с двумя узлами передачи данных и арбитром или предлагаемой настройкой с тремя узлами передачи данных.
Можно ли разумно использовать один экземпляр ec2 в качестве производственного сервера mongo для небольшой базы данных?
Проще говоря: не имхо. Это граничит с небрежностью, увеличивает риски, которые можно уменьшить за сравнительно небольшие деньги и, скорее всего, намного дороже, чем наличие хотя бы набора реплик с двумя узлами, несущими данные, и арбитром. Если принять во внимание все.
Это должен быть набор реплик из 3 серверов, как указано в документации mongo?
Если только ты не действительно, действительно, действительно знаете, что делаете: да.
Вы можете использовать один экземпляр EC2 в качестве производственного сервера mongoDB, если вы счастливы, что все данные клиента исчезнут без предупреждения. Конечно, выбрав в первую очередь MongoDB (предположительно из-за его хорошо известные свойства веб-масштаба), вы, по-видимому, в любом случае не заинтересованы в долговечности, но запускать все это на одном экземпляре EC2 просто попрошайничество гремлинов базы данных, чтобы подарить вам плохой день.