[SERVER-13458] Identify replica state in ismaster for uninitialized and shunned states Created: 02/Apr/14 Updated: 03/Jan/23 Resolved: 13/Jun/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Jeffrey Yemin | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
A server started with --replSet <name> return this ambiguous ismaster response in both the uninitialized and shunned state; shunned is when the node was removed from the replica set configuration:
Note: isreplicaset exists in only these states and there is no hosts field, nor setName nor setVersion to work with. It would be very helpful for clients and drivers to be able to uniquely identify each state with as much context as possible so that replica set discovery/monitoring behavior can be well defined. |
| Comments |
| Comment by Githook User [ 03/Jan/23 ] |
|
Author: {'name': 'Alex Bevilacqua', 'email': 'alex@alexbevi.com', 'username': 'alexbevi'}Message: Update SDAM Spec to remove "RSGhosts may report their setNames in the future" (#1331) Update server-discovery-and-monitoring.rst > RSGhosts may report their setNames in the future (see Remove the above reference as |
| Comment by Eric Milkie [ 13/Jun/14 ] |
|
After discussion, we believe the current ismaster fields are sufficient for our needs. |
| Comment by Eric Milkie [ 13/Jun/14 ] |
|
How would you use the new information? In other words, what client behavior would change when you discover an uninitialized node versus one that had been part of a valid config in the past but is currently not? |