What will happen if network partition happen after leader get consensus from follower and commit in its store but when it tries to send confirmation to follower to commit?
For simplicity let's just assume the leader is unable to communicate with any other node because of the network partition. Then the election timeout happens in any of the followers because the leader can't send heartbeat messages anymore. The constraints in election guarantee that if a new leader is elected, it must be one of the nodes which have the committed entries of the old leader from the last term. Those entries are not yet committed in the new leader yet because the rpc message sent by the old leader with the updated commit index was lost because of the network partition. There is another constraint in raft by which a leader can't commit entries from the older terms until it commits an entry in the current term. Once it commits an entry in the current term, it implies previous entries can also be safely committed because of the log matching property. Hope this helps.
![[ 🔴LIVE ] Minecraft : Day5 บ้านหรู หนูอยู่สบายย](http://i.ytimg.com/vi/q3e6qfwDwFs/mqdefault.jpg)
Having the Questions is really good for a better understanding of the concept.
Excellent presentation, the explanation of Raft was clear and not hard to follow. Also good questions!
26:59 was that Martin Kleppmann speaking?
Judging from his voice, yes.
What will happen if network partition happen after leader get consensus from follower and commit in its store but when it tries to send confirmation to follower to commit?
i have the same question! if you find out, please let me know
For simplicity let's just assume the leader is unable to communicate with any other node because of the network partition. Then the election timeout happens in any of the followers because the leader can't send heartbeat messages anymore. The constraints in election guarantee that if a new leader is elected, it must be one of the nodes which have the committed entries of the old leader from the last term. Those entries are not yet committed in the new leader yet because the rpc message sent by the old leader with the updated commit index was lost because of the network partition. There is another constraint in raft by which a leader can't commit entries from the older terms until it commits an entry in the current term. Once it commits an entry in the current term, it implies previous entries can also be safely committed because of the log matching property. Hope this helps.
How gossip can work in integration with it