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.

In a replica set, every database on the primary is replicated to all secondaries; there is no way to exclude a database. Some of our databases do not need high availability or copies on every node — for example temporary/staging databases, scratch data used for processing, or large data that can easily be rebuilt. These databases still generate oplog entries and consume disk, I/O and network bandwidth on every secondary, increase replication lag risk, and fill the oplog window faster, which reduces our recovery margin for the databases that actually matter. Today our only option is to run a separate mongod/replica set for this data, which adds operational overhead, extra servers and more monitoring and backup configuration.

What would you like to see happen?

Describe the desired outcome or enhancement.

A replica set–level configuration option to include or exclude specific databases (and ideally collections) from replication, for example a namespace exclude list in the replica set config. Excluded namespaces would remain local to the node where they are written: no oplog entries for them, no copying to secondaries during initial sync. Ideally:

• Configurable per replica set (and per shard in sharded clusters)

• Manageable via rs.reconfig() and Ops Manager / automation

• Clear behaviour on failover (e.g. excluded databases are not available on the new primary, documented explicitly)

• Visible in monitoring so it is clear which namespaces are not protected

Why is this important to you or your team?

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

Disk, network and I/O resources on secondaries are spent on data that does not need to be replicated, and oplog capacity is consumed by low-value writes, reducing the oplog window for critical data. Running separate replica sets just to isolate non-replicated databases increases infrastructure cost and operational complexity: more servers, more monitoring, more backup configuration. A built-in option would let us use resources more efficiently and keep a simpler topology. (Other database systems offer replication filtering, e.g. MySQL’s replicate-ignore-db, so this is a common expectation when migrating to MongoDB.)

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

Currently we have no clean solution and use the following workarounds:

• Accepting full replication: In most cases we simply let all databases replicate, accepting the extra disk, I/O, network and oplog usage on every secondary, even for data that does not need high availability.

• Separate mongod instances / replica sets: For some non-critical data we run a separate standalone mongod or a separate replica set. This means more servers to provision, patch, monitor and back up, and applications have to manage multiple connection strings.

• Increasing oplog size and secondary capacity: We size the oplog and secondary hardware larger than needed for our critical data alone, to absorb writes from databases that do not actually need replication.

All of these either waste resources or add operational complexity, which is why a built-in option to exclude databases from replication would help.