14

I have a MongoDB 2.0.4 installation on Ubuntu 12.10. Recently I had some problems connecting to the database from the outside, and figured out there was something which prevented MongoDB from starting correctly. As suggested on several sources (see StackOverflow) I removed /var/lib/mongodb/mongodb.lock and ran mongod --repair. This didn't solve the problem, MongoDB wouldn't run and kept creating lock files that it didn't take care of removing afterwards. By looking at the logs, I realized that it didn't have access to some folder called $tmpSomething, so (since the name suggested a temporary folder) I removed it, and afterwards it all worked ... except the fact that I only have one of my previous databases in sight, while the other ones are still there because my /var/lib/mongodb/ folder is still full of .ns .0 .1 .n files that weight a lot. Is there a way to restore them into the database? (I have tried with mongorestore, but as I was expecting, it doesn't handle those files).

Thanks

tunnuz
  • 427
  • 2
  • 5
  • 10

1 Answers1

19

The .ns .0 .1 etc. files are the data files themselves. If you started a mongod instance with a --dbpath argument pointing at that folder, or if you moved the contents somewhere else and used the option to point there, mongod will attempt to read them as normal.

Since your issues suggest corruption and/or some other issue starting mongod (you should really post the startup messages log files, perhaps in a separate question to address that issue), then there are alternatives. For reference, the most common problems are permissions related, especially when people try to start mongod manually (as themselves) or with sudo (as root) and create problematic permissions in the various directories.

You are correct that mongorestore cannot use these data files directly, but mongodump can read them and dump data from them into the BSON files that mongorestore expects.

The option you want here is dbpath. You mention your path is /var/lib/mongo, so you can run something like this:

mongodump --dbpath /var/lib/mongo -d <database name> -o /path/to/put/files

Optionally you can use --repair here too to fix corruption along with the query options in extreme circumstances to get around corrupted sections (rarely, if ever, needed). The various options are described on the mongodump page:

http://docs.mongodb.org/manual/reference/mongodump/

Once you dump the files out, you can use mongorestore to reimport them into another mongod instance.

Adam C
  • 5,132
  • 2
  • 28
  • 49
  • 5
    Mongodump 3.0+ [no longer has the --dbpath flag](http://docs.mongodb.org/manual/reference/program/mongodump/#options). – doub1ejack Sep 18 '15 at 15:05
  • correct, you will notice that the question was asked about version 2.0.4 - mongodump will only support repair for the MMAP engine now too - with later versions and in particular with WiredTiger you are limited to the repair option with mongod, mongodump is no longer an option – Adam C Sep 18 '15 at 15:55
  • 2
    With Mongo 3.0 an option is to start the mongo server with specified files: `mongod --dbpath ./` and then proceed with the mongodump without the `--dbpath` – Shwaydogg Jan 03 '16 at 00:33
  • 3
    Just a note, if you are running Mongo 3.0 and `mongod --dbpath ./` does not give you the database in the `.ns .0` files, it could be that the storage engine is defaulting to the new WiredTiger engine instead of the old MMapV1 engine. Try `mongod --storageEngine mmapv1 --dbpath ./` instead to connect using the old engine. – flamebaud May 13 '16 at 14:34
  • 1
    Can anybody help me migrating the data from .ns, .0 and .1 files to mongo 3.0 – Mandeep Singh Jul 27 '16 at 07:18
  • 1
    As @flamebaud said, the default engine has changed. Please check [Default Storage Engine Change](https://docs.mongodb.com/manual/release-notes/3.2-compatibility/#storage-engine-compatibility) in the Mongo documentation. You may also want to have a look at the beginning of the document at [WiredTiger Storage Engine](https://docs.mongodb.com/manual/core/wiredtiger/) – Ludovic Kuty Sep 07 '16 at 03:10