diff --git a/docs/server-learner.rst b/docs/server-learner.rst index 00ef63dae..a814172c7 100644 --- a/docs/server-learner.rst +++ b/docs/server-learner.rst @@ -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 `_ 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 `_ 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 ---------------- diff --git a/raft/README.md b/raft/README.md index 6745c7fdf..83cf04035 100644 --- a/raft/README.md +++ b/raft/README.md @@ -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. diff --git a/raft/doc.go b/raft/doc.go index 301b0713b..68fe6f0a6 100644 --- a/raft/doc.go +++ b/raft/doc.go @@ -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