• Reference >
• Database Commands >
• Administration Commands >
• repairDatabase

repairDatabase

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

Warning

This command obtains a global write lock and will block other operations until it has completed.

Note

repairDatabase requires free disk space equal to the size of your current data set plus 2 gigabytes. If the volume that holds dbpath lacks sufficient space, you can mount a separate volume and use that for the repair. When mounting a separate volume for repairDatabase you must run repairDatabase from the command line and use the --repairpath switch to specify the folder in which to store temporary repair files.

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

repairDatabase recreates all indexes in the database.

repairDatabase and compact

The repairDatabase command rebuilds the database, which for MMAPv1, has a secondary effect of compacting all the collections.

For WiredTiger, the operation rebuilds the database but does not result in the compaction of the collections in the database.

See also

compact

Example

Warning

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), see Resync a Member of a Replica Set instead.

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.

Use repairDatabase if you have no other option.

Before using repairDatabase, make a backup copy of the data files in the dbpath.

copy

db.runCommand( { repairDatabase: 1 } )

←   renameCollection setFeatureCompatibilityVersion  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.