Re: how to solve this uncommitted log problem?

81 views
Skip to first unread message
Message has been deleted

Юрий Соколов

unread,
Dec 11, 2017, 1:12:22 PM12/11/17
to raft-dev
New leader is chosen based on nextIdx, not on commitIdx. So, B will be new leader, not C.

понедельник, 11 декабря 2017 г., 18:58:14 UTC+3 пользователь jin deng написал:
hi all,
    I still has one problem with the uncommitted problem.
    If we have a cluster with 3 nodes A,B,C and A as a leader.Initially,the commitIdx is 2,2,2 and nextIdx is 3,3,3.The a client sends a write to the leader and A appends the log entry into its own log and replicates it on B but not on C,as the number of replicas fulfill the majority requirement so A commits this log and replies to the client,but the AppendEntries to update commitIdx has not been sent to the two followers,so at this moment,the cluster status is:

           commitIdx     nextIdx
A              3                  4
B              2                  4
C              2                  3

Now,the A crashes and C is elected as new leader as its commitIdx is biggest among B and C.And leader C will force the B to remove logs which C doesn't have.so the cluster becomes:

           commitIdx     nextIdx
A              off                off
B              2                  3
C              2                  3

If the client sends a read request to read the latest written value,we will not return it because the log(log index is 3) has been removed.

Martin Furmanski

unread,
Jan 30, 2018, 2:20:17 PM1/30/18
to raft-dev


On Monday, December 11, 2017 at 7:12:22 PM UTC+1, Юрий Соколов wrote:
New leader is chosen based on nextIdx, not on commitIdx. So, B will be new leader, not C.

понедельник, 11 декабря 2017 г., 18:58:14 UTC+3 пользователь jin deng написал:
hi all,
    I still has one problem with the uncommitted problem.
    If we have a cluster with 3 nodes A,B,C and A as a leader.Initially,the commitIdx is 2,2,2 and nextIdx is 3,3,3.The a client sends a write to the leader and A appends the log entry into its own log and replicates it on B but not on C,as the number of replicas fulfill the majority requirement so A commits this log and replies to the client,but the AppendEntries to update commitIdx has not been sent to the two followers,so at this moment,the cluster status is:

           commitIdx     nextIdx
A              3                  4
B              2                  4
C              2                  3

Now,the A crashes and C is elected as new leader as its commitIdx is biggest among B and C.

No, the commitIdx is irrelevant. It is the appendIndex which is relevant for choosing next leader. The leader will be B.
 
Reply all
Reply to author
Forward
0 new messages