5 ms·
How does Raft handle the scenario where there’s a network split, Client One updates a value on the majority, and then Client Two attempts to read the value from
by jmpman 6y ago
How does Raft handle the scenario where there’s a network split, Client One updates a value on the majority, and then Client Two attempts to read the value from the minority side?
- mfcl 6y agoThen client two can't read the new value until a least one node of the minority side can connect to the majority. Also client two can't update anything.
- ryanworl 6y agoI'll assume by "majority/minority" you mean a network partition where at least half plus one nodes are still able to elect a leader, while the remainder are not. In vanilla Raft, reads are appended to the Raft log like writes are. This means in order to commit a write, the client and the leader on the "majority" side will update the value as normal. The second client will either be unable to find a leader to contact at all, or if it is connected to an old leader, the leader will not be able to replicate the log entry necessary to service the read from the second client. There are lease optimizations that rely on bounded clock error that allow for performing reads from the leader without appending entries to the log. Note this relies on the rate at which the clock advances, not the actual time. There are also optimizations from Paxos research that would allow reading from the followers, but those also require contacting the leader at minimum. In summary, Client One will succeed and Client Two will fail.