1

I read in MongoDB's official documentation:

important: db.fsyncLock() may block reads, including those necessary to verify authentication warning: When calling db.fsyncLock(), ensure that the connection is kept open to allow a subsequent call to db.fsyncUnlock(). Closing the connection may make it difficult to release the lock.

In the worst case scenario, I use fsyncLock() which blocks the database but I then suddenly lose a connection to the database because of temporary network failure. In that scenario, I cannot reconnect because fsyncLock() blocks the reader. My database will be blocked forever.

I am now considering shutting down mongodb to do a backup. What is the safest backup solution for single mongod ?

Wesley
  • 32,690
  • 9
  • 82
  • 117
Luke Nguyen
  • 111
  • 2
  • 7

2 Answers2

5

What is the most safest backup solution for single mongod?

Two options:

  1. Use mongodump against the running mongod. It won't block, but it'll cause some read locking and general noise as it backs up your databases. It's not normally a big deal unless you've got a lot of contention for the database.
  2. Depending on your filesystem, take snapshots of the filesystem and perform a mongodump --dbpath against those files.

Really, you should have a replica set and take backups against a secondary.

Wesley
  • 32,690
  • 9
  • 82
  • 117
  • Dump without explicit lock on mongod may be risk. I am not sure backup data is consistency. I have not ever do something similarly with mysql. For mongo, I am also not sure. Database server is not LVM, single mongod. Do you have any ideas in the case. – Luke Nguyen Dec 25 '14 at 07:32
  • 2
    @LukeNguyen It is not a risk to dump without a lock, mongodump was designed for that. MongoDB Inc [explicitly states in their documentation](http://docs.mongodb.org/manual/reference/program/mongodump/): `Do not use mongodump with db.fsyncLock().` Furthermore, you can use the `--oplog` option with mongodump to write the operations that came in while mongodump was running. You will then need to use the `--oplog` flag when restoring with mongorestore. Really though, you should make a replica set for this for zero-downtime, zero side effect backups. – Wesley Dec 25 '14 at 20:30
1

Depending on your setup, the solution can be different.

I suggest you to read the Backup and Recovery chapter of mongo documentation to decide how to implement it.

If you opt to implement the "Filesystem Snapshot" solution, which I prefer over the others, you can mitigate network problems by issuing the db.fsyncLock() and db.fsyncUnlock() directly from a procedure to be executed on the server where mongo is running.

For example, on a *NIX server, you should be able to make a correct snapshot by running a script like this:

#!/bin/sh
mongo admin --eval "printjson(db.fsyncLock())"
# create file system snapshot
mongo admin --eval "printjson(db.fsyncUnlock())"
# make the backup of entire snapshot
# release the snapshot

By running this script directly on the server where mongo is, the mongo client will connect to the server by using a tcp connection to 127.0.0.1 and your network problems will disappear.

grobx
  • 111
  • 3