#mongodb #database
#mongodb #База данных
Вопрос:
В данный момент наша база данных запущена, и, похоже, все в порядке. Я хотел собрать некоторую статистику, поэтому выполнил несколько стандартных вызовов. В принципе, я хотел количество некоторых конкретных данных.
Сначала несколько базовых вызовов, чтобы показать вам, что в базе данных действительно есть данные.
> db.files.count()
814639
> db.files.find({"migrated":true})
{ "migrated" : true, "filename" : "bleh",... }
...
Итак, очевидно, что данные есть, и вызов возвращает их. Теперь я хочу узнать, сколько существует результатов, но я получаю это:
> db.files.count({"migrated":true})
0
И я тоже это сделал:
> db.files.find({"migrated":true}).count()
0
Есть ли кто-нибудь, у кого есть какие-либо идеи, почему это могло происходить?
Версии:
> db.version()
1.8.1
Любая помощь была бы высоко оценена
Комментарии:
1. Возможно, повреждена база данных? Вы пытались запустить —repair/repairDatabase() ?
2. У нас были некоторые недавние сбои, но после каждого запуска мы выполняли —repair перед его запуском. Проблема в том, что она работает, поэтому я не могу ее отключить. Или я ошибаюсь, полагая, что исправление не может быть выполнено в действующей базе данных?
3. Как бы то ни было, a —repair в основном выполнит дамп и импорт ваших данных. Если какие-либо записи повреждены, они будут удалены во время этого процесса.
4. @Bryan: Как вы думаете, в примере, который я привел, это можно исправить?
5. Я даже не уверен, что проблема в этом, я просто опирался на комментарий, оставленный Sentinel относительно ремонта.
Ответ №1:
Вероятно, этот вопрос связан со следующими ошибками:
- Прерванный запрос count возвращает 0 в качестве результата count
- в некоторых случаях ошибок команда count возвращает ноль вместо сообщения об ошибке с помощью ok:false
В моем случае (mongodb 2.0.1) было связано с повреждением базы данных. Видите ошибку find().count()?
Ответ №2:
Прошло некоторое время, но я закрываю это сейчас. Но это была поврежденная база данных. Пришлось вручную переместить все элементы из одной базы данных в новую, поскольку резервное копирование было остановлено, когда были обнаружены поврежденные данные, и впоследствии резервные копии действительных данных не создавались.