On this page
db.repairDatabase()provides a wrapper around the database command
repairDatabase, and has the same effect as the run-time option
mongod --repairoption, limited to only the current database. See
repairDatabasefor full documentation.
- Before using
repairDatabase, make a backup copy of the dbpath directory.
- Avoid running
repairDatabaseagainst 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
- Only use the
repairDatabasecommand and associated wrappers, including
mongod --repair, if you have no other options. These operations remove and do not save any corrupt data during the repair process.
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.
Changed in version 2.6: The
db.repairDatabase() is now available for secondary as well as primary members of replica sets.