[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: |
|
||||||||
| 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. |