How to reclaiming deleted space without `db.repair

问题:

I want to shrink data files size by reclaiming deleted space, but I can't run db.repairDatabase(), because free disk space is not enough.

回答1:

Update: With WiredTiger, compact does free space.

The original answer to this question is here: Reducing MongoDB database file size

There really is nothing outside of repair that will reclaim space. The compact should allow you to go much longer on the existing space. Otherwise, you will have to migrate to a bigger drive.

One way to do this is to use an off-line secondary from your Replica Set. This should give you a whole maintenance window to migrate, repair, move back and bring back up.

If you are not running a Replica Set, it's time to look at doing just that.

回答2:

You could run the compact command on a single collection, or one by one in all the collections you want to shrink.

http://www.mongodb.org/display/DOCS/Compact+Command

db.runCommand( { compact : 'mycollectionname' } )

As noted in comments, I was mistaken, compact does not actually reclaim disk space, it only defragments and rebuilds collection indexes.

Instead though, you could use "--repairpath" option if you have another drive available which has available freespace.

For example:

mongod --dbpath /data/db --repair --repairpath /data/db0

Shown here: http://docs.mongodb.org/manual/tutorial/recover-data-following-unexpected-shutdown/

回答3:

You can as well do a manual mongodump and mongorestore. That's basically the same what repairDatabase does. That way you can dump and restore it to/from a different machine with sufficient disk space.

回答4:

If you're running a replica-set, you will want to issue a resync on each of your secondaries, one at a time. Once this has been completed, step-down your primary and resync the newly assigned secondary.

To resync, stop your mongod instance, delete the locals and start the process back up. Watch the logs to ensure everything starts back up properly and the resync has initiated.

If you have a lot of data / indexes, ensure your oplog is large enough, otherwise it's likely to go stale.

回答5:

There is one other option, if you are using a replica set, but with a lot of caveats. You can fail over to another set member, then delete the files on the now former primary and do a full resync. A full resync rewrites the files from scratch in a similar way to a repair, but you will also have to rebuild indexes. This is not to be done lightly.

If you go down this path, my recommendation would be to have a 3 member replica set before doing this for disk space reclamation, so that at any time when a member is syncing from scratch you have 2 set members fully functional.

If you do not have a replica set, I recommend creating one, with two secondaries. When you sync them initially you will be creating a nice unfragmented and unpadded versions of your data. More here:

http://www.mongodb.org/display/DOCS/Replica+Set+Configuration