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

repairDatabase

Definition

repairDatabase

Rebuilds the database and indexes by discarding invalid or corrupt data that may be present due to an unexpected system restart or shutdown. 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 after an unclean shutdown since the server can use the journal files to restore the data files to a clean state automatically. However, you may need to run repairDatabase in cases where you need to recover from a disk-level data corruption.
• 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 related db.repairDatabase() method and the --repair command-line option) 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 MMAPv1 options as follows:

copy

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

repairDatabase Operations

In addition to the repairDatabase command, the mongo shell provides db.repairDatabase() as a wrapper around the repairDatabase command. For more information on the method, see db.repairDatabase().

MongoDB also provides the option to run mongod --repair directly from the command line to repair all databases for the mongod. Starting in MongoDB 4.0.3, mongod --repair performs a more extensive repair operation than the repairDatabase command. For more information on running mongod --repair, see --repair.

Behavior

Warning

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

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

repairDatabase recreates all indexes in the database.

MMAPv1

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. For example:

copy

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

See --repairpath for more information.

WiredTiger

repairDatabase performs the operation in-place and does not require additional disk space.

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 repair since the server can use the journal files to restore the data files to a clean state automatically. However, you may need to run repair in cases where you need to recover from a disk-level data corruption.

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.