Notes: https://pdos.csail.mit.edu/6.824/notes/l-raft.txt
Video: https://youtu.be/h3JiQ_lnkE8
Prep:
-
Raft Paper (from section 5): https://pdos.csail.mit.edu/6.824/papers/raft-extended.pdf
- Log Divergence (resumed)
- Log Catchup
- Erasing Log Entries
- Catch Up quickly
- Persistence
- Service Recovery
- Using Raft
- Linearizability
Log Divergence (resumed)
rules
- any leader needs to achieve majority from a node which participated in previous elections
- followers only vote positively when they’re at least as updated as leader
Log Catchup
https://excalidraw.com/#json=nvZm5sB8LpLhg9mNZ1ZwT,TogbNdeWHBa5Et2WhTqibg
in unoptimized version
nextIndexwhich is optimistic, thinks that followers are up to date, so starts at index where leader’s curr index- when it recieves info that it’s wrong, it’ll decrement
matchIndexwhich is pessimistic, thinks that followers are not up to date (don’t even have any entries), so starts at 0- when it receives info that follower’s fine, then it’ll get updated to that curr index
Erasing Log Entries
followers can only commit after leader has commited atleast once in it’s own term
Catch Up quickly
In optimized version, instead of sending multiple not up to date and leader decrementing indices
follower will send at what index conflict is happening. Now server sends entries from there
Persistence
strategies
- rejoins ⇒ replay log
- start from persistent state
- voted for, log on disk[], curr term
Service Recovery
- replay log ⇒ recreate state
- snapshot
- contains all ops until some idx i, log will get truncated/cut from that snapshot part
Using Raft
https://excalidraw.com/#json=dV42j4bd8ElJLwCHmKNsW,vmBS9ae4VN2VSpGW5OAHXg
A clerk interacts with service like a middleman, clients communicate through clerk
clerk maintains IDs for operations and cluster membership details
clerk is part of client
Linearizability
-
total order of execution
-
match real time
-
read returns results of last write
difference from serializability is it doesn’t match real time (transactinos?)