mirror of
https://github.com/etcd-io/etcd.git
synced 2024-09-27 06:25:44 +00:00
169f4c3cc7
See https://github.com/etcd-io/etcd/issues/14370. When run in a single-voter configuration, prior to this PR raft would emit `HardState`s that would emit a proposed `Entry` simultaneously in `CommittedEntries` and `Entries`. To be correct, this requires users of the raft library to enforce an ordering between appending to the log and notifying the client about `CommittedEntries` also present in `Entries`. This was easy to miss. Walk back this behavior to arrive at a simpler contract: what's emitted in `CommittedEntries` is truly committed, i.e. present in stable storage on a quorum of voters. This in turn pessimizes the single-voter case: rather than fully handling an `Entry` in just one `Ready`, now two are required, and in particular one has to do extra work to save on allocations. We accept this as a good tradeoff, since raft primarily serves multi-voter configurations. Signed-off-by: Tobias Grieger <tobias.b.grieger@gmail.com>
31 lines
666 B
Plaintext
31 lines
666 B
Plaintext
log-level info
|
|
----
|
|
ok
|
|
|
|
add-nodes 1 voters=(1) index=3
|
|
----
|
|
INFO 1 switched to configuration voters=(1)
|
|
INFO 1 became follower at term 0
|
|
INFO newRaft 1 [peers: [1], term: 0, commit: 3, applied: 3, lastindex: 3, lastterm: 1]
|
|
|
|
campaign 1
|
|
----
|
|
INFO 1 is starting a new election at term 0
|
|
INFO 1 became candidate at term 1
|
|
INFO 1 received MsgVoteResp from 1 at term 1
|
|
INFO 1 became leader at term 1
|
|
|
|
stabilize
|
|
----
|
|
> 1 handling Ready
|
|
Ready MustSync=true:
|
|
Lead:1 State:StateLeader
|
|
HardState Term:1 Vote:1 Commit:3
|
|
Entries:
|
|
1/4 EntryNormal ""
|
|
> 1 handling Ready
|
|
Ready MustSync=false:
|
|
HardState Term:1 Vote:1 Commit:4
|
|
CommittedEntries:
|
|
1/4 EntryNormal ""
|