Есть ли дополнительные соображения при записи данных в локальную БД Монго?

Question

EDIT: Есть несколько точек зрения здесь

Запись на "местный" является законным метод - от "MongoDB: The Definitive Guide, второй ED." И http://www.kchodorow.com/blog/2010/10/27/bending-the-oplog-to-your-will/

Этот база данных никогда не будут повторены и может использоваться для хранения любых коллекций, которые должны быть локальными по отношению к одному серверу

Дать на «местный» никогда не является хорошей идеей - от https://jira.mongodb.org/browse/SERVER-11670 и https://groups.google.com/forum/#!topic/mongodb-user/E_aPgNR1zss

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

это может или не может быть хорошей идеей - документация на http://docs.mongodb.org/manual/reference/local-database/ агностик

---

Оригинальное сообщение:

Я сталкиваюсь с ошибками при написании около 100 МБ данных в «локальный» БД на моей установке Монго 2.4.9 (версии как для Windows и Linux).

Эта ошибка (https://jira.mongodb.org/browse/SERVER-11670) похожа на мою проблему, но я не могу поверить, что случайное неспособность писать в базу данных является второстепенной проблемой и что она будет отложена до 2.7. Так что это должен быть я.

Во всяком случае, ошибки Windows, выглядеть следующим образом:

Fri Jan 24 15:59:11.551 [conn40] mongod.exe ...\src\mongo\util\stacktrace.cpp(167)       mongo::printStackTrace+0x3e 
Fri Jan 24 15:59:11.551 [conn40] mongod.exe ...\src\mongo\db\dur.cpp(277)         mongo::dur::DurableImpl::_aCommitIsNeeded+0xe8 
Fri Jan 24 15:59:11.551 [conn40] mongod.exe ...\src\mongo\db\instance.cpp(812)        mongo::insertMulti+0x212 
Fri Jan 24 15:59:11.551 [conn40] mongod.exe ...\src\mongo\db\instance.cpp(875)        mongo::receivedInsert+0xaff 
Fri Jan 24 15:59:11.552 [conn40] mongod.exe ...\src\mongo\db\instance.cpp(441)        mongo::assembleResponse+0x57a 
Fri Jan 24 15:59:11.552 [conn40] mongod.exe ...\src\mongo\db\db.cpp(194)          mongo::MyMessageHandler::process+0xfa 
Fri Jan 24 15:59:11.552 [conn40] mongod.exe ...\src\mongo\util\net\message_server_port.cpp(207)    mongo::PortMessageServer::handleIncomingMsg+0x578 
Fri Jan 24 15:59:11.552 [conn40] mongod.exe ...\src\third_party\boost\libs\thread\src\win32\thread.cpp(180) boost::`anonymous namespace'::thread_start_function+0x21 
Fri Jan 24 15:59:11.552 [conn40] mongod.exe f:\dd\vctools\crt_bld\self_64_amd64\crt\src\threadex.c(314)  _callthreadstartex+0x17 
Fri Jan 24 15:59:11.552 [conn40] mongod.exe f:\dd\vctools\crt_bld\self_64_amd64\crt\src\threadex.c(292)  _threadstartex+0x7f 
Fri Jan 24 15:59:11.553 [conn40] kernel32.dll                 BaseThreadInitThunk+0xd 
Fri Jan 24 15:59:11.553 [conn40] ERROR: can't commitNow from commitIfNeeded, as we are in local db lock 

И ошибки Linux выглядеть следующим образом:

Sat Jan 25 00:20:04.558 [conn19] ERROR: can't commitNow from commitIfNeeded, as we are in local db lock 
0xde46e1 0x921a65 0x921b4c 0x9f8b15 0x9f9412 0x9ffd68 0x6e8518 0xdd0cae 0x7f0cd72d8ddb 0x7f0cd667ca1d 
/usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xde46e1] 
/usr/bin/mongod(_ZN5mongo3dur11DurableImpl16_aCommitIsNeededEv+0x155) [0x921a65] 
/usr/bin/mongod(_ZN5mongo3dur11DurableImpl14commitIfNeededEb+0x4c) [0x921b4c] 
/usr/bin/mongod(_ZN5mongo11insertMultiEbPKcRSt6vectorINS_7BSONObjESaIS3_EERNS_5CurOpE+0x45) [0x9f8b15] 
/usr/bin/mongod(_ZN5mongo14receivedInsertERNS_7MessageERNS_5CurOpE+0x862) [0x9f9412] 
/usr/bin/mongod(_ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0xab8) [0x9ffd68] 
/usr/bin/mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0x98) [0x6e8518] 
/usr/bin/mongod(_ZN5mongo17PortMessageServer17handleIncomingMsgEPv+0x42e) [0xdd0cae] 
/lib64/libpthread.so.0(+0x7ddb) [0x7f0cd72d8ddb] 
/lib64/libc.so.6(clone+0x6d) [0x7f0cd667ca1d] 

Ошибка прерывистые, но, как правило, происходит в блоках 30-90 секунд и за это время я не могу написать никаких данных. Несколько раз мне приходилось убивать процесс, который записывает данные.

Говоря о данных, я пишу около 750 000 довольно простых документов (несколько строк и небольшой встроенный документ). Нет пользовательских индексов, только индекс по умолчанию на _id.

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

Есть ли обходные пути для этого? Специальные настройки конфигурации? Я использую конфигурацию по умолчанию для установки Windows и небольшие изменения журнала для установки Linux.

Answer 1

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

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

Предполагая, что у вас есть другие потоки, делающие записи, я ПОДОЗРЕВАЮ, что возможное обходное решение должно состоять в том, чтобы спать в течение короткого времени, когда вы получаете эту ошибку, чтобы дать другому потоку возможность зафиксировать журнал, не удерживая локальную БД. Но это предположение от чтения кода.

Answer 2

База данных local предназначена только для тиражирования MongoDB и другого внутреннего отслеживания.

Согласно комментарию Аси на SERVER-11670:

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

в этом выпуске она тестируется новый $out функции агрегации против oplog, поэтому пораженный версия 2,5 .3 (разработка/нестабильность), а fixVersion - Тайн.

Если вы хотите записать данные, которые не будут реплицированы, наилучшим подходом является установка отдельного автономного экземпляра mongod. Нет (как в MongoDB 2.4) поддерживаемого способа хранения ваших собственных не реплицированных данных в развертывании набора реплик.