From 4db7922f432ab95b2a85c0e928ad9e311f8cb71c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=B0=AD=E5=B7=8D?= <931418134@qq.com> Date: Tue, 4 Jan 2022 18:34:26 +0800 Subject: [PATCH] fix some guide doc typo --- change-log.md | 2 ++ guide/src/cluster-controls.md | 2 +- guide/src/delete_log.md | 16 ++++++++-------- guide/src/dynamic-membership.md | 4 ++-- guide/src/threading.md | 8 ++++---- 5 files changed, 17 insertions(+), 15 deletions(-) diff --git a/change-log.md b/change-log.md index 1111c3289..96d2da0ac 100644 --- a/change-log.md +++ b/change-log.md @@ -553,6 +553,8 @@ ### Fixed: +- Fixed: [178d520](https://github.com/veeupup/openraft/commit/178d520e3db47b361582fe4aedd96f04a5dae160) typo; by Veeupup; 2022-01-04 + - Fixed: [fc8e92a8](https://github.com/datafuselabs/openraft/commit/fc8e92a8207c1cf8bd1dba2e8de5c0c5eebedc1c) typo; by drdr xp; 2021-07-12 - Fixed: [447dc11c](https://github.com/datafuselabs/openraft/commit/447dc11cab51fb3b1925177d13e4dd89f998837b) when finalize_snapshot_installation, memstore should not load membership from its old log that are going to be overridden by snapshot.; by drdr xp; 2021-07-13 diff --git a/guide/src/cluster-controls.md b/guide/src/cluster-controls.md index 1795c1d07..6e71050fd 100644 --- a/guide/src/cluster-controls.md +++ b/guide/src/cluster-controls.md @@ -1,6 +1,6 @@ # Cluster Controls -A raft cluster may be control in various ways using the API methods of the `Raft` type. +A raft cluster may be controlled in various ways using the API methods of the `Raft` type. This allows the application to influence the raft behavior. There are several concepts related to cluster control: diff --git a/guide/src/delete_log.md b/guide/src/delete_log.md index 9a2977dcb..4aaaa4602 100644 --- a/guide/src/delete_log.md +++ b/guide/src/delete_log.md @@ -1,4 +1,4 @@ -When appending logs or install snapshot(another form of appending logs), +When appending logs or installing snapshot(another form of appending logs), Conflicting logs **should** be removed. To maintain log consistency, it does not need to delete. @@ -11,17 +11,17 @@ if the logs from the new leader are committed. But membership changing requires it to remove the incompatible logs when appending. This is what raft did wrongly. -If membership log are ketp in a separate log column, there wont be such problem. -But membership a mixed into business log. +If membership logs are kept in a separate log column, there wont be such a problem. +But membership a mixed into the business log. which makes it a non-WAL storage. The following is an exmaple of why logs must be removed: -A membership change log will only appended if the previous membership log is committed, +A membership change log will only be appended if the previous membership log is committed, which is the algo raft defined. -A non committed membership log is only allowed to present if any quorum in it intersection with a quorum in the committed config. +A non-committed membership log is only allowed to present if any quorum is in its intersection with a quorum in the committed config. -But when new logs are appended, there could be some membership log that is not compatible with a membership log in the incompatible logs. -which results in a brain break. +But when new logs are appended, there could be a membership log that is not compatible with a membership log in the incompatible logs. +which results in a split-brain. E.g.: @@ -39,7 +39,7 @@ m'2 = {R3,X,Y} // final m3 = {R1,U,V} x {R1,R2,R3} m3 is compatible with the committed membership log when it is created. -But not compatible with other's +But not compatible with others' ``` R1 L1 e1,e2,m3 m'1,m'2,m3 diff --git a/guide/src/dynamic-membership.md b/guide/src/dynamic-membership.md index 2e70765fd..ecbabd1ce 100644 --- a/guide/src/dynamic-membership.md +++ b/guide/src/dynamic-membership.md @@ -37,7 +37,7 @@ and immediately begin syncing logs from the leader. This method will initiate a membership change. -If there are nodes in the given config is not a learner, this method will add it +If there are nodes in the given config that is not a learner, this method will add it as Learner first. Thus it is recommended that application always call `Raft::add_learner` first. Otherwise `change_membership` may block for long before committing the @@ -45,7 +45,7 @@ given membership and return. The new membership config specified by this method will take effect at once. -Once the new config is committed, a Voter that is no in the new config will +Once the new config is committed, a Voter that is not in the new config will revert to a Learner and is ready to remove. Correctness constrains: diff --git a/guide/src/threading.md b/guide/src/threading.md index 48340135b..00bd4945e 100644 --- a/guide/src/threading.md +++ b/guide/src/threading.md @@ -2,7 +2,7 @@ There are several threads, AKA tokio-tasks in this raft impl: -- RaftCore: all log and state machine operation is done in this thread. +- RaftCore: all logs and state machine operations are done in this thread. Thus there is no race condition - All raft state runs in this task, such as LeaderState, CandidateState etc. @@ -82,13 +82,13 @@ User - Replication to RaftCore: - - Replication task send the already replicated log id + - Replication task sends the already replicated log id to RaftCore through another per-replication channel. - - Replication task send a `NeedSnapshot` request through the same channel to + - Replication task sends a `NeedSnapshot` request through the same channel to ask RaftCore to build a snapshot if there is no log a follower/learner needs. - Build-snapshot to RaftCore: RaftCore spawn a separate task to build a snapshot - asynchronously. When finished, the spawned task send to RaftCore a message + asynchronously. When finished, the spawned task sends to RaftCore a message including the snapshot info.