/ /

Administration Commands

Docs Home

/ /

Database Commands

Administration Commands

Administration Commands

compact

This version of the documentation is archived and no longer supported. View the current documentation to learn how to upgrade your version of MongoDB.

Definition

compact

Rewrites and defragments all data and indexes in a collection. On WiredTiger databases, this command will release unneeded disk space to the operating system.

compact has the following form:

{ compact: <collection name> }

compact takes the following fields:

Note

Starting in MongoDB 4.2

MongoDB removes the MMAPv1 storage engine and the MMAPv1 specific options paddingFactor, paddingBytes, preservePadding for compact.

Field	Type	Description
`compact`	string	The name of the collection.
`force`	flag	Changed in version 4.4. Optional. Starting in v4.4, if specified, forces `compact` to run on the primary in a replica set. Before v4.4, this boolean field enabled `compact` to run on the primary in a replica set if the value was `true` and returned an error when run on a primary if the value was `false`, because the command blocked all other operations. Starting in v4.4, `compact` does not block MongoDB CRUD Operations on the database it is compacting.
`comment`	any	Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations: mongod log messages, in the `attr.command.cursor.comment` field. Database profiler output, in the `command.comment` field. `currentOp` output, in the `command.comment` field. A comment can be any valid BSON type (string, integer, object, array, etc). New in version 4.4.

Warning

Always have an up-to-date backup before performing server maintenance such as the compact operation.

`compact` Required Privileges

For clusters enforcing authentication, you must authenticate as a user with the compact privilege action on the target collection. The dbAdmin role provides the required privileges for running compact against non-system collections.

For more information on configuring the resource document, see Resource Document.

To add the dbAdmin or the custom role to an existing user, use db.grantRolesToUser() or db.updateUser(). The following operation grants the custom compact role to the myCompactUser on the admin database:

use admin
db.grantRolesToUser("myCompactUser", [ "dbAdmin" | "myCustomCompactRole" ] )

To add the dbAdmin or the custom role to a new user, specify the role to the roles array of the db.createUser() method when creating the user.

use admin
db.createUser(
  {
     user: "myCompactUser",
     pwd: "myCompactUserPassword",
     roles: [
       { role: "dbAdmin", db: "<database>" } | "myCustomCompactRole"
     ]
   }
)

Behavior

Blocking

Blocking behavior is version specific.

Version	Blocking Behavior
Pre 4.4	`compact` blocks all read and write activity.
4.4	`compact` blocks these operations: `db.collection.drop()` `db.collection.createIndex()` `db.collection.createIndexes()` `db.collection.dropIndex()` `db.collection.dropIndexes()` `collMod` All other operations are permitted.
Post 4.4.17	`compact` blocks these operations: `db.collection.drop()` `db.collection.createIndex()` `db.collection.createIndexes()` `db.collection.dropIndex()` `db.collection.dropIndexes()` `collMod` All other operations are permitted. The locking order changes.

To run compact in a replica set, see Replica Sets for additional considerations.

Monitoring Progress

To check the compact operation's progress, monitor the mongod log file or run db.currentOp() from another shell instance.

Operation Termination

If you terminate the operation with the db.killOp() method or restart the server before the compact operation has finished, be aware of the following:

If you have journaling enabled, the data remains valid and usable, regardless of the state of the compact operation. You may have to manually rebuild the indexes.
If you do not have journaling enabled and the mongod or compact terminates during the operation, it is impossible to guarantee that the data is in a valid state.
In either case, much of the existing free space in the collection may become un-reusable. In this scenario, you should rerun the compaction to completion to restore the use of this free space.

Disk Space

To see how the storage space changes for the collection, run the collStats command before and after compaction.

On WiredTiger, compact attempts to reduce the required storage space for data and indexes in a collection, releasing unneeded disk space to the operating system. The effectiveness of this operation is workload dependent and no disk space may be recovered. This command is useful if you have removed a large amount of data from the collection, and do not plan to replace it.

compact may require additional disk space to run on WiredTiger databases.

Replica Sets

You can use compact on collections and indexes that are stored in a replica set, however there are some important considerations:

The primary node does not replicate the compact command to the secondaries.
You should run compact on secondary nodes whenever possible. If you cannot run compact on secondaries, see the force option.
Starting in MongoDB 4.4.17:
- A secondary node can replicate while compact is running.
- Reads are permitted.

To run compact on a cluster

Compact the secondary nodes.

Run compact on one of the secondary nodes. When compact finishes, repeat the operation on each of the remaining secondaries in turn.

Reassign the primary node.

To step down the current primary and trigger an election, use the rs.stepDown() method. To nominate a particular secondary node, adjust the member priority.

Compact the old primary.

After stepping down, the old primary node becomes a secondary node. Run compact on the old primary node.

Version Specific Considerations for Secondary Nodes

Blocking behavior on secondary nodes is version specific.

Version	Blocking Behavior
Pre 4.4	`compact` blocks all read and write activity. No replication possible. Secondary node is in `RECOVERING` state.
4.4	No replication is possible. Reads are not permitted.
Post 4.4.17	A secondary node can replicate while `compact` is running. Reads permitted.

Replication status while the compact command is running depends on your specific MongoDB version:

In MongoDB versions 4.4.9 and later, the replica set remains in a SECONDARY status.
In MongoDB versions earlier than 4.4.9, compact forces the replica set into the RECOVERING status.

For more information about replica set member states, see See Replica Set Member States.

For replica set maintenance and availability, see Perform Maintenance on Replica Set Members.

Sharded Clusters

compact only applies to mongod instances. In a sharded environment, run compact on each shard separately as a maintenance operation.

You cannot issue compact against a mongos instance.

Index Building

mongod rebuilds all indexes in parallel following the compact operation.

Back

collMod

convertToCapped

Definition

Note

Starting in MongoDB 4.2

Warning

compact Required Privileges

Behavior

Blocking

Monitoring Progress

Operation Termination

Disk Space

Replica Sets

Compact the secondary nodes.

Reassign the primary node.

Compact the old primary.

Version Specific Considerations for Secondary Nodes

Sharded Clusters

Index Building

`compact` Required Privileges