raft: let learners vote #10998
raft: let learners vote #10998
Conversation
It turns out that that learners must be allowed to cast votes.
This seems counter- intuitive but is necessary in the situation in which
a learner has been promoted (i.e. is now a voter) but has not learned
about this yet.
For example, consider a group in which id=1 is a learner and id=2 and
id=3 are voters. A configuration change promoting 1 can be committed on
the quorum `{2,3}` without the config change being appended to the
learner's log. If the leader (say 2) fails, there are de facto two
voters remaining. Only 3 can win an election (due to its log containing
all committed entries), but to do so it will need 1 to vote. But 1
considers itself a learner and will continue to do so until 3 has
stepped up as leader, replicates the conf change to 1, and 1 applies it.
Ultimately, by receiving a request to vote, the learner realizes that
the candidate believes it to be a voter, and that it should act
accordingly. The candidate's config may be stale, too; but in that case
it won't win the election, at least in the absence of the bug discussed
in:
etcd-io#7625 (comment).
Codecov Report
@@ Coverage Diff @@
## master #10998 +/- ##
==========================================
+ Coverage 63.75% 63.97% +0.22%
==========================================
Files 401 401
Lines 37551 37554 +3
==========================================
+ Hits 23939 24026 +87
+ Misses 12003 11890 -113
- Partials 1609 1638 +29
Continue to review full report at Codecov.
|
|
Thanks @nvanbenschoten. |
@tbg hello，I'm a little confused about learners being able to vote without elevated privileges and hope to help me out |
It turns out that that learners must be allowed to cast votes.
This seems counter- intuitive but is necessary in the situation in which
a learner has been promoted (i.e. is now a voter) but has not learned
about this yet.
For example, consider a group in which id=1 is a learner and id=2 and
id=3 are voters. A configuration change promoting 1 can be committed on
the quorum
{2,3}without the config change being appended to thelearner's log. If the leader (say 2) fails, there are de facto two
voters remaining. Only 3 can win an election (due to its log containing
all committed entries), but to do so it will need 1 to vote. But 1
considers itself a learner and will continue to do so until 3 has
stepped up as leader, replicates the conf change to 1, and 1 applies it.
Ultimately, by receiving a request to vote, the learner realizes that
the candidate believes it to be a voter, and that it should act
accordingly. The candidate's config may be stale, too; but in that case
it won't win the election, at least in the absence of the bug discussed
in:
#7625 (comment).
PS I have a work-in-progress PR that makes these sorts of interactions
much more testable and I'm planning to add additional test coverage
when it lands.
PS2: note that a similar behavior already holds for considering entries committed.
This decision is made by the leader based on its view of the configuration. If a node
that considers itself a learner acks a log entry, and it is in fact a voter in the leader's
view, then that ack will count for the commit quorum for that index (and always has).
This is necessary, and so is this change.