MongoDB replica sets synchronize only partial collections or databases?

Does the MongoDB replica set support features similar to MySQL replicate-do-db, specifying database or collection synchronization?

Hello @111198, welcome to the MongoDB Community forum!

MongoDB replication is at the level of the server (includes all databases and the collections). There is no option to replicate only selected databases and collections.

For more details please refer Replication:

A replica set in MongoDB is a group of mongod processes that maintain the same data set. Replica sets provide redundancy and high availability, and are the basis for all production deployments). …

1 Like

Hi @Prasad_Saya , so it’s not possible to configure a database like local that only exists on one server?

Further, if excluding a database from replication is not possible, can collections be created in local so that they are not replicated?



The local Database documentation says:

Every mongod instance has its own local database, which stores data used in the replication process, and other instance-specific data. The local database is invisible to replication: collections in the local database are not replicated.

Since, local database holds very important information that should not be messed with, it is not recommended to create your own data (i.e., collections) in this database.


Welcome to the MongoDB Community Forums @Cast_Away!

The local database is only intended for use by MongoDB internal code such as the replication system so I would definitely advise against using this for other purposes. I recall some past discussions where usage of local led to unexpected performance or access issues because there are some design assumptions that local will primarily be used by the replication process and some infrequently updated instance-specific metadata. There are some local database restrictions noted on the page that @Prasad_Saya linked, such as no support for transactions or retryable writes.

If you have data that does not need to be replicated, the safer path would be to use a separate standalone instance. I assume you are trying to avoid some overhead for ephemeral data, but a more straightforward deployment option would be save this data in your replica set and use a Time-To-Live (TTL) index to automatically remove old documents after a set expiry time or per-document expiry.



This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.