Databases Reference
In-Depth Information
directory to use as a backup. This is especially useful when running on a snapshotting
filesystem, like LVM
*
or EBS
†
, where taking a snapshot of the data directory is a fast
operation.
After performing the backup, we need to unlock the database again:
> db.$cmd.sys.unlock.findOne();
{ "ok" : 1, "info" : "unlock requested" }
> db.currentOp();
{ "inprog" : [ ] }
Here we run the
currentOp
command to ensure that the lock has been released. (It may
take a moment after the unlock is first requested.)
The
fsync
command allows us to take very flexible backups, without shutting down
the server or sacrificing the point-in-time nature of the backup. The price we've paid,
however, is a momentary block against write operations. The only way to have a point-
in-time snapshot without any downtime for reads
or
writes is to backup from a slave.
Slave Backups
Although the options discussed earlier provide a wide range of flexibility in terms of
backups, none is as flexible as backing up from a slave server. When running MongoDB
with replication (see
Chapter 9
), any of the previously mentioned backup techniques
can be applied to a slave server rather than the master. The slave will always have a
copy of the data that is nearly in sync with the master. Because we're not depending
on the performance of the slave or its availability for reads or writes, we are free to use
any of the three options above: shutting down, the dump and restore tools, or the
fsync
command. Backing up from a slave is the recommended way to handle data
backups with MongoDB.
Repair
We take backups so that when a disaster occurs, which could be anything from a power
failure to an elephant on the loose in the data center, our data is safe. There will un-
fortunately always be cases when a server with no backups (or slaves to failover to)
fails. In the case of a power failure or a software crash, the disk will be fine when the
machine comes back up. Because of the way MongoDB stores data, however, we are
not guaranteed that the data on the disk is OK to use: corruption might have occurred
(see
Appendix C
for more on MongoDB's storage engine). Luckily, MongoDB has built-
in repairing functionality to attempt to recover corrupt data files.
* A logical volume manager for Linux
† Amazon's Elastic Block Store
