On this page

• Definition
• repairDatabase Wrappers
• Behavior
• Example

Definition

repairDatabase

Rebuilds the database and indexes by discarding invalid or corrupt data, which may be present due to an unexpected system restart or crash. repairDatabase is analogous to a fsck command for file systems.

Warning

• Before using repairDatabase, make a backup copy of the files in the dbpath directory.
• If you are running with journaling enabled, there is almost never any need to run repairDatabase unless you need to recover from a disk-level data corruption. In the event of an unclean shutdown, the server will be able to restore the data files to a clean state automatically.
• Avoid running repairDatabase against a replica set. If you are trying to repair a replica set member, and you have access to an intact copy of your data (e.g. a recent backup or an intact member of the replica set), you should restore from that intact copy (see Resync a Member of a Replica Set), and not use repairDatabase.
• You should only use the repairDatabase command and associated wrappers if you have no other options. These operations remove and do not save any corrupt data during the repair process.

repairDatabase takes the following form:

copy

{ repairDatabase: 1 }

repairDatabase has the following fields:

Field	Type	Description
preserveClonedFilesOnFailure	boolean	When true, repairDatabase will not delete temporary files in the backup directory on error, and all new files are created with the “backup” instead of “_tmp” directory prefix. By default repairDatabase does not delete temporary files, and uses the “_tmp” naming prefix for new files. Changed in version 3.0: preserveClonedFilesOnFailure is only available with the mmapv1 storage engine.
backupOriginalFiles	boolean	When true, repairDatabase moves old database files to the backup directory instead of deleting them before moving new files into place. New files are created with the “backup” instead of “_tmp” directory prefix. By default, repairDatabase leaves temporary files unchanged, and uses the “_tmp” naming prefix for new files. Changed in version 3.0: backupOriginalFiles is only available with the mmapv1 storage engine.

You can explicitly set the options as follows:

copy

{ repairDatabase: 1,
  preserveClonedFilesOnFailure: <boolean>,
  backupOriginalFiles: <boolean> }

See mongod --repair and mongodump --repair for information on these related options.

repairDatabase Wrappers

You may invoke repairDatabase from multiple contexts:

• Use the mongo shell to run the command, as above.

• Use the db.repairDatabase() in the mongo shell.

• Run mongod directly from your system’s shell. Make sure that mongod isn’t already running, and that you invoke mongod as a user that has access to MongoDB’s data files:

  copy

  mongod --repair
  

  For MMAPv1, you can specify a temporary working directory that the command will use during the repair operation:

  copy

  mongod --repair --repairpath /opt/vol2/data
  

  See repairPath for more information.

Behavior

The time requirement for repairDatabase depends on the size of the data set.

repairDatabase recreates all indexes in the database.

Example

db.runCommand( { repairDatabase: 1 } )