Is it possible to recover disk space on replica set secondaries based on the results of a repairDatabase call performed on a primary? I can't seem to locate anything that would work short of bringing the secondaries down and restarting them minus their membership in the replica set. In my scenario I don't have the option to bring them down nor will repairDatabase work on a secondary. I looked at compact, but it does not free disk space.

Informational link: http://www.mongodb.org/display/DOCS/Excessive+Disk+Space


Compact will not recover space, because it really just defragments the data inside the existing data files, making the data more dense, more compact. In fact, a compact occasionally needs extra space to do its work and so can end up using up more space rather than reclaiming it.

Because a repair rewrites the data files from scratch, it reclaims the "wasted" space and recovers disk space.

Besides bringing the secondaries down and running a repair there as you mention, another option is to delete the data files from a secondary and re-sync them from the primary from scratch. This has a similar effect to a repair, because in both cases the data files are re-written, the difference being that you don't need ~2x the disk space because you wipe out the originals and pull the data from the primary.

Once you have done the first secondary, generally the quickest way to do the second would be to snapshot (with journaling enabled) or fsync and lock the secondary and just to a file based copy to seed the other secondary.

Your final option assuming you have run the repair already on the primary, which is really just a variation, would be to snapshot the primary (or fsync and lock) and use its repaired files as a seed to populate a secondary.

These methods are covered in more detail as part of the Backup docs:


  • Thanks for your answer, I did read that compact itself didn't recover on the secondaries. I really hoped there was a db.runCommand that would've "magically" recovered on the secondaries after repair is performed on the primary; but I guess there isn't – Paul Gregoire Nov 8 '12 at 16:27
  • 1
    It is because the operations are what is replicated, not the data, so in that context a repair being replicated really doesn't make sense. I think what you want is the ability to run a repair on a secondary, and as usual, there is a feature request you can vote on for just that - see jira.mongodb.org/browse/SERVER-2264 – Adam C Nov 8 '12 at 22:12

I've been looking into reclaiming disk space this morning.

I'd like to add that as of version 2.6 Mongo permits use of repairDatabase on the secondaries. So the process of recovery is to simply execute db.repairDatabase() on the offending databases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.