I’m using MongoDB’s cluster-to-cluster sync (mongosync) with filtered sync to replicate data between two clusters.
Cluster A has Database A
Cluster B has Database B
mongosync A syncs Database A from Cluster A → Cluster B
mongosync B syncs Database B from Cluster B → Cluster A
This setup works fine in general. However, I recently attempted to resync Database A to Cluster B by dropping Database A in Cluster B and restarting mongosync A. Unexpectedly, this led to a view in Database A being dropped from the source Cluster A.
It seems like DDL operations (particularly view deletions) might not be properly filtered or isolated in the sync process—possibly due to prior syncs (mongosync B) that brought those views from Cluster B into Cluster A.
This behavior is quite concerning. Has anyone experienced something similar with mongosync and filtered syncs? Is there a best practice to avoid view drops in such bi-directional filtered sync setups?
Any guidance or confirmation would be appreciated.
mongosync is not intended for bidirectional synchronisation.
Cluster-to-Cluster Sync provides continuous data synchronization or a one-time data migration between MongoDB clusters. For notes and caveats on continuous sync, see the Considerations for Continuous Sync page. You can enable Cluster-to-Cluster Sync with the mongosync utility.
The second item in the general limitations list specifies “The destination cluster must be empty”
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.
If all the Considerations and Limitations are assessed and followed there will be little chance of issues.