[SERVER-15740] a node newly added to a replset sometimes goes into REMOVED state first Created: 20/Oct/14  Updated: 22/Nov/19  Resolved: 27/Oct/14

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 2.8.0-rc0

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-44807 Allow transition from RS_STARTUP to R... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

We suspect that checkQuorumForConfigChange on the reconfig'ing node is communicating the old config to the newly added node. Specifically, the node running the reconfig command issues a heartbeat to every member of the new config. This causes the newly added node to issue a heartbeat back to the reconfig'ing node before that node has finished processing the reconfig. The response to the new node contains the old config, which does not contain the new node, so it goes into REMOVED. It then receives a heartbeat from the reconfig'ing node when the reconfig is complete, and this time the new node gets the new configuration and joins the set.



 Comments   
Comment by Githook User [ 27/Oct/14 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-15740 Do not transition from RS_STARTUP to RS_REMOVED directly.

If a node is in RS_STARTUP (because it has no replica set configuration) and it learns of a
configuration that does not contain it, the correct behavior is to ignore the new configuration and
stay in RS_STARTUP, not to save the new configuration and enter RS_REMOVED.
Branch: master
https://github.com/mongodb/mongo/commit/eb4df26203fb5f242d36751a67c318313d36e121

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