0

I'm reading about raft, but I got a bit confused when it comes to consensus after a network partition.

So, considering a cluster of 2 nodes, 1 Leader, 1 Follower.

Before partitioning, there where X messages written, successfully replicated, and then imagine that a network problem caused partitioning, so there are 2 partitions, A(ex-leader) and B(ex-follower), which are now both leaders (receiving writes):

before partition | Messages  |x| Partition   | Messages  
Leader           | 0 1 2 3 4 |x| Partition A | 5  6  7  8  9
Follower         | 0 1 2 3 4 |x| Partition B | 5' 6' 7' 8' 9'

After the partition event, we've figured it out, what happens?

a) We elect 1 new leader and consider its log? (dropping messages of the new follower? e.g:

0 1 2 3 4 5 6 7 8 9 (total of 10 messages, 5 dropped)

or even:

0 1 2 3 4 5' 6' 7' 8' 9' (total of 10 messages, 5 dropped)

(depending on which node got to be leader)

b) We elect a new leader and find a way to make consensus of all the messages?

0 1 2 3 4 5 5' 6 6' 7 7' 8 8' 9 9' (total of 15 messages, 0 dropped)

if b, is there any specific way of doing that? or it depends on client implementation? (e.g.: message timestamp...)

Marcelo Boeira
  • 860
  • 8
  • 22

1 Answers1

2

The leaders log is taken to be "the log" when the leader is elected and has successfully written its initial log entry for the term. However in your case the starting premise is not correct. In a cluster of 2 nodes, a node needs 2 votes to be leader, not 1. So given a network partition neither node will be leader.

superfell
  • 18,780
  • 4
  • 59
  • 81