[SERVER-20745] replSetElect response does not always contain 'vote' field Created: 02/Oct/15  Updated: 06/Dec/22  Resolved: 03/Jan/20

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

Type: Bug Priority: Trivial - P5
Reporter: Kamran K. Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 560d56e2be07c4135fa877db.txt    
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

It looks like it's possible for the replSetElect command response to not contain a 'vote' field:

I REPL     [ReplicationExecutor] received EOO votes from ip-10-140-165-110:20018
E REPL     [ReplicationExecutor] wrong type for vote argument in replSetElect command: EOO

More context:

[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.130+0000 c20017| 2015-10-01T15:53:17.127+0000 I REPL     [ReplicationExecutor] This node is ip-10-140-165-110:20017 in the config
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.130+0000 c20017| 2015-10-01T15:53:17.127+0000 I REPL     [ReplicationExecutor] transition to STARTUP2
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.130+0000 c20018| 2015-10-01T15:53:17.128+0000 I NETWORK  [initandlisten] connection accepted from 10.140.165.110:33629 #6 (4 connections now open)
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.130+0000 c20018| 2015-10-01T15:53:17.128+0000 I COMMAND  [conn3] received elect msg { replSetElect: 1, set: "test-configRS", who: "ip-10-140-165-110:20016", whoid: 0, cfgver: 1, round: ObjectId('560d56ed99649624616c262a') }
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.131+0000 c20017| 2015-10-01T15:53:17.127+0000 I REPL     [ReplicationExecutor] Member ip-10-140-165-110:20016 is now in state SECONDARY
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.131+0000 c20017| 2015-10-01T15:53:17.128+0000 I COMMAND  [conn3] received elect msg { replSetElect: 1, set: "test-configRS", who: "ip-10-140-165-110:20016", whoid: 0, cfgver: 1, round: ObjectId('560d56ed99649624616c262a') }
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.131+0000 c20017| 2015-10-01T15:53:17.128+0000 I REPL     [ReplicationExecutor] replSetElect voting yea for ip-10-140-165-110:20016 (0)
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.132+0000 c20017| 2015-10-01T15:53:17.128+0000 I NETWORK  [conn3] end connection 10.140.165.110:57139 (1 connection now open)
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.132+0000 c20017| 2015-10-01T15:53:17.129+0000 I REPL     [ReplicationExecutor] Member ip-10-140-165-110:20018 is now in state STARTUP
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.132+0000 c20017| 2015-10-01T15:53:17.130+0000 I NETWORK  [initandlisten] connection accepted from 10.140.165.110:57156 #5 (2 connections now open)
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.132+0000 c20016| 2015-10-01T15:53:17.127+0000 I REPL     [ReplicationExecutor] Standing for election
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.133+0000 c20016| 2015-10-01T15:53:17.128+0000 I REPL     [ReplicationExecutor] running for election
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.133+0000 c20016| 2015-10-01T15:53:17.128+0000 I REPL     [ReplicationExecutor] received EOO votes from ip-10-140-165-110:20018
[js_test:fsm_all_sharded_replication] 2015-10-01T15:53:17.133+0000 c20016| 2015-10-01T15:53:17.128+0000 E REPL     [ReplicationExecutor] wrong type for vote argument in replSetElect command: EOO

This was spotted in the fsm_all_sharded_replication.js log from https://evergreen.mongodb.com/task/mongodb_mongo_master_linux_64_debug_concurrency_sharded_WT_97128797aa2d5169ca2e7f1cc6795955857803d7_15_09_30_21_57_26.



 Comments   
Comment by Siyuan Zhou [ 03/Jan/20 ]

Closing this ticket. PV0 has been removed in 4.0.

Comment by Eric Milkie [ 02/Oct/15 ]

This will go away once we remove support for protocolVersion 0.

Comment by Eric Milkie [ 02/Oct/15 ]

This is actually a cosmetic issue; if a node receives a vote command before it's finished starting up, it may return a response with an error. The election logic on the other side treats any bad response as 0 votes, although it would be nice if it logged the error status to its log for diagnostic purposes.

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