Насколько безопасен безопасный режим MongoDB на вставках?

Question

Я работаю над проектом, в котором есть некоторые важные данные. Это означает, что мы не можем потерять что-либо из этого, если свет или сервер не работает. Мы используем MongoDB для базы данных. Я хотел бы убедиться, что мои данные находятся в базе данных после вставки и выполнить откат всей партии, если один элемент не был вставлен. Я знаю, что философия Mongo заключается в том, что нам не нужны транзакции, но как я могу убедиться, что мои данные действительно надежно хранятся после вставки, а не отправляются в какую-то «черную дыру».

• Должен ли я сделать поиск?

• Должен ли я использовать некоторые конкретные команды mongoDB?

• Должен ли я использовать шардинг, даже если одного сервера достаточно для удовлетворения
  скорость и, кстати, ничего не гарантирует, если свет
  понижается?

Какое лучшее решение?

Answer 1

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

Задача записи, которую вы ищете, - это FSYNC_SAFE (по крайней мере, так ее называют с точки зрения драйвера Java ) или REPLICAS_SAFE, которая подтверждает, что ваши данные были реплицированы.

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

Другая вещь, которую вам нужно сделать, это либо использовать относительно новую опцию --journal (которая использует журнал записи вперед), либо использовать наборы реплик для обмена данными между многими машинами, чтобы максимизировать целостность данных в случае сбой / потеря мощности.

Sharding - это не столько защита от аппаратных сбоев, сколько способ распределения нагрузки при работе с особенно большими наборами данных - sharding не следует путать с наборами реплик, которые являются способом записи данных на несколько дисков на более чем одна машина.

Поэтому, если ваши данные достаточно ценны, вам определенно следует использовать наборы реплик, возможно, даже размещение ведомых устройств в других центрах обработки данных / зонах доступности / стойках / и т. Д., Чтобы обеспечить необходимую вам устойчивость.

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

Answer 2

Я получил действительно хороший ответ от человека по имени GVP в группах Google.Я процитирую это (в основном это добавляет к ответу Рича):

Я хотел бы быть уверен, что мои данные будут в базе данных после вставки, и откатить весь пакет, если одинэлемент не был вставлен.

Это сложная тема, и здесь необходимо рассмотреть несколько компромиссов.

Стоит ли использовать шардинг?

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

Должен ли я использовать некоторые конкретные команды mongoDB?

Первое, что нужно рассмотреть, это "безопасный" режим или "getLastError ()", как указано Андреасом.Если вы выполняете «безопасную» запись, вы знаете, что база данных получила вставку и применила запись.Однако MongoDB сбрасывается на диск только каждые 60 секунд, поэтому сервер может выйти из строя без данных на диске.

Второе, что нужно учитывать, это «ведение журнала» (v1.8 +).При включенном ведении журнала данные отправляются в журнал каждые 100 мс.Таким образом, у вас есть меньшее время до сбоя.Драйверы имеют опцию «fsync» (проверьте это имя), которая идет на шаг дальше, чем «безопасная», она ожидает подтверждения того, что данные были сброшены на диск (то есть файл журнала).Однако это касается только одного сервера.Что произойдет, если жесткий диск на сервере просто умрет?Ну, вам нужна вторая копия.

Третье, что нужно учитывать, это репликация.Драйверы поддерживают параметр «W», который говорит «реплицируйте эти данные на N узлов» перед возвратом.Если запись не достигает «N» узлов до истечения определенного времени ожидания, запись завершается неудачно (генерируется исключение).Однако вам необходимо правильно настроить букву «W» в зависимости от количества узлов в вашем наборе реплик.Опять же, поскольку жесткий диск может выйти из строя, даже при ведении журнала, вы захотите посмотреть на репликацию.Затем происходит репликация в центрах обработки данных, которая слишком длинна, чтобы попасть сюда.Последнее, что нужно учитывать, это ваше требование «откатиться».Насколько я понимаю, MongoDB не обладает такой способностью «отката».Если вы делаете пакетную вставку, лучшее, что вы получите, - это указание того, какие элементы вышли из строя.

Вот ссылка на драйвер PHP на этом: http://it.php.net/manual/en/mongocollection.batchinsert.php Вам придетсяпроверьте детали репликации и параметр WЯ считаю, что здесь действуют те же ограничения.