What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

We need to continuously replicate data between separate MongoDB clusters, not just within a replica set. Typical needs are:

• Copying selected databases or collections from production to reporting, analytics or test clusters

• Consolidating data from multiple clusters (e.g. regional or application-specific clusters) into one central cluster for reporting or data integration

• Keeping a filtered, continuously updated copy of data in another cluster without replicating everything

Replica set replication always copies all data inside one cluster and cannot target another cluster. Cluster-to-Cluster Sync (mongosync) is designed mainly for migration: as far as we know it supports only one source to one destination, restricts writes on the destination, and is not built as a long-running, multi-source replication solution. As a result we have to build and maintain custom pipelines (change streams, Kafka, scripts) to move data between clusters.

What would you like to see happen?

Describe the desired outcome or enhancement.

A native, supported inter-cluster replication feature that:

• Replicates continuously from a source cluster to a target cluster

• Supports scope selection at cluster level, database level and collection level, with include/exclude filters

• Supports many-to-one topologies: multiple source clusters replicating into a single target cluster, with optional namespace mapping/renaming on the target (e.g. sourceA.db1 → target.sourceA_db1) to avoid name conflicts

• Allows the target cluster to stay writable for its own (non-replicated) databases and collections

• Replicates indexes and collection options together with the data

• Handles initial sync plus ongoing changes, with resumability after network interruptions or restarts

• Exposes lag, status and errors in monitoring, and is configurable via Ops Manager / Atlas and the API

• Works with replica sets and sharded clusters, with TLS and authentication between clusters

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

Many organisations run several MongoDB clusters for different applications, regions or environments, and need parts of that data combined or copied elsewhere. Without a native feature, every team builds its own change-stream or Kafka-based pipeline, which is costly to develop, hard to monitor and operate, and easy to get wrong (missed events, resume token handling, schema/index drift). A built-in, supported solution would reduce operational risk and engineering effort, simplify architectures for reporting, analytics and data consolidation, and give consistent monitoring and support. Other database platforms offer logical replication with table-level selection and multi-source setups, so this is a common expectation.

What steps, if any, are you taking today to manage this problem?

• Custom change stream applications: We write and maintain our own code to read change streams from source clusters and apply them to the target, including resume token handling, error handling and monitoring.

• Kafka Connector pipelines: For some flows we use the MongoDB Kafka source and sink connectors, which adds Kafka infrastructure and operational overhead just to move data between MongoDB clusters.

• mongodump / mongorestore jobs: For less time-sensitive cases we run scheduled dump/restore jobs, which are not continuous, require full copies and cause stale data on the target.

• mongosync: Useful for one-time migrations, but it does not cover filtered, long-running or many-to-one replication.

All of these require significant custom work and do not provide a unified, supported way to replicate between clusters.