Replica Set Oplog¶
The oplog (operations log) is a special capped
collection that keeps a rolling record of all operations that modify
the data stored in your databases. MongoDB applies database operations
on the primary and then records the operations on the
primary’s oplog. The secondary members then copy and apply
these operations in an asynchronous process. All replica set members
contain a copy of the oplog, in the
which allows them to maintain the current state of the database.
To facilitate replication, all replica set members send heartbeats (pings) to all other members. Any member can import oplog entries from any other member.
Each operation in the oplog is idempotent. That is, oplog operations produce the same results whether applied once or multiple times to the target dataset.
When you start a replica set member for the first time, MongoDB creates an oplog of a default size. The size depends on the architectural details of your operating system.
In most cases, the default oplog size is sufficient. For example, if an oplog is 5% of free disk space and fills up in 24 hours of operations, then secondaries can stop copying entries from the oplog for up to 24 hours without becoming too stale to continue replicating. However, most replica sets have much lower operation volumes, and their oplogs can hold much higher numbers of operations.
mongod creates an oplog, you can specify its size
oplogSizeMB option. However, after you have started
a replica set member for the first time, you can only change the size
of the oplog using the Change the Size of the Oplog procedure.
By default, the size of the oplog is as follows:
- For 64-bit Linux, Solaris, FreeBSD, and Windows systems, MongoDB allocates 5% of the available free disk space, but will always allocate at least 1 gigabyte and never more than 50 gigabytes.
- For 64-bit OS X systems, MongoDB allocates 183 megabytes of space to the oplog.
- For 32-bit systems, MongoDB allocates about 48 megabytes of space to the oplog.
Workloads that Might Require a Larger Oplog Size¶
If you can predict your replica set’s workload to resemble one of the following patterns, then you might want to create an oplog that is larger than the default. Conversely, if your application predominantly performs reads with a minimal amount of write operations, a smaller oplog may be sufficient.
The following workloads might require a larger oplog size.
Updates to Multiple Documents at Once¶
The oplog must translate multi-updates into individual operations in order to maintain idempotency. This can use a great deal of oplog space without a corresponding increase in data size or disk use.
Deletions Equal the Same Amount of Data as Inserts¶
If you delete roughly the same amount of data as you insert, the database will not grow significantly in disk use, but the size of the operation log can be quite large.
Significant Number of In-Place Updates¶
If a significant portion of the workload is updates that do not increase the size of the documents, the database records a large number of operations but does not change the quantity of data on disk.
Under various exceptional situations, updates to a secondary’s oplog might lag behind the desired performance time. Use
db.getReplicationInfo() from a secondary member and the
output to assess the current state of replication and determine if
there is any unintended replication delay.
See Replication Lag for more information.