Take the 2-minute tour ×

I've got a MongoDB database that was once large (>3GB). Since then, documents have been deleted and I was expecting the size of the database files to decrease accordingly.

But since MongoDB keeps allocated space, the files are still large.

I read here and there that the admin command mongod --repair is used to free the unused space, but I don't have enough space on the disk to run this command.

Do you know a way I can freed up unused space?

share|improve this question
Is this question considered answered? Do we need more data? –  Gates VP Nov 9 '10 at 22:15

7 Answers 7

UPDATE: as of v1.9+ there is a compact command.

This command will perform a compaction "in-line". It will still need some extra space, but not as much.

MongoDB compresses the files by:

  • copying the files to a new location
  • looping through the documents and re-ordering / re-solving them
  • replacing the original files with the new files

You can do this "compression" by running mongod --repair or by connecting directly and running db.repairDatabase().

In either case you need the space somewhere to copy the files. Now I don't know why you don't have enough space to perform a compress, however, you do have some options if you have another computer with more space.

  1. Export the database to another computer with Mongo installed (using mongoexport) and then you can Import that same database (using mongoimport). This will result in a new database that is more compressed. Now you can stop the original mongod replace with the new database files and you're good to go.
  2. Stop the current mongod and copy the database files to a bigger computer and run the repair on that computer. You can then move the new database files back to the original computer.

There is not currently a good way to "compact in place" using Mongo. And Mongo can definitely suck up a lot of space.

The best strategy right now for compaction is to run a Master-Slave setup. You can then compact the Slave, let it catch up and switch them over. I know still a little hairy. Maybe the Mongo team will come up with better in place compaction, but I don't think it's high on their list. Drive space is currently assumed to be cheap (and it usually is).

share|improve this answer
Thank you Gates VP for your answer. I was thinking of the two options you mentionned. But before doing such things, I wanted to know if a compact in place solution was available. Thanks again. –  Meuble Jun 4 '10 at 17:01
As of today (2010-11-18) Dwight (speaking at the MongoDC event in Washington, DC) recommended the replicate / --repair / switch over approach if you want to compact without taking your database offline. –  David James Nov 18 '10 at 15:46
Just a heads up 'don't do like I did' and run --repair as root. chowns the db files to root. doh. –  Totoro Apr 1 '11 at 1:28
The documentation for 'compact' says: "This operation will not reduce the amount of disk space used on the filesystem." I don't understand how this is a solution to the original question. –  Ed Norris Jul 12 '12 at 17:28
If you look at the original question, part of the problem involved having too much data to perform a repair. If you have filled 2/3 of your drive with one DB, you could not perform a repair. Newly allocated files would suck up the remaining space before the new DB was completely "copied & repaired" and "the switch" would never happen. With compact, he can at least keep the existing files in place. I agree, it's not a full solution, but it's an incremental improvement. –  Gates VP Jul 12 '12 at 20:46

It looks like Mongo v1.9+ has support for the compact in place!

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

See the docs here: http://www.mongodb.org/display/DOCS/compact+Command

"Unlike repairDatabase, the compact command does not require double disk space to do its work. It does require a small amount of additional space while working. Additionally, compact is faster."

share|improve this answer
-1: Doesn't reduce file size –  Anuj Gupta Apr 29 '13 at 12:56
@AnujGupta "The repairDatabase command compacts all collections in the database. It is identical to running the compact command on each collection individually." docs.mongodb.org/manual/reference/command/repairDatabase/…. So if the repairDatabase reduces the size so as compact. I've been compacting my collections with lots of delete and update every week. I like compact more than repariDatabase because first it's targeted to collections you want not the entire database. Second it just needs 2GB free space instead of x2 of your db filesize (in my case 500GB). –  Maziyar Oct 26 '13 at 23:48
Btw check this out:" MongoDB provides 2 different ways to compact your data and restore optimal performance: repairDatabase and compact. RepairDatabase is appropriate if your databases are relatively small, or you can afford to take a node out of rotation for quite a long time. For our database sizes and query workload, it made more sense to run continuous compaction over all our collections." blog.parse.com/2013/03/26/always-be-compacting github.com/ParsePlatform/Ops/blob/master/tools/mongo_compact.rb –  Maziyar Oct 26 '13 at 23:52
@Maziyar docs.mongodb.org/manual/reference/command/compact/#disk-space - "Unlike repairDatabase, compact does not free space on the file system". –  Anuj Gupta Apr 24 at 17:26
@Maziyar OP wants to free up unused space, which is achieved through repairDatabase, not compact. compact does not free up space, it only defragments the used up space, which does not reduce it. –  Anuj Gupta Apr 25 at 18:27

I had the same problem, and solved by simply doing this at the command line:

mongodump -d databasename
echo 'db.dropDatabase()' | mongo databasename
mongorestore dump/databasename
share|improve this answer
+1 exactly what the OP asked for and what I needed, thanks! –  Steve Kehlet Nov 26 '13 at 0:12
assertion: 15936 Creating collection db.collection failed. Errmsg: exception: specify size:<n> when capped is true –  tweak2 Dec 10 '13 at 19:16
:Looks like an ubuntu regression... the dump file has metadata has capped:"undefined" in it... deleting these fixes the import problem. –  tweak2 Dec 10 '13 at 19:19

If you need to run a full repair, use the repairpath option. Point it to a disk with more available space.

For example, on my Mac I've used:

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair

Update: Per MongoDB Core Server Ticket 4266, you may need to add --nojournal to avoid an error:

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair --nojournal
share|improve this answer
thanks, you saved my day! –  Hassek Jul 5 '13 at 15:12

Database files cannot be reduced in size. While "repairing" database, it is only possible for mongo server to delete some of its files. If large amount of data has been deleted, mongo server will "release" (delete), during repair, some of its existing files.

share|improve this answer

In general compact is preferable to repairDatabase. But one advantage of repair over compact is you can issue repair to the whole cluster. compact you have to log into each shard, which is kind of annoying.

share|improve this answer

Compact all collections in current database

db.getCollectionNames().forEach(function (collectionName) {
    print('Compacting: ' + collectionName);
    db.runCommand({ compact: collectionName });
share|improve this answer

Your Answer


