- Replication >
- Change the Size of the Oplog
Change the Size of the Oplog¶
The oplog exists internally as a capped collection, so you cannot modify its size in the course of normal operations. In most cases the default oplog size is an acceptable size; however, in some situations you may need a larger or smaller oplog. For example, you might need to change the oplog size if your applications perform large numbers of multi-updates or deletes in short periods of time.
This tutorial describes how to resize the oplog. For a detailed explanation of oplog sizing, see the Oplog topic in the Replica Set Fundamental Concepts document. For details on the how oplog size affects delayed members and affects replication lag, see the Delayed Members topic and the Check the Replication Lag topic in Replica Set Operation and Management.
Overview¶
The following is an overview of the procedure for changing the size of the oplog:
- Shut down the current primary instance in the replica set and then restart it on a different port and in “standalone” mode.
- Create a backup of the old (current) oplog. This is optional.
- Save the last entry from the old oplog.
- Drop the old oplog.
- Create a new oplog of a different size.
- Insert the previously saved last entry from the old oplog into the new oplog.
- Restart the server as a member of the replica set on its usual port.
- Apply this procedure to any other member of the replica set that could become primary.
Procedure¶
The examples in this procedure use the following configuration:
- The active replica set is
rs0
. - The replica set is running on port
27017
. - The replica set is running with a
data directory
of/srv/mongodb
.
To change the size of the oplog for a replica set, use the following procedure for every member of the set that may become primary.
Shut down the
mongod
instance and restart it in “standalone” mode running on a different port.Note
Shutting down the primary member of the set will trigger a failover situation and another member in the replica set will become primary. In most cases, it is least disruptive to modify the oplogs of all the secondaries before modifying the primary.
To shut down the current primary instance, use a command that resembles the following:
To restart the instance on a different port and in “standalone” mode (i.e. without
replSet
or--replSet
), use a command that resembles the following:Backup the existing oplog on the standalone instance. Use the following sequence of commands:
Note
You can restore the backup using the
mongorestore
utility.Connect to the instance using the
mongo
shell:Save the last entry from the old (current) oplog.
In the
mongo
shell, enter the following command to use thelocal
database to interact with the oplog:Ensure that the temporary collection
temp
is empty by dropping the collection:Use the
db.collection.save()
operation to save the last entry in the oplog to a temporary collection:You can see this oplog entry in the
temp
collection by issuing the following command:
Drop the old
oplog.rs
collection in thelocal
database. Use the following command:This will return
true
on the shell.Use the
create
command to create a new oplog of a different size. Specify thesize
argument in bytes. A value of2147483648
will create a new oplog that’s 2 gigabytes:Upon success, this command returns the following status:
Insert the previously saved last entry from the old oplog into the new oplog:
To confirm the entry is in the new oplog, issue the following command:
Restart the server as a member of the replica set on its usual port:
The replica member will recover and “catch up” and then will be eligible for election to primary. To step down the “temporary” primary that took over when you initially shut down the server, use the
rs.stepDown()
method. This will force an election for primary. If the server’s priority is higher than all other members in the set and if it has successfully “caught up,” then it will likely become primary.Repeat this procedure for all other members of the replica set that are or could become primary.