# mongosync and live-migration oplog capacity planning > Source-anchored research for mongosync and live-migration oplog capacity planning. Run status: COMPLETED. Parent: [Oplog sizing under storage auto-scaling](https://llms-explorer.com/tree/oplog-sizing-under-storage-auto-scaling/) · 5 facets · 12 facts · page: https://llms-explorer.com/tree/mongosync-and-live-migration-oplog-capacity-planning/ ## How it works - For Atlas live migration, increase the source minimum oplog window when storage auto-scaling is enabled; increase a fixed source oplog size when storage auto-scaling is disabled. Apply the corresponding retention choice to the destination when embedded verification needs a larger history window. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/live-migration.md) - Percona ClusterSync documentation separately confirms that source change-stream history must survive until application and that destination storage must hold the dataset and generated oplog. It suggests reducing destination retention only when extended retention is unnecessary; its guidance concerns PCSM and does not establish mongosync embedded-verifier requirements. (low confidence) (verified as of 2026-10-13) — [source](https://docs.percona.com/percona-clustersync-for-mongodb/oplog-sizing.html) ## Measurements and reference values - MongoDB illustrates destination copy overhead with a 10 GB logical migration requiring at least another 10 GB for initial-sync insert oplog entries. This is the documentation example, not a complete physical disk-sizing formula including indexes, compression, or ongoing workload. (low confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) ## Problems, failure modes and limitations - Mongosync consumes change streams backed by retained oplog history; if required source changes roll off before application, synchronization fails. Percona documents the same retention requirement for its own ClusterSync implementation. Large datasets, pauses, and slow synchronization increase this risk. (high confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - A destination oplog constrained enough to prevent the embedded verifier from keeping up can fail the migration. Source retention alone is insufficient capacity planning when embedded verification is enabled. (high confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - If destination capacity cannot support embedded verification, Atlas documents disabling that verifier and using another verification method. A January 2025 forum reply reports the same mitigation for a live-migration progress error associated with destination oplog exhaustion; the thread does not prove that every progress error has that cause. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/live-migration.md) - Reducing destination oplog retention to save migration overhead is conditional on verification requirements. Mongosync warns that a smaller destination oplog can make the embedded verifier fall behind and fail; Atlas recommends sufficient destination retention or an alternative verification method when adequate retention cannot be allocated. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) ## Comparisons and alternatives - Treat oplog enlargement and faster synchronization as complementary remedies: MongoDB recommends increasing the retained window or adding CPU and memory to the mongosync host, while Percona additionally identifies destination write performance and network placement as factors in reducing its migration lag. A larger window supplies time rather than fixing a sustained throughput deficit; that last distinction is an operational inference. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) ## Facts and statements - For mongosync initial-sync capacity checks, compare /progress lag.overallLagSeconds with db.getReplicationInfo().timeDiff on the source; for sharded sources use the smallest shard window. If lag approaches that window, extend retention or increase mongosync CPU or memory to improve copying. Atlas does not support replSetResizeOplog; use its minimum-window configuration. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - In a July 19, 2026 first-person production migration account, Harikrishnan explicitly included checking retained history on both source and destination during mongosync collection copy. This is independent practitioner evidence for considering both sides, but the account supplies no measured oplog-byte budget or validated retention duration. (low confidence) — [source](https://harikrishnanjr.com/blog/mongosync) - The separate MongoDB Labs migration-verifier warns that verifier lag can exceed oplog capacity, permanently failing that verification run and requiring a restart. Switching away from embedded verification therefore does not automatically eliminate oplog planning for a change-stream-based alternative verifier. (low confidence) (verified as of 2026-10-27) — [source](https://github.com/mongodb-labs/migration-verifier) - Budget destination storage for both the migrated dataset and the oplog generated by migration writes. MongoDB and Percona each document these as separate destination capacity requirements; dataset size alone is insufficient. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md)