[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: 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. |