replSetResizeOplog dynamically changes a replica-set member’s oplog size after initialization without restarting mongod. Use it when workload patterns consume more oplog space than the default allocation provides. section 9.1.3
Consider a larger oplog when operations create substantial replication history without comparable data growth:
- Batch document updates can expand the oplog because idempotency requires separate logged actions. section 9.1.3
- Balanced deletions and insertions can leave disk use stable while the oplog grows significantly. section 9.1.3
- Frequent in-place updates can generate many oplog entries without enlarging stored documents. section 9.1.3
- Size the oplog so secondaries can retrieve all entries generated during logical initial sync; otherwise entries may be purged too early. section 9.1.3
Listing 9.5 Output of the db.getReplicationInfo() command
db.getReplicationInfo()
{
configuredLogSizeMB: 4096,
logSizeMB: 4096,
usedMB: 4074.63,
timeDiff: 635133,
timeDiffHours: 176.43,
tFirst: 'Wed Mar 20 2024 10:44:15 GMT+0000 (Coordinated Universal Time)',
tLast: 'Wed Mar 27 2024 19:09:48 GMT+0000 (Coordinated Universal Time)',
now: 'Wed Mar 27 2024 19:09:49 GMT+0000 (Coordinated Universal Time)'
}
Inspect configured size, used space, and time window with db.getReplicationInfo() before deciding whether dynamic resizing is needed. section 9.1.3
