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.
This is a classic scale-out use case, and IMO GlusterFS should fit the bill. You can give it a try - just bring a few VMs up, set up a few bricks to be used for repository storage and run a stress test.
DRBD is not an option here anyway - it doesn't scale. If anything, I'd look at other object storage projects (Swift for example), if Gluster doesn't work well enough, but none of them are extremely performance oriented
Best Answer
You cannot share a
dbPath
with multiple activemongod
processes - each process requires exclusive access to the data files.For data redundancy and readonly copies of data, MongoDB supports replica set deployments. A replica set elects a single primary member that accepts writes and can have multiple read-only secondary members. By default all reads and writes are directed to the current primary in a replica set, but your driver or application can use read preferences to read from secondary members. In the event the current primary is unavailable, replica sets also support failover based on your configuration.
However, shared storage is not ideal for a replica set as you will be writing many copies of the same data to the shared storage (which presumably also has some built-in write redundancy).
With or without replication, you should configure MongoDB's Role-Based Access Control (RBAC) so that your applications authenticate with appropriate privileges such as read-only access. The MongoDB Security Checklist has a list of security measures to consider. Even if access is limited to a trusted network, use of RBAC limits your exposure to accidental data modification and provides some audit trail in the MongoDB server logs.