@@ -201,7 +201,7 @@ The `Ready` state contains quite a bit of information, and you need to check and
201
201
by one:
202
202
203
203
1. Check whether `messages` is empty or not. If not, it means that the node will send messages to
204
- other nodes:
204
+ other nodes:
205
205
206
206
```rust
207
207
# use slog::{Drain, o};
@@ -226,7 +226,7 @@ other nodes:
226
226
```
227
227
228
228
2. Check whether `snapshot` is empty or not. If not empty, it means that the Raft node has received
229
- a Raft snapshot from the leader and we must apply the snapshot:
229
+ a Raft snapshot from the leader and we must apply the snapshot:
230
230
231
231
```rust
232
232
# use slog::{Drain, o};
@@ -254,8 +254,8 @@ a Raft snapshot from the leader and we must apply the snapshot:
254
254
```
255
255
256
256
3. Check whether `committed_entries` is empty or not. If not, it means that there are some newly
257
- committed log entries which you must apply to the state machine. Of course, after applying, you
258
- need to update the applied index and resume `apply` later:
257
+ committed log entries which you must apply to the state machine. Of course, after applying, you
258
+ need to update the applied index and resume `apply` later:
259
259
260
260
```rust
261
261
# use slog::{Drain, o};
@@ -310,7 +310,7 @@ need to update the applied index and resume `apply` later:
310
310
after restarting, *it may work but potential log loss may also be ignored silently*.
311
311
312
312
4. Check whether `entries` is empty or not. If not empty, it means that there are newly added
313
- entries but have not been committed yet, we must append the entries to the Raft log:
313
+ entries but have not been committed yet, we must append the entries to the Raft log:
314
314
315
315
```rust
316
316
# use slog::{Drain, o};
@@ -335,8 +335,8 @@ entries but have not been committed yet, we must append the entries to the Raft
335
335
```
336
336
337
337
5. Check whether `hs` is empty or not. If not empty, it means that the `HardState` of the node has
338
- changed. For example, the node may vote for a new leader, or the commit index has been increased.
339
- We must persist the changed `HardState`:
338
+ changed. For example, the node may vote for a new leader, or the commit index has been increased.
339
+ We must persist the changed `HardState`:
340
340
341
341
```rust
342
342
# use slog::{Drain, o};
@@ -360,7 +360,7 @@ We must persist the changed `HardState`:
360
360
```
361
361
362
362
6. Check whether `persisted_messages` is empty or not. If not, it means that the node will send messages to
363
- other nodes after persisting hardstate, entries and snapshot:
363
+ other nodes after persisting hardstate, entries and snapshot:
364
364
365
365
```rust
366
366
# use slog::{Drain, o};
@@ -385,8 +385,8 @@ other nodes after persisting hardstate, entries and snapshot:
385
385
```
386
386
387
387
7. Call `advance` to notify that the previous work is completed. Get the return value `LightReady`
388
- and handle its `messages` and `committed_entries` like step 1 and step 3 does. Then call `advance_apply`
389
- to advance the applied index inside.
388
+ and handle its `messages` and `committed_entries` like step 1 and step 3 does. Then call `advance_apply`
389
+ to advance the applied index inside.
390
390
391
391
```rust
392
392
# use slog::{Drain, o};
@@ -470,8 +470,8 @@ This process is a two-phase process, during the midst of it the peer group's lea
470
470
**two independent, possibly overlapping peer sets**.
471
471
472
472
> **Note:** In order to maintain resiliency guarantees (progress while a majority of both peer sets is
473
- active), it is recommended to wait until the entire peer group has exited the transition phase
474
- before taking old, removed peers offline.
473
+ active), it is recommended to wait until the entire peer group has exited the transition phase
474
+ before taking old, removed peers offline.
475
475
476
476
*/
477
477
0 commit comments