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

[Konstantin Osipov via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

* Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [21/07/20 23:06]:
> >>>
> >>> Imagine there are nodes A, B, C, D, E.

^^^ 

> >>> A is a leader, E is a voter which can not become a leader.
> >>>
> >>> Imagine A's log index is 5, B = 4, C = 3, D = 2, E = 5.
> >>>
> >>> The majority's log index is 4, so entry 4 is committed. A dies, B
> >>> is partitioned away. The cluster is stuck, because neither C nor B
> >>> can get a quorum (3 votes).
> >>
> >> But how is it different from the real Raft? In normal Raft I can say
> >> E simply is too slow to make any actions. It is just stuck or died.
> >> The cluster will be stuck then, yes. Not much you can do here.
> > 
> > In a real raft:
> > - liveness is guaranteed if quorum is present; this guarantee here
> >   is not held
> > - you never sacrifice safety for liveness; you never lose
> >   committed entries if quorum is present; and you never lose it
> >   unnoticed! here you can lose a committed entry and not notice
> >   it.
> 
> Please, show me an example. The example above only shows that the
> election might stop if there are issues with the quorum. And this
> will happen regardless of whether I have voter role or not. In normal
> Raft you can kill 3/5 nodes and nothing will work too.

What is not clear with the example above? In it, I kill 2 out of
5, not 3 out of 5. And no, in Raft "nothing will work" is not
correct. The system will not be live, but will be safe.

-- 
Konstantin Osipov, Moscow, Russia