Mirroristas/etcd
2
0
Fork 0
mirror of https://github.com/etcd-io/etcd.git synced 2024-09-27 06:25:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #10848 from spzala/raftthesis10831

Browse Source 
raftdoc: fix raft thesis link
This commit is contained in:
Xiang Li
2019-06-28 12:43:32 -07:00
committed by GitHub
parent ecba4492f2 655ab0ac6a
commit d506962fec
3 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/server-learner.rst
View File

@@ -78,7 +78,7 @@ As seen above, a simple misconfiguration can fail the whole cluster into an inop
Raft Learner
============
In order to mitigate such availability gaps in the previous section, `Raft §4.2.1 <https://ramcloud.stanford.edu/~ongaro/thesis.pdf>`_ introduces a new node state “Learner”, which joins the cluster as a **non-voting member** until it catches up to leader’s logs.
In order to mitigate such availability gaps in the previous section, `Raft §4.2.1 <https://github.com/ongardie/dissertation/blob/master/stanford.pdf>`_ introduces a new node state “Learner”, which joins the cluster as a **non-voting member** until it catches up to leader’s logs.
Features in v3.4
----------------

2
raft/README.md
View File

@@ -190,7 +190,7 @@ may be reused. Node IDs must be non-zero.
## Implementation notes
This implementation is up to date with the final Raft thesis (https://ramcloud.stanford.edu/~ongaro/thesis.pdf), although this implementation of the membership change protocol differs somewhat from that described in chapter 4. The key invariant that membership changes happen one node at a time is preserved, but in our implementation the membership change takes effect when its entry is applied, not when it is added to the log (so the entry is committed under the old membership instead of the new). This is equivalent in terms of safety, since the old and new configurations are guaranteed to overlap.
This implementation is up to date with the final Raft thesis (https://github.com/ongardie/dissertation/blob/master/stanford.pdf), although this implementation of the membership change protocol differs somewhat from that described in chapter 4. The key invariant that membership changes happen one node at a time is preserved, but in our implementation the membership change takes effect when its entry is applied, not when it is added to the log (so the entry is committed under the old membership instead of the new). This is equivalent in terms of safety, since the old and new configurations are guaranteed to overlap.
To ensure there is no attempt to commit two membership changes at once by matching log positions (which would be unsafe since they should have different quorum requirements), any proposed membership change is simply disallowed while any uncommitted change appears in the leader's log.

2
raft/doc.go
View File

@@ -172,7 +172,7 @@ may be reused. Node IDs must be non-zero.
Implementation notes
This implementation is up to date with the final Raft thesis
(https://ramcloud.stanford.edu/~ongaro/thesis.pdf), although our
(https://github.com/ongardie/dissertation/blob/master/stanford.pdf), although our
implementation of the membership change protocol differs somewhat from
that described in chapter 4. The key invariant that membership changes
happen one node at a time is preserved, but in our implementation the