Notes Background Already existing scheme used db query for replication Replication scheme was in such a way that any follower could query any other follower Due to this when they tried to implement RAFT there was a mismatch between the architecture and algorithm. So they decided to change the algorithm to implement in existing architecture.
Problem Querying will not give you the term number meaning you don’t know if you’re pulling from the leader or not and if the log entries are correct or not. Any other follower can pull from this stale follower. Solution Use updateposition RPC to get the term. Implementation Reading can be done by batching read requests with other requests. After lecture Look up TiDB What is mmap? Why fsync twice? TLA+ verification FLP Theorem (https://ilyasergey.net/CS6213/week-03-bft.html)
Notes Runs in 2 phases -
Phase 1 - get a promise from majority of servers Phase 2 - get a majority of servers to commit Two important rules Two numbers should be used to track the system Highest seen Highest accepted Majority will only happen if the values getting selected are happening at the same number It can’t be that one value got accepted at 1,v1 and another got accepted at 3,v1. It won’t be a majority. RAFT’s up-to date term and index matching can be mapped to the two numbers rule in paxos. RAFT’s figure 2 last rule where current term is stored while appending(so a majority cannot be reached as term and index both must be matched) can be matched to the majority rule where values are selected that happened at the same number.
...
RAFT Notes What kind of system is RAFT? Exactly once/At least once/ At most once? Two ways to approach this:
Application layer is responsible for de-duplication and the command is just appended (albeit with the same ID). Consensus layer(RAFT) is responsible for checking duplicates. Let the client handle ID generation instead of servers.
PAXOS Notes Majority concept is for making sure that two different groups of systems cannot reach different consensus as two majorities will always overlap.
...