# resume-and-checkpoint > Source-anchored research for resume-and-checkpoint. Run status: COMPLETED. Parent: [mongosync](https://llms-explorer.com/tree/mongosync/) · 5 facets · 15 facts · page: https://llms-explorer.com/tree/resume-and-checkpoint/ ## How it works - Mongosync's binary is stateless; restart metadata lives on the destination cluster. After a recoverable interruption, restart the process with its original connection parameters to continue the migration. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/mongosync/current/faq/) - Creationline's mongosync 1.8.1 experiment logged a destination bootstrap lookup in mongosync_reserved_for_internal_use.resumeData. A standalone destination failed initialization with NotAReplicaSet because the lookup required replica-set read concern. This historical log identifies a resume-data dependency, not a supported metadata-editing interface. (low confidence) — [source](https://www.creationline.com/tech-blog/author/k-yamamori/75841) - Mongosync does not automatically restart after errors. Its FAQ recommends a script or process manager such as systemd; RightTouch's migration ran the worker under systemd, illustrating external process supervision. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/mongosync/current/faq/) ## How-to and procedures - To continue an intentionally paused session, POST an empty JSON object to /api/v1/resume. The endpoint requires PAUSED state and returns the session to RUNNING on success. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/api/resume.md) ## Problems, failure modes and limitations - Resume is not necessarily immediate: the API warns of at least two minutes before migration resumes. The FAQ dates this behavior to 1.7.3 and says progress calls can temporarily fail and may safely be retried. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/api/resume.md) - Migration continuation does not imply verifier continuation. The embedded verifier keeps state in memory and cannot resume; stopping or pausing sync and then starting mongosync again restarts verification from the beginning and can leave it substantially behind migration. (low confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/mongosync/current/reference/verification/embedded/) - The FAQ distinguishes fatal failures from recoverable interruptions: after correcting a fatal error it instructs operators to delete migrated destination data, including __mdb_internal_mongosync, and start a new migration. A supervisor restart alone is therefore insufficient for every failure. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/mongosync/current/faq/) ## Comparisons and alternatives - A paused migration is not a consistent application checkpoint: mongosync can combine or reorder writes, so the destination may differ from the source even while paused. Commit and canWrite=true are required before application read or write traffic. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior/) ## Facts and statements - Recovery depends on source oplog retention. If a source outage exceeds the oplog window, MongoDB requires restarting the migration from the beginning, removing migrated destination data. Mafiree separately recommends increasing the source oplog before a long pause. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior/) - Restart does not preserve partial progress within every collection-copy partition: MongoDB's reconfiguration procedure says partitions in progress at termination restart from their beginning. (low confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/configuration.md) - RightTouch reported that destination Atlas autoscaling triggered a rolling restart during rehearsal, interrupted the verifier, and prevented resumption in that run. For production it fixed the destination at a larger tier. This is a specific operational report, not a universal claim about every cluster restart. (low confidence) (verified as of 2026-10-13) — [source](https://tech.righttouch.co.jp/entry/2026/10/13/123032) - AppViewX's 2026.3.0 integration prescribes pausing both sites before maintenance and resuming the destination wrapper before the source wrapper afterward. These are AppViewX-specific mongosync_utility.sh commands, not a general ordering rule for the native mongosync API. (low confidence) (verified as of 2026-10-23) — [source](https://docs.appviewx.com/2026.3.0/oxy_ex/appviewx_mongosync_setup_and_operations_guide.html) - After a source or destination cluster crash, restart mongosync with the original connection-string parameters once the cluster is online. Confirm recovery by checking that /progress reports RUNNING. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior/) - While mongosync is PAUSED, MongoDB does not support upgrading either cluster’s MongoDB version or enabling and then disabling the balancer. Upgrading the mongosync binary while paused is supported. (low confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior/) - For sharded migrations with multiple mongosync instances, the resume API documentation requires identical endpoint commands to each instance. Resuming one instance does not resume every instance. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/api/resume.md)