Re: [Tarantool-patches] [PATCH 1/2] replication: introduce ballot.can_be_leader

[Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

On Wed, Jul 21, 2021 at 02:20:57AM +0300, Konstantin Osipov wrote:
> 
> Right. That's what I am saying - the cluster is stuck even though
> the quorum (3 nodes) is present. And this is not something
> consistent, such clusters will get stuck simply based on the state
> of the voter - sometimes they will, sometimes they won't.

Which is exactly the same as it would be if node E is a follower but at
the moment when it gonna be selected as a leader the network environment
get broken (or enter a flip/flop cycle). In such case even traditional
Raft nodes (ie those which doen't have "voters" at all) will behave
the same way -- sometimes quorum will be achieved and sometimes not.
Though I see what you mean, thanks!

> > Lets assume the E's index is low, say 3
> > 
> >     A  B  C  D  E
> >    {5, 4, 4, 3, 3}
> >     *  *
> >     L  F  F  F  V
> > 
> > in this config the leader won't commit record 5 until one
> > of {C,D,E} write the new record(s) since otherwise the quorum
> > won't be reached. Assume A and B get out of the set without
> > record 4 written to C
> > 
> >      A  B  C  D  E
> >     {-, -, 4, 3, 3}
> >            F  F  V
> > 
> > Now the node E can vote for C and D because its index is LE.
> > And since C's index is bigger than others it will be elected
> > next as far as I understand, no?
> 
> You're right, assuming the voter never casts a vote for a
> candidate with a shorter log the safety is not violated. I wasn't
> sure it's the case, and presumed that the voter may have no log of
> its own. But still there are issues with liveness. Raft PHD has
> learners, so why not use them instead.

Yeah, voters are to carry logs as well and it is their critical
feature but idea about Raft learners might be even better, I think
Vlad has some thoughts about learners.