Durability and Repair

Single Server Durability

The v1.8 release of MongoDB will have single server durability. You can follow the Jira here : http://jira.mongodb.org/browse/SERVER-980.

We recommend using replication to keep copies of data for now – and likely forever – as a single server could fail catastrophically regardless.

Repair Command

There is a bug with repair and replica sets in MongoDB v1.6.0. Please see this Jira for information: http://jira.mongodb.org/browse/SERVER-1614. Do NOT run repair without reading this first. This bug applies to 1.6.0 only. Will be fixed in 1.6.1. In the meantime there are workarounds.

After a machine crash or or kill -9 termination, consider running the repairDatabase command. This command will check all data for corruption, remove any corruption found, and compact data files a bit.

In the event of a hard crash, we recommend running a repair – analogous to running fsck. If a slave crashes, another option is just to restart the slave from scratch.

From the command line:

mongod --repair

From the shell (you have to do for all dbs including local if you go this route):

> db.repairDatabase();

During a repair operation, mongod must store temporary files to disk. By default, mongod creates temporary directories under the dbpath for this purpose. Alternatively, the --repairpath command line option can be used to specify a base directory for temporary repair files.

Note that repair is a slow operation which inspects the entire database.

If the databases exited uncleanly and you attempt to restart the database, mongod will print:

**************
old lock file: /data/db/mongod.lock.  probably means unclean shutdown
recommend removing file and running --repair
see: http://dochub.mongodb.org/core/repair for more information
*************

Then it will exit. After running with --repair, mongod will start up normally.

Validate Command

Alternatively one could restart and run the validate command on select tables. The validate command checks if the contents of a collection are valid.

For example, here we validate the users collection:

> db.users.validate();
{
 "ns" : "test.users",
 "result" : " validate
  details: 0x1243dbbdc ofs:740bdc
  firstExtent:0:178b00 ns:test.users
  lastExtent:0:178b00 ns:test.users
  # extents:1
  datasize?:44 nrecords?:1 lastExtentSize:8192
  padding:1
  first extent:
    loc:0:178b00 xnext:null xprev:null
    nsdiag:test.users
    size:8192 firstRecord:0:178bb0 lastRecord:0:178bb0
  1 objects found, nobj:1
  60 bytes data w/headers
  44 bytes data wout/headers
  deletedList: 0000000010000000000
  deleted: n: 1 size: 7956
  nIndexes:2
    test.users.$_id_ keys:1
    test.users.$username_1 keys:1 ",
 "ok" : 1,
 "valid" : true,
 "lastExtentSize" : 8192
}

--syncdelay Command Line Option

Since 1.1.4, the --syncdelay option controls how often changes are flushed to disk (the default is 60 seconds). If replication is not being used, it may be desirable to reduce this default.

See Also

• What About Durability? (MongoDB Blog)
• fsync Command
• MongoDB (Single-Server) Data Durability Guide