- Replication >
- Replica Set Maintenance Tutorials >
- Change the Size of the Oplog
Change the Size of the Oplog¶
On this page
New in version 3.6.
This procedure changes the size of the oplog on each member of a
replica set using the replSetResizeOplog command, starting
with the secondary members before proceeding to the
primary.
Important
You can only run replSetResizeOplog on
replica set member’s running with the
Wired Tiger storage engine.
Perform these steps on each secondary replica set member first. Once you have changed the oplog size for all secondary members, perform these steps on the primary.
A. Connect to the replica set member¶
Connect to the replica set member using the mongo shell:
Note
If the replica set enforces authentication,
you must authenticate as a user with privileges to modify the
local database, such as the clusterManager or
clusterAdmin role.
B. (Optional) Verify the current size of the oplog¶
To view the current size of the oplog, switch to the local
database and run db.collection.stats() against the
oplog.rs collection. stats() displays the
oplog size as maxSize.
The maxSize field displays the collection size in bytes.
C. Change the oplog size of the replica set member¶
To change the size, run the replSetResizeOplog passing
the desired size in megabytes as the size parameter. The
specified size must be greater than 990, or 990 megabytes.
The following operation changes the oplog size of the replica set member to 16 gigabytes, or 16000 megabytes.
D. (Optional) Compact oplog.rs to reclaim disk space¶
Reducing the size of the oplog does not automatically reclaim
the disk space allocated to the original oplog size. You must run
compact against the oplog.rs collection in the
local database to reclaim disk space. There are no benefits to
running compact on the oplog.rs collection after increasing the
oplog size.
Important
The replica set member cannot replicate oplog entries while the
compact operation is ongoing. While compact runs, the
member may fall so far behind the primary that it cannot resume
replication. The likelihood of a member becoming “stale” during
the compact procedure increases with cluster write throughput,
and may be further exacerbated by the reduced oplog size.
Consider scheduling a maintenance window during which writes are throttled or stopped to mitigate the risk of the member becoming “stale” and requiring a full resync.
Do not run compact against the primary replica set member.
Connect a mongo shell to the primary and run
rs.stepDown(). If successful, the primary steps down and
closes all open connections. Reconnect the mongo
shell to the member and run the compact command on the member.
The following operation runs the compact command against the
oplog.rs collection:
If the disk space allocated to the original oplog size is not
reclaimed, restart mongod and run the commands from step
D again. Restarting mongod runs recalculations in
WiredTiger that might allow compact to
release more space to the OS.
For clusters enforcing authentication,
authenticate as a user with the compact privilege
action on the local database and the oplog.rs collection.
For complete documentation on compact authentication
requirements, see compact Required Privileges.