replSetResizeOplog and oplog compaction runbook
Parent: Oplog sizing under storage auto-scaling · Published reference · snapshot 2026-10-24 · skill mongodb-cohort-37fc02336c5b
↓ Facts as markdownall context files
Source-anchored research for replSetResizeOplog and oplog compaction runbook. 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.
Definitions
- Configured oplog size is not a strict disk cap: minimum retention can keep entries beyond it, and MongoDB also protects the majority commit point. A smaller configured size alone does not guarantee bounded physical usage. (medium confidence) [source]
How it works
- Connect directly to each member, process secondaries before the primary, and repeat the resize on every intended member: replSetResizeOplog changes do not replicate. (high confidence) [source]
How-to and procedures
- Use a maintenance window and compact members in sequence. For the old primary, step it down and compact it as a secondary; compact itself does not replicate to the other members. (high confidence) [source]
- Check collection storage statistics and filesystem free space after compact; monitor mongod logs or db.currentOp() while it runs. Successful command completion alone does not prove the desired amount was reclaimed. (high confidence) [source]
Measurements and reference values
- For self-managed members, run db.adminCommand({replSetResizeOplog:1,size:Double(16000)}) to set the local oplog maximum to 16000 MB without restarting mongod. The admin command takes megabytes, while unscaled oplog.rs.stats().maxSize reports bytes. (high confidence) [source]
Problems, failure modes and limitations
- The cached MongoDB master source checks an explicitly configured oplog size against existing capped metadata during createOplog and throws error 13257 on mismatch. This supports reviewing pinned startup settings after resizing, but is not a release-specific restart reproduction. (low confidence) (verified as of 2026-10-20) [source]
Facts and statements
- As observed in the current command reference, replSetResizeOplog is unsupported on Atlas; the reference directs Atlas users to the minimum oplog window setting. Do not treat this self-managed runbook as an Atlas command procedure. (low confidence) (verified as of 2026-10-20) [source]
- Logical shrink does not immediately return disk space. For explicit reclamation after shrink, the documented operation is db.getSiblingDB("local").runCommand({compact:"oplog.rs"}); the oplog tutorial says compact adds no benefit after increasing its size. (high confidence) [source]
- Shrinking the oplog can truncate history needed by lagging secondaries, change streams, or mongodump --oplog. Check reader progress and required recovery history before reducing it. (medium confidence) [source]
- Bloodguy publishes a distinct command transcript that reduces maxSize from 2147483648 to 1073741824 bytes and then reports bytesFreed:49152 from compact. Treat this as one unversioned operator observation, not a guarantee of proportional disk recovery. (medium confidence) [source]
- Compaction reclamation depends on the availability and placement of obsolete blocks and may require additional free disk space. An ok response alone does not establish that the desired amount was reclaimed; compare collection statistics and filesystem usage. (medium confidence) [source]
- Monitor compaction with mongod logs or db.currentOp() from another shell, then inspect reclaimed space. Percona demonstrates these checks in a PSMDB 6.0.14 experiment on an ordinary collection. (medium confidence) [source]
- The general compact reference permits secondary replication during compact starting in MongoDB 6.1.0 and 6.0.2. Percona demonstrates concurrent reads and replication on PSMDB 6.0.14 while compacting test.demo; that experiment does not directly test compacting local.oplog.rs. (medium confidence) (verified as of 2024-07-17) [source]
- Do not copy historical drop-and-recreate oplog recipes into a modern runbook: the current oplog tutorial prohibits dropping local.oplog.rs, while Bloodguy retains such a recipe explicitly under its old-version section. (medium confidence) [source]
- Record db.getSiblingDB("local").oplog.rs.stats().maxSize before and after resizing. Unscaled maxSize is bytes, whereas the resize command accepts megabytes. (high confidence) [source]
- Generic compact documentation permits secondary replication and reads from MongoDB 6.0.2/6.1.0. Percona independently demonstrates this on PSMDB 6.0.14-11 for test.demo, not local.oplog.rs. This does not verify uninterrupted replication during oplog compaction. (medium confidence) (verified as of 2024-07-17) [source]
- On versions supporting it, compact dryRun:true estimates reclaimable bytes without compacting; MongoDB documents this option as introduced in 8.0. Additional working disk space may still be required for actual compaction. (low confidence) (verified as of 2026-10-20) [source]
- For authenticated deployments, verify compact privilege on local.oplog.rs explicitly. Current compact documentation requires a custom compact role for system collections; ordinary dbAdmin guidance for non-system collections is insufficient by itself. (medium confidence) (verified as of 2026-10-20) [source]
Children
- No children recorded.