[SERVER-26851] Use lastOpTimeFetched rather than lastOpTimeApplied for election purposes Created: 31/Oct/16  Updated: 06/Dec/22

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

Type: Improvement Priority: Major - P3
Reporter: Mathias Stearn Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: pm722
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-28680 Fix naming of lastCommittedOp field i... Closed
Assigned Teams:
Replication
Participants:

 Description   

We should look into using lastOpTimeFetched rather than lastOpTimeApplied for election purposes. In particular, candidates for election would use it for the "lastLogIndex" field of the RAFT RequestVote RPC and voters would refuse to vote for anyone who is behind their lastOpTimeFetched. I think this will avoid the odd case where a majority of nodes can accept an op and apply it, but it will still be rolled back. I think this also is closer to my reading of RAFT's log[] state given the way that we split the AppendEntries RPC with the "request" being the reply from a getMore and the "reply" being the upatePosition command request.


Generated at Thu Feb 08 04:13:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.