Docs Home → MongoDB Cluster-to-Cluster Sync
Limitations
On this page
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.
General Limitations
The minimum supported server versions are MongoDB 6.0.8 and 7.0.0.
Starting in version 1.2,
mongosync
can sync between clusters running some older (pre-6.0) releases of MongoDB Server. This feature requires additional preparation and configuration in pre-6.0 releases.If you would like to migrate pre-6.0 versions of MongoDB Server using
mongosync
, please contact your account team to inquire about Professional Services.mongosync
does not support MongoDB rapid releases such as 6.1 or 6.2. The minimum supported server version is MongoDB 6.0.5. For more information on MongoDB versioning, see MongoDB Versioning.The source and destination clusters must have the same major and minor release version, but can have different patch releases.
For example,
mongosync
supports sync from a MongoDB 6.0.8 source cluster to a- MongoDB 6.0.9 destination cluster, since these are patch releases
of the same major release.
mongosync
does not support sync from a MongoDB 6.0.9 source cluster to a MongoDB 7.0.0 destination cluster, since they have different major versions.
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.
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.You cannot sync a collection that has a unique index and a non-unique index defined on the same field(s).
MongoDB Community Edition
Cluster-to-Cluster Sync supports a limited number of operations with MongoDB Community Edition. Please contact a sales representative to discuss your requirements.
Unsupported Collection Types
Time-series collections are not supported.
Clustered collections with expireAfterSeconds set are not supported.
Sharded Clusters
mongosync
does not support sync from a sharded cluster to a replica set.Sync from a replica set to a sharded cluster has the following limitations:
Collections included in the
sharding.shardingEntries
option for thestart
command cannot be renamed to use a different database whilemongosync
is running.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 andmongosync
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 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.
mongosync
only supports syncing sharded collections that have default collation settings.
Reversing
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.
Multiple Clusters
Syncing multiple source clusters to one destination cluster is not supported.
Syncing one source cluster to many destination clusters is not supported.
Filtered Sync
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 is replicated.
You cannot specify system collections or system databases in a filter.
To use the
$out
aggregation stage or themapReduce
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.
Capped Collections
Starting in 1.3.0, Cluster-to-Cluster Sync supports capped collections with some limitations.
The minimum server version is 6.0.
convertToCapped
is not supported. If you runconvertToCapped
,mongosync
exits with an error.cloneCollectionAsCapped
is not supported.
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.
System Collections
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.