Mongodb oplog synchronization

Question

Я оцениваю Mongo DB с Apache Storm. Мой вариант использования таков, что я должен читать данные из MongoDB в Apache Storm, выполнять некоторую обработку в болте и выгружать его в базу данных графиков Neo4J.

Я использую Mongo Spout, который будет считывать данные из файла oplog. Я просмотрел документацию, в которой говорится, что первичный узел записывает данные в файл oplog, а чтение с репликами будет происходить из него асинхронно. Я знаю, что oplog - это ограниченная коллекция (заданный размер), данные записываются в oplog с очень высокой скоростью, а синхронизация с набором реплик немного медленная. Если oplog достигает максимального размера, он перезаписывает документы с самого начала файла. Во время асинхронного процесса, если мы получаем некоторые другие данные, и если репликация все еще завершена, существует возможность потерять набор репликации, поскольку он не будет синхронизирован.

Мой вопрос здесь

1) Есть ли способ преодолеть это?

2) Насколько лучше мы можем использовать эту ограниченную коллекцию при использовании с Apache Storm?

3) Если я даю максимальный размер oplog, например, я даю 500 ГБ, а oplog имеет 1 гб данных, он займет и зарезервирует 500 гб размера?

4) Является ли это правильным решением для моего использования?

Заранее благодарен!

Answer 1

Да, вы можете преодолеть это, увеличив размер оплога. Для этого требуется завершение экземпляра mongo для вступления в силу.

Недавно я работал над доказательством концепции, аналогичной тому, что вы делаете, используя хвостовой курсор в Mongo, чтобы подписаться на любые изменения, сделанные в oplog первичного, и перенести их в другую базу данных. Мы тоже в конечном счете заглянули в Шторм, чтобы сделать это чище. Мы не были на 100% проданы на Storm для этого варианта использования, но хвостовой курсор был немного уродливым и ненадежным. Я бы использовал Storm перед хвостом.

Вы можете лучше использовать эту ограниченную коллекцию со Storm, имея Storm только для сбора новых команд. Проблемы с репликацией, которые вы затрагиваете, по-видимому, являются взаимоисключающими из задачи сбора новой команды из Oplog на первичной основе и выполнения этих операций, представляющих интерес, в Neo4j. Если вы читали с помощью oplog на вторичной основе, я бы лучше понял, что это проблема, связанная с тем, что вы утверждаете, что целью является (то есть запись данных в Neo4j). Поскольку вы читаете из oplog Primary и можете обрабатывать новейшие команды по мере их поступления, я не уверен, что здесь есть проблема.

Что касается проблем синхронизации RS, которые вы подняли; если ваши второстепенные пользователи не синхронизированы с тем, что вы теряете репликацию, тогда есть проблемы, которые необходимо решить заранее. Я понимаю и ценю вашу точку зрения, но система, предназначенная для того, чтобы это произошло, нуждается в некоторой ТСХ.

Как вы сказали, oplog - это ограниченная коллекция. Когда это закончится, это освободит место для любых новых команд, которые будут выполнены. Как вы выразились, ничего не зарезервировано. Ваши второстепенные пользователи не смогут применять эти команды к ним и требуют полной повторной синхронизации. Вы должны быть заинтересованы в "replication oplog window", который обозначает 1. Это время, в течение которого операция останется в oplog, прежде чем будет перезаписана новой записью. 2. как долго второстепенный член может находиться в автономном режиме и все еще догоняет первичный, не выполняя полную повторную синхронизацию.