# Oplog capacity for initial sync, live migration and bulk loads > Source-anchored research for Oplog capacity for initial sync, live migration and bulk loads. Run status: COMPLETED. Parent: [Oplog sizing under storage auto-scaling](https://llms-explorer.com/tree/oplog-sizing-under-storage-auto-scaling/) · 4 facets · 17 facts · page: https://llms-explorer.com/tree/oplog-capacity-for-initial-sync-live-migration-and-bulk-loads/ ## How it works - Do not assume every initial-sync mechanism requires the entire clone interval to remain in the source oplog: logical initial sync buffers during cloning. The fetcher must still avoid losing required history, and the sync must preserve operation continuity through catch-up; buffering does not remove source retention requirements. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-sync.md) - Monitor the oplog time window alongside migration lag throughout the migration. MongoDB mongosync and Percona ClusterSync both document comparing db.getReplicationInfo().timeDiff with their respective lag metrics and increasing retention when lag approaches the window. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - Increasing retained history buys catch-up time but does not itself improve migration throughput. When lag remains high, mongosync and Percona ClusterSync documentation also recommend improving synchronization resources or destination performance. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) ## Problems, failure modes and limitations - A June 2, 2025 Percona community incident report describes a mongosync bulk load causing a destination shard secondary to lag beyond retained oplog history and remain unhealthy. This is an anecdotal failure report, not a controlled benchmark or a reason to copy its destructive recovery commands. (low confidence) — [source](https://forums.percona.com/t/mongodb-sharded-cluster-stuck-initializing-due-to-denylisted-sync-source/38185/2) - For Percona ClusterSync, larger queues absorb temporary bursts but do not fix a destination that is permanently slower than the source. Its October 1, 2026 engineering guidance recommends tuning clone and replication concurrency against available CPU and disk capacity; retention headroom alone cannot create sustained apply throughput. (low confidence) — [source](https://www.percona.com/blog/tuning-percona-clustersync-for-mongodb-performance/) - For change-stream-based mongosync and Percona ClusterSync migrations, required changes must remain available in source oplog history. If required operations expire before the migration processes them, synchronization fails; large clones and pauses increase the retention risk. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) ## Comparisons and alternatives - A fixed oplog byte allocation does not imply a fixed retention duration. Higher write volume can shorten the window; evaluate the actual window and lag under the expected migration or bulk-write load instead of relying on a quiet-period measurement. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md) - mongosync consumes change streams rather than reading the source oplog directly, but its historical events must remain inside the source oplog time range. Its sizing guide says synchronization fails if required unapplied operations roll off the source oplog. (low confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - AWS DMS guidance for migration to DocumentDB explicitly requires the source to retain ongoing changes until full load completes for every included collection. For a MongoDB source, size its oplog to hold operations generated during full load. Treat this as DMS-specific guidance rather than a universal model for native replica-set initial sync. (low confidence) — [source](https://docs.aws.amazon.com/documentdb/latest/devguide/migration-quick-start.html) - Bulk maintenance and ingestion planning must account for write history rather than net database growth: multi-document updates expand into individual oplog operations, roughly balanced inserts and deletes can generate a large oplog, and in-place updates can generate history without increasing stored data size. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md) - Minimum retention is a time constraint rather than a strict disk cap: MongoDB removes an entry only after both the configured oplog size is reached and the entry exceeds the minimum age. Budget disk headroom when increasing the retention period. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md) ## Facts and statements - Logical replica-set initial sync fetches new oplog records during collection cloning and index building, stores them in a temporary collection in the destination local database, and applies buffered records afterward. Provision disk for that temporary history; source oplog bytes alone do not cover this destination requirement. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-sync.md) - For a sharded mongosync migration, measure db.getReplicationInfo().timeDiff on each shard and compare the smallest window with lag.overallLagSeconds from /progress. Repeat during migration; if lag approaches that minimum, increase retention or improve migration throughput. (low confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - Plan destination oplog storage separately from source retention. mongosync initial copying generates destination insert oplog entries, and logical initial sync also needs local storage for buffered history; data size alone is therefore insufficient for disk planning. (high confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - Cloud Manager Agent push live migration can buffer the initial-sync oplog window to a configured disk directory. The migration host must have enough storage in that directory for the buffered oplog. This is an agent migration behavior, not a universal mongosync setting. (low confidence) — [source](https://www.mongodb.com/docs/cloud-manager/reference/mongodb-agent-settings.md) - During logical initial sync catch-up, MongoDB checks continuity against the source. A gap requires restarting initial sync. The documented source window requirement includes the buffered-oplog application and final catch-up phases, with additional time for changing conditions. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/replica-set-sync.md) - Plan destination storage for both the migrated dataset and the destination oplog generated by applied writes. Retention on the source and free space on the destination are separate capacity requirements. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md)