MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Add new feedback Subscribe
Status Submitted
Categories Atlas
Created by Guest
Created on Oct 8, 2020

RELATED FEEDBACK

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.
  • Guest
    Nov 14, 2022
    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
    Reply
  • Guest
    Dec 4, 2020
    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
    Reply
  • Guest
    Nov 25, 2020
    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.
    Reply