Option to configure an on-prem hidden replica set member for an Atlas replica set
As described in https://docs.mongodb.com/manual/tutorial/configure-a-hidden-replica-set-member/, on-prem mongodb deployments allow to configure a hidden replica set members which are good for workloads with different usage patterns from the other members in the replica set. It would be useful to have similar functionality for Atlas replica sets.
In fact, to elaborate, being able to configure an on-prem hidden replica set member for an Atlas replicaset will help in meeting regulatory requirements where organisations are required to host a near real time mirror of data on on-premises.
Mert
shared this idea
-
Slava Fomin
commented
I think this is a must-have feature. We would also like to have a realtime copy of the data from Atlas cloud in our on-premise database server, but currently it's not possible at all.
This should be probably merged with this:
https://feedback.mongodb.com/forums/924145-atlas/suggestions/43163433-support-external-nodes -
Hi Mert, Luke,
I'm sorry I missed this when it was first opened:
It's important to know that Atlas offers configurable workload isolation using *tags*: you can learn more here https://docs.atlas.mongodb.com/reference/replica-set-tags/index.html#node-types
For example you can create Analytics nodes which in turn allow you to isolate analytics (or any other kind of) workloads from operational workloads: you specify the tag in the connection string.
We don't use "hidden" replicas from an implementation perspective since those actually don't work in a sharded setting, and tagging achieves similar objectives.
-Andrew
-
Luke
commented
In the past we have used Hidden Members for the purpose of having a server which is not used by the transactional application, but used for other purposes like reporting.
This allows you to hammer the hidden reporting member of the cluster with large, even debilitating queries, performing massive and repeated table-scans and sorts which otherwise might negatively impact the transactional DB.
