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

1 Answer 1

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.

6
  • 5
    Mongodump 3.0+ no longer has the --dbpath flag.
    – doub1ejack
    Sep 18, 2015 at 15:05
  • 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 3, 2016 at 0: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, 2016 at 14:34
  • 1
    Can anybody help me migrating the data from .ns, .0 and .1 files to mongo 3.0
    – MSH
    Jul 27, 2016 at 7:18
  • 1
    As @flamebaud said, the default engine has changed. Please check Default Storage Engine Change in the Mongo documentation. You may also want to have a look at the beginning of the document at WiredTiger Storage Engine Sep 7, 2016 at 3:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .