initial-sync-and-cdc
Parent: mongosync · Published reference · snapshot 2026-10-19
↓ Facts as markdownall context files
Source-anchored research for initial-sync-and-cdc. 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
- The destination is not guaranteed to match the source at any point while the sync runs, including while paused. Call commit to reach a matching state; at COMMITTING mongosync takes the commit timestamp (time of the latest source operation) and applies events up to it. (high confidence) [source]
Measurements and reference values
- For total size of 64 GB or less migrating to a destination with 4 or fewer CPUs, the copy phase issues fewer concurrent writes. Set an explicit load level at start or restart to override. (low confidence) (verified as of 2026-10-18) [source]
Problems, failure modes and limitations
- canCommit is true only when the initial sync is complete, the embedded verifier is ready, and lag for mongosync and the verifier is 30 seconds or less (30-second rule from 1.21). lagTimeSeconds is deprecated in 1.21; use lag.overallLagSeconds. (low confidence) (verified as of 2026-10-18) [source]
- mongosync is stateless and keeps restart metadata on the destination. After an outage, restart with the same parameters and confirm /progress returns state RUNNING. If the source outage exceeds the oplog window, mongosync cannot resume and the migration restarts from scratch, wiping migrated data. (medium confidence) [source]
- Avoid DDL, rolling index builds, an enabled balancer, and moveChunk/moveRange/movePrimary during the sync. DDL raises failure risk; a balancer enabled after start makes mongosync fail. (medium confidence) [source]
Comparisons and alternatives
- mongosync combines and reorders writes during the sync, so for a given document the number of writes on the destination can differ from the source. Documents are inserted in undefined order, not source natural order. (high confidence) [source]
Facts and statements
- mongosync runs two phases in order: collection copy (initial transfer, by splitting source collections into partitions) and then change event application (CEA), which starts after the copy ends. (high confidence) [source]
- CEA opens a change stream on the source and applies events to the destination. It applies events received during the copy phase first, then events received during CEA. (medium confidence) [source]
- Do not send application reads or writes to the destination until commit has run and /progress shows canWrite true. Do not use mongosync to maintain a standing secondary for DR or analytics. (high confidence) [source]
- Read /progress to see the phase: info is "collection copy", "change event application", "waiting for commit to complete" or "commit completed". collectionCopy.estimatedCopiedBytes is per instance; sum it across instances and divide by estimatedTotalBytes for percent complete. (medium confidence) (verified as of 2026-10-18) [source]
- During the copy, unique indexes sync as non-unique, TTL indexes get expireAfterSeconds set to MAX_INT, hidden indexes sync as non-hidden, and capped collections get the maximum size. These revert during COMMIT. On source 6.0+ (or buildIndexes afterDataCopy) indexes build after the data copy. (medium confidence) [source]
- Transactions might not appear atomically on the destination, and retryable writes may not be retryable there. (low confidence) [source]
Children
- No children recorded.