compact
On this page
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.
compacthas the following form:{ compact: <collection name> }compacttakes the following fields:Field Type Description compactstring The name of the collection. forceboolean Optional. If
true,compactcan run on the primary in a replica set. Iffalse,compactreturns an error when run on a primary, because the command blocks all other operations.compactblocks operations only for the database it is compacting.paddingFactornumber Optional. Applicable for the MMAPv1 storage engine only. Specifies the padding to use (as a factor of the document size) during the
compactoperation.The
paddingFactordoes not affect the padding of subsequent record allocations aftercompactcompletes. For more information, see paddingFactor.paddingBytesinteger Optional. Applicable for the MMAPv1 storage engine only. Specifies the padding to use (in absolute number of bytes) during the
compactoperation.paddingBytesdoes not affect the padding of subsequent record allocations aftercompactcompletes. For more information, see paddingBytes.preservePaddingboolean Optional. Applicable for the MMAPv1 storage engine only. Specifies that the
compactprocess should leave document padding intact.This option cannot be used with
paddingFactororpaddingBytes.New in version 2.6.
Warning
Always have an up-to-date backup before performing server maintenance such as the compact operation.
paddingFactor
Note
Applicable for the MMAPv1 storage engine only; specifying paddingFactor has no effect when used with the WiredTiger storage engine.
The paddingFactor field takes the following range of values:
- Default:
1.0 - Minimum:
1.0(no padding) - Maximum:
4.0
If your updates increase the size of the documents, padding will increase the amount of space allocated to each document and avoid expensive document relocation operations within the data files.
You can calculate the padding size by subtracting the document size from the record size or, in terms of the paddingFactor, by subtracting 1 from the paddingFactor:
padding size = (paddingFactor - 1) * <document size>.
For example, a paddingFactor of 1.0 specifies a padding size of 0 whereas a paddingFactor of 1.2 specifies a padding size of 0.2 or 20 percent (20%) of the document size.
With the following command, you can use the paddingFactor option of the compact command to set the record size to 1.1 of the document size, or a padding factor of 10 percent (10%):
db.runCommand ( { compact: '<collection>', paddingFactor: 1.1 } )
compact modifies existing documents, but does not set the padding factor for future documents.
paddingBytes
Note
Applicable for the MMAPv1 storage engine only; specifying paddingBytes has no effect when used with the WiredTiger storage engine.
Specifying paddingBytes can be useful if your documents start small but then increase in size significantly.
For example, if your documents are initially 40 bytes long and you grow them by 1 kB, using paddingBytes: 1024 might be reasonable since using paddingFactor: 4.0 would specify a record size of 160 bytes (4.0 times the initial document size), which would only provide a padding of 120 bytes (i.e. record size of 160 bytes minus the document size).
The following command uses the paddingBytes option to set the padding size to 100 bytes on the collection named by <collection>:
db.runCommand ( { compact: '<collection>', paddingBytes: 100 } )
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 system collections, create a custom role that grants the compact action on the system collection. You can then grant that role to a new or existing user and authenticate as that user to perform the compact command. For example, the following operations create a custom role that grants the compact action against 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.
To add the dbAdmin or the custom role to an existing user, use db.grantRoleToUser or db.updateUser(). The following operation grants the custom compact role to the myCompactUser on the admin database:
use admin
db.grantRoleToUser("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
compact only blocks operations for the database it is currently operating on. Only use compact during scheduled maintenance periods.
You may view the intermediate progress either by viewing the mongod log file or by running the db.currentOp() in 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
compactoperation. You may have to manually rebuild the indexes. - If you do not have journaling enabled and the
mongodorcompactterminates 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
compact has different impacts on available disk space depending on which storage engine is in use.
To see how the storage space changes for the collection, run the collStats command before and after compaction.
WiredTiger
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.
MMAPv1
On MMAPv1, compact defragments the collection’s data files and recreates its indexes. Unused disk space is not released to the system, but instead retained for future data. If you wish to reclaim disk space from a MMAPv1 database, you should perform an initial sync.
compact requires up to 2 gigabytes of additional disk space to run on MMAPv1 databases.
Note
compact may increase the total size and number of your data files, especially when run for the first time. However, this will not increase the total collection storage space since storage size is the amount of data allocated within the database files, and not the size/number of the files on the file system.
Replica Sets
compact commands do not replicate to secondaries in a replica set.
- Compact each member separately.
- Ideally run
compacton a secondary. See optionforce:trueabove for information regarding compacting the primary.
- On secondaries, the
compactcommand forces the secondary to enterRECOVERINGstate. Read operations issued to an instance in theRECOVERINGstate will fail. This prevents clients from reading during the operation. When the operation completes, the secondary returns toSECONDARYstate. - See Replica Set Member States for more information about replica set member states.
See Perform Maintenance on Replica Set Members for an example replica set maintenance procedure to maximize availability during maintenance operations.