Docs Menu

Docs HomeMongoDB Cluster-to-Cluster Sync


On this page

  • General Limitations
  • MongoDB Community Edition
  • Unsupported Collection Types
  • Sharded Clusters
  • Reversing
  • Multiple Clusters
  • System Collections


mongosync does not check for compliance with the documented limitations. Please ensure that your application is not affected by the limitations . Running mongosync in the presence of one of these limitations could lead to undefined behavior on the destination cluster.

  • The minimum supported server version is MongoDB 6.0.

  • mongosync does not support MongoDB rapid releases such as 6.1 or 6.2. Only major MongoDB releases such as 6.0 or 7.0. are supported. For more information on MongoDB versioning, see MongoDB Versioning.

  • The source and destination clusters must have the same release version.

  • The minimum supported Feature Compatibility Version is 6.0.

  • The source and destination clusters must have the same Feature Compatibility Version.

  • The destination cluster must be empty.

  • mongosync does not validate that the clusters or the environment are properly configured.

  • Other clients must not write to the destination cluster while mongosync is running.

  • If write blocking is disabled, the client must prevent writes to the source cluster before starting the commit process.

  • Synchronizing a subset of the source data, "Filtered Synchronization", is not supported.

  • Network compression is not supported.

  • applyOps operations from the source cluster are not supported.

  • system.* collections are not replicated.

  • Documents that have dollar ($) prefixed field names are not supported. See Field Names with Periods and Dollar Signs.

  • Serverless clusters are not supported.

  • The MongoDB Shared Tier is not supported.

  • Queryable Encryption is not supported.

  • After you replace the mongosync binary during an upgrade or a downgrade, you should drop all non-system databases in the destination cluster before starting the new binary. Syncing operations will restart from the beginning when you start the new processes.

Cluster-to-Cluster Sync supports a limited number of operations with MongoDB Community Edition. Please contact a sales representative to discuss your requirements.

  • Time-series collections are not supported.

  • Capped collections are not supported.

  • Clustered collections with expireAfterSeconds set are not supported.

  • The shard topologies must be the same in the source and target clusters. The following configurations are not supported.

    • Replica set to sharded cluster.

    • Sharded cluster to replica set.

    • Unequal numbers of source and destination shards.

  • Within a collection, the _id field must be unique across all of the shards in the cluster. See Sharded Clusters and Unique Indexes for more details.

  • The movePrimary command cannot be used to reassign the primary shard while syncing.

  • There is no replication for zone configuration. mongosync replicates data, it does not inherit zones.

  • Shards cannot be added or removed while syncing.

  • Only indexes which exist on all shards are synced.

  • The shard key cannot be refined while syncing.

  • The shard key cannot be modified using reshardCollection during syncing.

  • The maximum number of shard key indexes is one lower than normal, 63 instead of 64.

If the old source has unique indexes which are partially distributed across shards, reversing may cause failures. Ensure that unique indexes exist on all shards before reversing.

  • Syncing multiple source clusters to one destination cluster is not supported.

  • Syncing one source cluster to many destination clusters is not supported.

Cluster-to-Cluster Sync does not replicate system collections to the destination cluster.

If you issue a dropDatabase command on the source cluster, this change is not directly applied on the destination cluster. Instead, Cluster-to-Cluster Sync drops user collections and views in the database on the destination cluster, but it does not drop system collections on that database.

For example, on the destination cluster:

  • The drop operation does not affect a user-created system.js collection.

  • If you enable profiling, the system.profile collection remains.

  • If you create views on the source cluster and then drop the database, replicating the drop removes the views, but leaves an empty system.views collection.

In these cases, the replication of dropDatabase removes all user-created collections from the database, but leaves its system collections on the destination cluster.

←  Use mongosync for Disaster RecoveryLogging →
Share Feedback
© 2022 MongoDB, Inc.


  • Careers
  • Investor Relations
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2022 MongoDB, Inc.