Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

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

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

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:

http://www.mongodb.org/display/DOCS/Backups#Backups-Methods

share|improve this answer
    
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 –  Mondain 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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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