Reverse sync and rollback-window economics
Parent: Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Reverse sync and rollback-window economics. 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.
How it works
- Before /reverse is requested, the destination oplog must still retain the history beginning when mongosync reached canWrite=true. Operational inference: delaying reversal consumes available history; the documentation does not guarantee a fixed number of rollback hours or days. (low confidence) (verified as of 2026-10-31) [source]
- Retain mongosync metadata until the rollback decision closes. Dropping __mdb_internal_mongosync or verifier metadata after migration prevents reversal, even when reversible:true was set initially. (medium confidence) (verified as of 2026-10-31) [source]
- For reversible sharded migrations, mongosync leaves any balancers it disabled off after commit. Budget operational attention during the rollback interval and restore balancing when the migration plan permits. (low confidence) (verified as of 2026-10-31) [source]
- After a destination has accepted new transactions, changing application endpoints alone can return users to stale data. AWS migration guidance distinguishes rollback without new data from rollback with changed data; mongosync reverse is a MongoDB-specific mechanism for returning those post-cutover writes. (medium confidence) [source]
- Atlas includes default storage in the running cluster's hourly charge and continues charging storage when the cluster is paused. Pausing does not eliminate all holding costs; the cited documentation does not establish that a paused cluster can satisfy an active reverse-sync recovery objective. (low confidence) (verified as of 2026-10-31) [source]
Problems, failure modes and limitations
- Reverse sync is a planned rollback mechanism: start with reversible:true, commit the initial migration, then reverse replication so destination writes return to the original source. The reversible option cannot be enabled after the sync starts. (high confidence) (verified as of 2026-10-31) [source]
- Atlas's cached configuration-cost documentation describes hourly tier charges, extra charges for customized storage or speed, and backup costs. Pausing a cluster still incurs storage charges; it therefore cannot be modeled as free retention. These are billing categories, not a current price quote. (low confidence) (verified as of 2026-10-31) [source]
- MongoDB warns against using mongosync for a standing disaster-recovery or analytics secondary: the receiving cluster cannot serve application traffic until commit and canWrite=true. Reverse synchronization therefore needs an explicit migration cutover plan. (high confidence) (verified as of 2026-10-31) [source]
- Reversibility is an initial migration decision: /start must set reversible=true, its default is false, and the option cannot be enabled after synchronization starts. (medium confidence) (verified as of 2026-10-31) [source]
Comparisons and alternatives
- Scaleway's migration overview advertises zero downtime and easy rollback, while CloudSpinx's controlled lab observed rejected application writes during commit. Use measured cutover behavior and MongoDB's prerequisites rather than the overview wording as an outage guarantee. (medium confidence) [source]
- mongosync reverse sync swaps the original source and destination after the initial sync is COMMITTED and applies writes made on the destination after canWrite=true. It continues from the existing migration instead of copying the original dataset again. (medium confidence) (verified as of 2026-10-31) [source]
- Scaleway's migration-selection guide describes mongosync as offering easy rollback and flexible migration windows while linking to MongoDB limitations. That service-provider framing is conditional on mongosync's reversal prerequisites, rather than evidence for an unlimited rollback window. (medium confidence) (verified as of 2026-10-31) [source]
Facts and statements
- After /reverse, wait for RUNNING, canCommit:true and lag close to zero, then commit the reverse migration before using the original source; reversing alone leaves it in an intermediate state. (high confidence) (verified as of 2026-10-31) [source]
- Reverse sync requires matching MongoDB major versions and matching shard counts/topologies; filtered migrations and migrations from pre-6.0 sources are excluded. A forward migration that is supported does not automatically have a supported reverse path. (high confidence) (verified as of 2026-10-31) [source]
- Atlas's per-hour cluster charge includes default RAM and storage; storage customizations can add charges, and paused clusters still incur storage charges. Reversal remains subject to mongosync's history and state prerequisites. These resource and prerequisite descriptions do not provide a published valuation of avoided recovery loss or a universal rollback-window break-even duration. (medium confidence) [source]
- A 2024 Percona forum report describes /reverse failing while dropping mongosync_reserved_for_internal_use with a restricted user, while a root-role test succeeded. A respondent suggested database-specific dbAdmin, but the thread does not confirm that fix. Rehearse reverse permissions; do not treat the proposed role as a verified universal remedy. (low confidence) [source]
- CloudSpinx's October 26, 2026 lab found that a root application user could write to the old source despite write blocking. Its old-cluster unblock command restores writability but does not itself reconcile writes accepted by the new destination. Treat that command as insufficient for a lossless post-write rollback. (medium confidence) (verified as of 2026-10-31) [source]
- AppViewX documents a product-specific failover workflow with bidirectional MongoDB networking, pause operations, configuration changes and wrapper stop/start commands. That is evidence of operational rollback work, not proof that its wrapper procedure is equivalent to MongoDB's native /reverse API contract. (low confidence) (verified as of 2026-10-31) [source]
Children
- Rollback decision deadline and oplog retention margin (frontier)
- Migration overlap cost and expected-loss model (frontier)
- Reverse-sync privilege rehearsal (frontier)
- Oplog retention as a rollback constraint (frontier)
- Reverse cutover rehearsal (frontier)
- Incremental cost of retaining a migration source (frontier)
Frontier under this node: Incremental cost of retaining a migration source, Migration overlap cost and expected-loss model, Oplog retention as a rollback constraint, Reverse cutover rehearsal, Reverse-sync privilege rehearsal, Rollback decision deadline and oplog retention margin