Oplog Sizing
Parent: MongoDB Capacity Planning · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-321ef5e25160
↓ Facts as markdownall context files
Source-anchored research for Oplog Sizing. 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.
Structure and components
- MongoDB scopes its standard replica-set oplog documentation to Atlas Core and self-managed deployments and says Atlas Infinite handles replication and durability in its storage layer; do not apply standard replica-set size defaults to Atlas Infinite compute nodes without checking its architecture documentation. (low confidence) (verified as of 2026-10-20) [source]
How it works
- On Atlas Core, storage auto-scaling can wait until the oplog window covers estimated scaling time. Atlas documents a maximum minimum-retention window of 60 seconds per configured GB of disk for auto-scaling to complete. Because Atlas says storage-capacity changes affect cost, longer retention can become a storage-cost driver if oplog growth triggers capacity increases; this cost link is an inference from those documented behaviors. Atlas Infinite's minimum oplog window does not affect storage auto-scaling. (medium confidence) (verified as of 2026-10-23) [source]
- The oplog window depends on oplog byte capacity and the rate of oplog generation; estimate size as observed oplog GB per hour multiplied by target retention hours, then validate the actual window and replication lag because write rates change. (high confidence) [source]
Measurements and reference values
- For mongosync initial-copy migrations, the destination needs disk for both the logical data and oplog entries generated during the copy; MongoDB's example uses 10 GB for data plus another 10 GB for destination oplog entries. A large data set or a long pause can also exceed the source oplog window; Alibaba says initial-sync history must cover the full data-copy time, which varies with data volume, collection count, and instance specifications. (high confidence) (verified as of 2026-10-23) [source]
- For Unix and Windows WiredTiger deployments, MongoDB documents a default oplog size of 5% of free disk, bounded by a 990 MB minimum and a 50 GB maximum default; 50 GB is not a hard cap because operators can configure larger sizes and the oplog can exceed its configured size to protect the majority commit point. (high confidence) (verified as of 2026-10-23) [source]
- ApsaraDB for MongoDB documents a 10%-of-total-disk default that scales when disk is increased; MongoDB's standard Unix and Windows WiredTiger default is 5% of free disk, so oplog allocation rules are deployment-specific. (medium confidence) (verified as of 2026-10-20) [source]
Problems, failure modes and limitations
- MongoDB defines the oplog window as the time between the oldest and newest oplog timestamps. Percona says that window depends on oplog size and write rate, and Netdata advises tracking the minimum window during peak write periods. A fixed byte limit therefore represents fewer hours as write volume rises; size from peak oplog generation and the longest lag or outage interval the deployment must survive. (high confidence) [source]
- If a secondary needs an entry that has rolled off its sync source's oplog, it cannot catch up using incremental replication; Alibaba says the member becomes too stale and enters RECOVERING. MongoDB's mongosync documentation says a transfer fails when unapplied source operations roll off, and its change-stream documentation says a resume token can fail after the associated event leaves the oplog. The window must cover the expected outage, lag, or migration copy interval. (high confidence) [source]
- As of 2026-10-23, Atlas documentation says Atlas Core retains oplog entries for at least 24 hours by default and offers a configurable minimum window; storage auto-scaling is enabled by default. A fixed Oplog Size can be set only after opting out of storage auto-scaling, must leave at least 25% of disk capacity free, and cannot be used on Atlas Infinite. Atlas does not support the replSetResizeOplog command. (high confidence) (verified as of 2026-10-23) [source]
- A minimum-retention setting is not a hard byte cap. MongoDB says mongod can grow the oplog beyond its configured maximum to preserve the retention period, which can exhaust disk under high write volume and long retention. Atlas also warns that high-volume bulk writes and migrations may fail to maintain the configured minimum window. Treat the configured retention as a target and check actual window and disk use during bursts. (high confidence) (verified as of 2026-10-23) [source]
Facts and statements
- Atlas Live Migration currently recommends a destination cluster tier at least two tiers above the source to accommodate storage fluctuations related to oplog requirements; embedded verification also needs a large destination oplog. This is migration-specific guidance, not a steady-state tier-sizing rule. (high confidence) (verified as of 2026-10-23) [source]
- Choose the target window from the longest expected secondary downtime and recovery or maintenance interval: MongoDB documents 24 hours as a minimum and notes some users prefer 72 hours or a week, while Percona's advisor uses 24–48 hours as its heuristic. (medium confidence) (verified as of 2026-10-23) [source]
- High-write patterns can create more oplog bytes than collection-size growth suggests: MongoDB documents multi-document updates expanded into individual oplog operations, deletes that offset inserts, and in-place updates that do not grow documents. (high confidence) [source]
- Minimum retention with oplogMinRetentionHours removes entries only after the oplog reaches its configured size and the entries are old enough; high write rates with a long retention period can therefore exceed the configured size and exhaust disk. (high confidence) [source]
- Reducing the configured oplog size does not immediately reclaim allocated disk; MongoDB requires compact to reclaim it, and compacting oplog.rs prevents oplog synchronization during that maintenance operation. (high confidence) [source]
- MongoDB's current replSetResizeOplog documentation says the command is not supported in Atlas clusters, so a sizing plan that depends on this command needs a supported Atlas-specific control path. (low confidence) (verified as of 2026-10-23) [source]
Children
- Peak write rate to oplog retention-window conversion (frontier)
- Atlas oplog retention and storage auto-scaling (frontier)
- Oplog retention for live migrations and change-stream recovery (frontier)
Frontier under this node: Atlas oplog retention and storage auto-scaling, Oplog retention for live migrations and change-stream recovery, Peak write rate to oplog retention-window conversion