compact
On this page
Definition
Compatibility
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.
MongoDB Enterprise: The subscription-based, self-managed version of MongoDB
MongoDB Community: The source-available, free-to-use, and self-managed version of MongoDB
Syntax
The command has the following syntax:
db.runCommand( { compact: <string>, dryRun: <boolean>, force: <boolean>, // Optional freeSpaceTargetMB: <int>, // Optional comment: <any>, // Optional } )
Command Fields
The command takes the following fields:
Field | Type | Description |
---|---|---|
compact | string | The name of the collection. |
dryRun | boolean | New in version 8.0. If enabled, the Default: False |
force | boolean | Changed in version 4.4. Optional. If enabled, forces |
freeSpaceTargetMB | Integer | Optional. Specifies the minimum amount of storage space, in megabytes, that must be recoverable for compaction to proceed. 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). |
compact
Required Privileges
For clusters enforcing authentication,
you must authenticate as a user with the compact
privilege
action on the target collection. The dbAdmin
and
hostManager
roles provide the required privileges for running
compact
against non-system collections.
For system collections, you must:
Create a custom role that grants the
compact
action on the system collection.Grant that role to a new or existing user.
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
, hostManager
, 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
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 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.
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.
Performance Considerations
Compaction regularly checkpoints the database, which can lead to synchronization overhead. On high-traffic databases, this can potentially delay or prevent operational tasks such as taking backups. To avoid unexpected disruptions, disable compaction before taking a backup.
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 runcompact
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
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.
Version Specific Considerations for Secondary Nodes
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.
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.
Concurrent Compact Commands Not Allowed
If you try to run multiple concurrent compact
commands on the same
collection, MongoDB returns an error.
Example
Compact a Collection
The following operation runs the compact
command on the
movies
collection:
db.runCommand( { compact: "movies" } )
{ bytesFreed: 27859, ok: 1 }
Estimate Compaction
The following operation performs a dry run of the compact
command on the
movies
collection:
db.runCommand( { compact: "movies", dryRun: true } )
{ estimatedBytesFreed: 27859, ok: 1 }