Mongodb, могу ли я запускать вторичную репликацию только в заданное время или вручную?

Question

Я не эксперт mongodb, поэтому я немного не уверен в настройке сервера.

У меня есть один экземпляр, запускающий mongo3.0.2 с wiredtiger, принимающий операции чтения и записи. Он собирает журналы от клиента, поэтому нагрузка на запись приличная. Один раз в день я хочу обрабатывать эти журналы и вычислять некоторые показатели с помощью структуры агрегации, набор данных для обработки - это что-то вроде всех журналов за последний месяц, и все вычисления занимают около 5-6 часов. Я думаю о разделении записи и чтения, чтобы избежать блокировок в моих коллекциях (сервер продолжает записывать журналы во время чтения, новые записанные журналы могут совпадать с моими запросами, но я могу пропустить их, потому что мне не нужно 100% точность).

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

Я делаю всю свою обработку с node.js, поэтому один из вариантов, который я вижу здесь, заключается в том, чтобы экспортировать данные, созданные в некоторый период, например [вчера, сегодня], и импортировать его для чтения экземпляра самостоятельно и выполнить вычисления после импорта , Я рассматривал набор реплик и репликацию master/slave как возможные настройки, но я не понял, как его настроить для достижения описанного сценария. Так что, может быть, я ошибся и что-то пропустил? Есть ли другие возможности для достижения этого?

Answer 1

Ваша идея использования набора реплик ошибочна по нескольким причинам.

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

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

Но если вы хотите выполнить интеллектуальный анализ данных в подмножестве ваших документов, выбранных по времени, существует другое решение.

Перенос документов, которые вы хотите проанализировать, в новую коллекцию. Вы можете сделать это с помощью конвейера агрегации, состоящего только из соответствия $, которое соответствует документам за последний месяц, за которыми следует $out. Out-operator указывает, что результаты агрегирования не отправляются в приложение/оболочку, а вместо этого записываются в новую коллекцию (которая автоматически опорожняется до того, как это произойдет). Затем вы можете выполнять свою отчетность в новой коллекции, не блокируя ее. Это также имеет то преимущество, что теперь вы работаете с гораздо меньшей коллекцией, поэтому запросы будут быстрее, особенно те, которые не могут использовать индексы. Кроме того, ваши данные не будут меняться между вашими агрегациями, поэтому ваши отчеты не будут иметь никаких несоответствий между ними из-за изменения данных между ними.

Если вы уверены, что для генерации отчетов вам понадобится второй сервер, вы все равно можете использовать репликацию и выполнить агрегацию на вторичной основе. Тем не менее, я бы порекомендовал вам build a proper replica-set (состоящий из первичного, вторичного и arbiter) и всегда оставляйте репликацию активной. Мало того, что убедитесь, что ваши данные не устарели, когда вы создаете свои отчеты, это также дает вам важное преимущество автоматического переключения при сбое, если ваша основная причина по какой-то причине идет вниз.