[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:
Related
is related to JAVA-1161 A replica set member that doesn't rep... Closed
is related to SERVER-29680 Update perf.yml microbenchmarks repls... Closed
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:

{ "serverUsed" : "localhost:27017" ,
  "ismaster" : false ,
  "secondary" : false ,
  "info" : "can't get local.system.replset config from self or any seed (EMPTYCONFIG)" ,
  "isreplicaset" : true ,
  "maxBsonObjectSize" : 16777216 ,
  "maxMessageSizeBytes" : 48000000 ,
  "localTime" : { "$date" : "2014-04-01T14:10:05.110Z"} ,
  "ok" : 1.0 }

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 SERVER-13458).

Remove the above reference as SERVER-13458 was closed in 2014 as Works as Designed
Branch: master
https://github.com/mongodb/specifications/commit/013d36bd583605628aa9e4bc891f4a87841f7029

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?

Generated at Thu Feb 08 03:31:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.