Docs Menu
Docs Home
/
MongoDB Cluster-to-Cluster Sync
/

Limitations

On this page

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

Warning

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.

Note

For information on MongoDB server compatility, see MongoDB Server Version Compatibility and Support.

  • The destination cluster must be empty.

  • mongosync doesn't 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.

  • system.* collections aren't replicated.

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

  • Serverless clusters aren't supported.

  • A MongoDB Shared Tier isn't supported.

  • Queryable Encryption isn't supported.

  • You cannot sync a collection that has a unique index and a non-unique index defined on the same field(s).

  • Before you attempt to run mongosync with an M10+ Atlas cluster, disable the Require Indexes for All Queries option.

  • mongosync doesn't sync users or roles.

  • mongosync does not replicate applyOps operations made on the source cluster during sync to the destination cluster.

  • mongosync must read from the source cluster using the primary read preference.

  • mongosync does not support syncing Atlas Search Indexes.

MongoDB does not test Cluster-to-Cluster Sync with Community builds and in most cases, MongoDB does not offer support for Cluster-to-Cluster Sync with Community deployments. If you would like to use Cluster-to-Cluster Sync with MongoDB Community Edition, contact a MongoDB sales representative to discuss requirements and individualized options.

  • Time-series collections aren't supported.

  • Clustered collections with expireAfterSeconds set aren't supported.

  • mongosync doesn't support sync from a sharded cluster to a replica set.

  • Sync from a replica set to a sharded cluster has the following limitations:

    • mongosync allows users to rename collections that the sharding.shardingEntries option for the start command includes during sync. To see limitations on renaming collections while mongosync is running, see Renaming During Sync.

    • When using the sharding.createSupportingIndexes option to create indexes supporting shard keys on the destination cluster during sync, you cannot create these indexes afterwards on the source cluster.

      The index must either exist before mongosync starts or be created after the migration is complete and mongosync has stopped.

  • 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 doesn't inherit zones.

  • Shards cannot be added or removed while syncing.

  • mongosync only syncs indexes that exist on all shards.

  • mongosync only syncs indexes that have consistent index specifications on all shards.

    Note

    To check for index inconsistencies, see Find Inconsistent Indexes Across Shards.

  • You must stop the balancer on a sharded source cluster until mongosync finishes the collection copy phase.

    Note

    After stopping the balancer, wait fifteen minutes before starting mongosync. This gives the cluster time to finish any in progress chunk migrations.

  • You must not run the moveChunk and moveRange commands on the source cluster.

  • The shard key cannot be refined while syncing.

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

  • The maximum number of indexes per sharded collection is 63, which is one less than the default limit of 64.

  • mongosync only supports syncing sharded collections that have default collation settings.

  • 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.

  • The source and destination clusters must have the same number of shards. You cannot reverse sync when the clusters have different topologies or major versions.

  • mongosync does not support syncing multiple source clusters to one destination cluster.

  • One cluster cannot simultaneously be a source cluster in one mongosync instance and a destination cluster in another mongosync instance.

  • Filtering is not supported with reversible sync.

  • The destination cluster must not contain user data prior to starting.

  • The destination cluster must not contain the mongosync_reserved_for_internal_use system database prior to starting.

  • You cannot modify a filter that is in use. To create a new filter, see: Replace an Existing Filter.

  • You can only rename collections in certain situations. For more details see: Adding and Renaming Collections.

  • If a filter includes a view but not the base collection, only the view metadata syncs to the destination cluster. To include the view documents, you must also sync the base collection.

  • You cannot specify system collections or system databases in a filter.

  • To use the $out aggregation stage or the mapReduce command (when set to create or replace a collection) with filtering, you must configure the filter to use the entire database. You cannot limit the filter to collections within the database.

    For more information, see Filtering with mapReduce and $out.

Starting in 1.3.0, Cluster-to-Cluster Sync supports capped collections with some limitations.

Capped collections on the source cluster work normally during sync.

Capped collections on the destination cluster have temporary changes during sync:

  • There is no maximum number of documents.

  • The maximum collection size is 1PB.

mongosync restores the original values for maximum number of documents and maximum document size during commit.

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 Recovery
Logging →