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

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

  • Я должен выполнить поиск?

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

Должен ли я использовать осколки?

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

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

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

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

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

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