Docs Menu
Docs Home
/
MongoDB Manual
/ / /

compact

On this page

  • Definition
  • Compatibility
  • Syntax
  • Command Fields
  • compact Required Privileges
  • Behavior
  • Example
compact

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

This command is available in deployments hosted in the following environments:

  • MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud

Important

This command is not supported in M0, M2, and M5 clusters. For more information, see Unsupported Commands.

The command has the following syntax:

db.runCommand(
{
compact: <string>,
force: <flag>, // Optional
freeSpaceTargetMB: <int>, // Optional
comment: <any>, // Optional
}
)

The command takes the following fields:

Field
Type
Description
compact
string
The name of the collection.
force
flag

Optional. If specified, forces compact to run on the primary in a replica set. compact does not block MongoDB CRUD Operations on the database it is compacting.

freeSpaceTargetMB
Integer

Optional. Specifies the minimum amount of storage space, in megabytes, that must be recoverable for compaction to proceed. Compaction proceeds only if the amount of free storage space available is greater than freeSpaceTargetMB.

Default: 20

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:

A comment can be any valid BSON type (string, integer, object, array, etc).

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 system collections, you must:

  1. Create a custom role that grants the compact action on the system collection.

  2. Grant that role to a new or existing user.

  3. Authenticate as that user to perform the compact command.

For example, the following operations create a custom role that grants the compact action against the specified database and collection:

use admin
db.createRole(
{
role: "myCustomCompactRole",
privileges: [
{
resource: { "db" : "<database>" , "collection" : "<collection>" },
actions: [ "compact" ]
}
],
roles: []
}
)

For more information on configuring the resource document, see Resource Document on Self-Managed Deployments.

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"
]
}
)

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

If you terminate compact with the db.killOp() method or restart the server before the operation finishes, compact ends and may fail its attempt to release disk space back to the operating system.

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.

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 6.1.0 (and 6.0.2 and 5.0.12):

    • A secondary node can replicate while compact is running.

    • Reads are permitted.

To run compact on a cluster

1

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

2

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.

3

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

  • A secondary node can replicate while compact is running.

  • Reads are permitted.

While the compact command is running, the replica set remains in a SECONDARY 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 Self-Managed Replica Set Members.

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.

mongod rebuilds all indexes in parallel following the compact operation.

The following operation runs the compact command on the movies collection:

db.runCommand( { compact: "movies" } )

Running compact returns output similar to the following:

{ bytesFreed: 27859, ok: 1 }

Back

collMod