I've aksed this question in mongodb google group, in absence of any reply posting it here.
We have a single node mongo (version 2.0.1) instance. We are running out of disk space even after daily archiving as mongo doesn't return the space back to the OS and tries to use it itself. Currently our setup has become very sparse with around 50% space lying idle. You can see that data + index size is around 1170 GB while storage size is around 2158 GB and file size is around 2368 GB.
db.stats()
{
"db" : "default",
"collections" : 106,
"objects" : 553988389,
"avgObjSize" : 2094.1392962010254,
"dataSize" : NumberLong("1160128855044"),
"storageSize" : NumberLong("2315777236208"),
"numExtents" : 1487,
"indexes" : 107,
"indexSize" : 97914435136,
"fileSize" : NumberLong("2543459500032"),
"nsSizeMB" : 16,
"ok" : 1
}
We want to reclaim the space and as this is not a mission critical system (its like a dumping yard for logs) can sustain a downtime. We don't want to spend on creating a replica set also we are in a physical datacenter hence will prefer not to attach additional disk only for repairing database.
I want to understand :-
-How much free disk space is required for repair database
-How much space can we hope to recover after repair database
-Around how much time should it take to repair database.
-If at all repair database keeps going on, is it safe to just kill it and restart the database.
Bulk of our data lie in a single collection so whether compact collection would be better than repair database.
First I would recommend you to upgrade from 2.0.1. At least to 2.0.7 if not 2.2.2. Repair takes 2x file size. You should end up with slightly larger than your data size as your file size. How long it takes depends on system resources and how busy your system is. Compact doesn't free space on disk - it just defragments within the data file.
In 2.2.x you can use collMod
command to set usePowerOf2Sizes to reduce file fragmentation. e.g insert 800 byte document and 1024 bytes will be allocated. Delete that doc and insert a 900 byte doc, now the 1024 space can be reused. Without this maybe only 850 bytes would have been allocated and new free space would have been allocated for the 900 byte document.
killing repairDatabase should be ok - files are copied to new location, defragg'd then copied back in on completion but you would have to test it to be sure :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With