replSetResizeOplog and oplog compaction on self-managed replica sets
Parent: Oplog sizing under storage auto-scaling · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for replSetResizeOplog and oplog compaction on self-managed replica sets. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- replSetResizeOplog changes do not replicate. Connect directly to each intended member and process secondaries before the primary, as the official resizing procedure directs. (high confidence) [source]
How-to and procedures
- Run db.adminCommand({replSetResizeOplog:1,size:Double(16000)}) on the target self-managed member to set a 16000 MB logical oplog maximum without restarting mongod; unscaled local.oplog.rs.stats().maxSize reports bytes. (high confidence) [source]
Problems, failure modes and limitations
- Reducing the oplog limit does not automatically return allocated disk space. MongoDB prescribes db.getSiblingDB('local').runCommand({compact:'oplog.rs'}) to reclaim unused space after a reduction; its tutorial says compaction provides no benefit after increasing the limit. (high confidence) [source]
- The configured oplog size is not an absolute disk ceiling: retaining the majority commit point can exceed it, and minRetentionHours can preserve entries beyond the size limit until they age out. (high confidence) [source]
- Run db.adminCommand({replSetResizeOplog:1,size:Double(16000)}) to set one self-managed member's oplog limit to 16000 MB without restarting mongod. The change does not propagate to other members. (high confidence) [source]
- MongoDB's resizing procedure handles secondaries first and the primary last. Inspect db.getSiblingDB('local').oplog.rs.stats().maxSize to verify the configured limit; unscaled maxSize is in bytes. (high confidence) [source]
Comparisons and alternatives
- Perform compaction separately on each required member, preferring secondaries; step down the old primary before compacting it. Compaction is not replicated. Check reclaimed space rather than assuming command success guarantees filesystem reduction. (high confidence) [source]
Facts and statements
- Shrinking can truncate history needed by lagging secondaries, change streams, or mongodump --oplog; check reader progress before reducing it. (low confidence) [source]
- For self-managed maintenance, compact secondaries sequentially, step down the old primary, and compact it after it becomes a secondary. The compact command itself does not replicate. (high confidence) [source]
- Compaction attempts to reclaim obsolete blocks; block availability and placement determine effectiveness, and it can need additional free space. Compare storage statistics before and after and monitor mongod logs or db.currentOp(). (medium confidence) [source]
- An independent operator transcript changes oplog maxSize from 2147483648 to 1073741824 bytes and then reports bytesFreed:49152 from compact. This is an unversioned observation, not evidence that shrinking by 1 GiB returns 1 GiB to the filesystem. (low confidence) [source]
- Percona reports replication and reads while compacting the ordinary collection test.demo on PSMDB 6.0.14-11. Its displayed replication entries fall within the compaction interval, but its displayed read timestamp precedes that interval; the read transcript therefore does not independently demonstrate concurrent reads. This experiment does not directly test local.oplog.rs compaction. (low confidence) (verified as of 2024-07-17) [source]
- The general compact reference permits secondary replication starting in 6.0.2/6.1.0; SERVER-68694 records removal of oplog-application blocking with fixes also listed for 4.4.17 and 5.0.12. These are general command changes, not an oplog-collection-specific availability test. (medium confidence) (verified as of 2024-07-17) [source]
- The autoCompact reference explicitly excludes an existing oplog from background compaction; enabling background compaction therefore does not establish oplog disk reclamation. (low confidence) [source]
- For authenticated oplog compaction, verify the compact action on local.oplog.rs. The general compact reference prescribes a custom role for system collections; its ordinary dbAdmin and hostManager guidance is explicitly for non-system collections. (medium confidence) [source]
- Shrinking history can strand lagging secondaries or consumers. MongoDB warns of secondary resynchronization and change-stream invalidation; Stitch documents full collection rereplication after its saved oplog position ages out. (high confidence) [source]
- MongoDB's general compact reference permits secondary replication and reads starting in 6.0.2 and 6.1.0. SERVER-68694 records fixes in 4.4.17, 5.0.12, 6.0.2 and 6.1.0-rc0. These statements alone do not resolve oplog-specific synchronization behavior. (high confidence) (verified as of 2026-10-14) [source]
- Percona's July 2024 demonstration used PSMDB 6.0.14-11 and compacted test.demo while replication continued. It did not compact local.oplog.rs, so it is not a direct test of oplog compaction concurrency. (low confidence) (verified as of 2024-07-17) [source]
- autoCompact, introduced in MongoDB 8.0, explicitly excludes the oplog from background compaction. Enabling it therefore does not replace explicit local.oplog.rs compaction after shrinking an oplog. (low confidence) (verified as of 2026-10-14) [source]
- compact attempts block reclamation; effectiveness depends on free-block placement and it may need additional disk space. MongoDB 8.0 adds dryRun for estimating reclaimable bytes before actual compaction. (low confidence) (verified as of 2026-10-14) [source]
Children
- Logical oplog sizing versus physical disk allocation (frontier)
- Version-specific oplog compaction locking (frontier)
Frontier under this node: Logical oplog sizing versus physical disk allocation, Version-specific oplog compaction locking