[SERVER-42986] Include hidden nodes in "hiddens" field of isMaster response Created: 22/Aug/19  Updated: 30/Oct/19  Resolved: 30/Oct/19

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: David Bartley Assignee: Benjamin Caimano (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Service Arch 2019-11-04
Participants:

 Description   

isMaster now includes "active" nodes, in "hosts", arbiters in "arbiters", and passive nodes (priority 0 but non-hidden). It'd be helpful to also include hidden nodes. The use case we have in mind is for automated rolling index builds; our replset configuration consists of 5 active data nodes, and 1 backup node running on EBS (that we take EBS snapshots for). The backup node is hidden, so we have to call replSetGetConfig to discover this node. It'd be nice if isMaster just included that, since we could presumably just query the driver (which obviously calls isMaster regularly).



 Comments   
Comment by Benjamin Caimano (Inactive) [ 30/Oct/19 ]

bartle, I'm afraid this isn't something we should be changing. I'm worried about disrupting clients who host replica sets for their own external clients. They could be maintaining hidden nodes that they have access to but providing limited access to the replica set at large.

For your specific case, I wonder if it would be useful to have your backup node be "passive" instead of hidden in combination with cluster-wide replica set tags. This would allow you to direct reads at will while avoiding the backup node during normal operation.

Comment by David Bartley [ 29/Oct/19 ]

For rolling operations, to discover all nodes we'll do something like:
1) Use a standard mongo client + fixed connection string to connect to the replset as a whole
2) Run replSetGetConfig to discover all nodes, including hidden ones

Mongo drivers typically provide a mechanism to see all servers in a deployment, so it'd be a bit more convenient to always use that, rather than use replSetGetConfig.

Comment by Benjamin Caimano (Inactive) [ 29/Oct/19 ]

bartle, the general motivation for an isMaster request is topology discovery for read and write dispatch (i.e. which servers are available and what role do they have in the system). To that end, we intentionally exclude hidden nodes from the isMaster response---it should not receive reads as a typical secondary, thus we do not list it. We tend to be conservative about how we change the isMaster command in general, since it underpins so much in our distributed logic. You might already know all of this, just restating so that we're on the same page.

I'd like more specifics on your use case. You seem to not know the identity of the backup node from the client side, which implies to me that you dynamically provide your client with a single connection string. When should a client that is talking to your active members start talking to your hidden member?

Comment by Danny Hatcher (Inactive) [ 23/Aug/19 ]

Thanks for the feature request. I'll forward it along to the appropriate team.

Generated at Thu Feb 08 05:01:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.