Database Reference
In-Depth Information
based backup is that it requires locking the database, but generally you'll lock a
secondary node, and thus should be able to keep your application online for the dura-
tion of the backup.
COPYING THE DATA FILES
Users frequently make the mistake of copying the
data files or taking a snapshot without first locking the database. With journal-
ing disabled, this will result in corruption of the copied files. When journaling
is enabled, it's safe to take a snapshot, but copying the files themselves is
tricky, and easy to botch.
So regardless of whether journaling is enabled, the recommendation of
this topic is to always lock the database before copying data files or taking a
disk snapshot. The resulting peace of mind and guaranteed file integrity are
well worth the minor delay incurred by locking.
To c o p y t h e d a t a f i l e s , y o u f i r s t n e e d t o m a k e s u r e t ha t t h e y ' r e i n a c o n s i s t e n t s t a t e . S o
you either have to shut down the database or lock it. Since shutting down the database
might be too involved for some deployments, most users opt for the locking
approach. Here's the command for syncing and locking:
> use admin
> db.runCommand({fsync: 1, lock: true})
At this point, the database is locked against writes and the data files are synced to disk.
This means that it's now safe to copy the data files. If you're running on a file system
or storage system that supports snapshots, then it's best to take a snapshot and copy
later. This allows you to unlock quickly.
If you can't run a snapshot, then you'll have to keep the database locked while you
copy the data files. If you're copying data files from a secondary node, be sure that the
node is current with the primary and has enough oplog to remain offline for the dura-
tion of the backup.
Once you've finished making a snapshot or backing up, you can unlock the data-
base. The somewhat arcane unlock command can be issued like so:
> db.$cmd.sys.unlock.findOne()
> { "ok" : 1, "info" : "unlock requested" }
Do note that this is merely a
request
to unlock; the database may not unlock right away.
Run the
db.currentOp()
method to verify that the database is no longer locked.
10.3.2
Compaction and repair
MongoDB includes a facility for repairing a database. You can initiate it from the com-
mand line to repair all databases on the server:
$ mongod --repair
Or you can run the
repairDatabase
command to repair a single database:
> use cloud-docs
> db.runCommand({repairDatabase: 1})
