repairDatabase¶

On this page

Definition
Behavior
Example
Using repairDatabase to Reclaim Disk Space

Definition¶

repairDatabase¶

Checks and repairs errors and inconsistencies in data storage. repairDatabase is analogous to a fsck command for file systems. Run the repairDatabase command to ensure data integrity after the system experiences an unexpected system restart or crash, if:

The mongod instance is not running with journaling enabled.

When using journaling, there is almost never any need to run repairDatabase. In the event of an unclean shutdown, the server will be able to restore the data files to a pristine state automatically.
There are no other intact replica set members with a complete data set.

Warning

During normal operations, only use the repairDatabase command and wrappers including db.repairDatabase() in the mongo shell and mongod --repair, to compact database files and/or reclaim disk space. Be aware that these operations remove and do not save any corrupt data during the repair process.

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, and not use repairDatabase.

repairDatabase takes the following form:

{ 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:

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

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.

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

Behavior¶

Changed in version 2.6: The repairDatabase command is now available for secondary as well as primary members of replica sets.

The repairDatabase command compacts all collections in the database. It is identical to running the compact command on each collection individually.

repairDatabase reduces the total size of the data files on disk. It also recreates all indexes in the database.

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

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. Run as:
```
mongod --repair
```
To add a repair path:
```
mongod --repair --repairpath /opt/vol2/data
```
See repairPath for more information.

Note

mongod --repair will fail if your database is not a master or primary. In most cases, you should recover a corrupt secondary using the data from an existing intact node. To run repair on a secondary/slave restart the instance in standalone mode without the --replSet or --slave options.

Example¶

db.runCommand( { repairDatabase: 1 } )

Using `repairDatabase` to Reclaim Disk Space¶

You should not use repairDatabase for data recovery unless you have no other option.

However, if you trust that there is no corruption and you have enough free space, then repairDatabase is the appropriate and the only way to reclaim disk space.

← getParameter repairCursor →

Was this page helpful?

Yes No

Thank you for your feedback!

We're sorry! You can Report a Problem to help us improve this page.