# replSetResizeOplog and oplog compaction on self-managed replica sets > Source-anchored research for replSetResizeOplog and oplog compaction on self-managed replica sets. Run status: COMPLETED. Parent: [Oplog sizing under storage auto-scaling](https://llms-explorer.com/tree/oplog-sizing-under-storage-auto-scaling/) · 5 facets · 20 facts · page: https://llms-explorer.com/tree/replsetresizeoplog-and-oplog-compaction-on-self-managed-replica-sets/ ## 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](https://www.mongodb.com/docs/manual/reference/command/replSetResizeOplog.md) ## 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](https://www.mongodb.com/docs/manual/reference/command/replSetResizeOplog.md) ## 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](https://www.mongodb.com/docs/manual/tutorial/change-oplog-size.md) - 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](https://www.mongodb.com/docs/manual/reference/command/replSetResizeOplog.md) - 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](https://www.mongodb.com/docs/manual/reference/command/replSetResizeOplog.md) - 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](https://www.mongodb.com/docs/manual/tutorial/change-oplog-size.md) ## 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](https://www.mongodb.com/docs/manual/reference/command/compact.md) ## 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](https://www.mongodb.com/docs/manual/reference/command/replSetResizeOplog.md) - 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](https://www.mongodb.com/docs/manual/tutorial/change-oplog-size.md) - 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](https://www.mongodb.com/docs/manual/reference/command/compact.md) - 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](https://bloodguy.tistory.com/entry/MongoDB-oplog-resize) - 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](https://www.percona.com/blog/using-compact-in-percona-server-for-mongodb-from-version-4-4/) - 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](https://www.mongodb.com/docs/manual/reference/command/compact.md) - The autoCompact reference explicitly excludes an existing oplog from background compaction; enabling background compaction therefore does not establish oplog disk reclamation. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/autoCompact.md) - 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](https://www.mongodb.com/docs/manual/tutorial/change-oplog-size.md) - 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](https://www.mongodb.com/docs/manual/reference/command/replSetResizeOplog.md) - 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](https://www.mongodb.com/docs/manual/reference/command/compact.md) - 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](https://www.percona.com/blog/using-compact-in-percona-server-for-mongodb-from-version-4-4/) - 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](https://www.mongodb.com/docs/manual/reference/command/autoCompact.md) - 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](https://www.mongodb.com/docs/manual/reference/command/compact.md)