zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shraer <shra...@gmail.com>
Subject Re: 3-server Zab cluster
Date Mon, 28 Sep 2015 23:10:38 GMT
I'm not 100% sure whether operations that were pending on the leader are
sent out during sync when this leader looses quorum and re-elected. If so,
then maybe you're right. But in any case, this would not work for 5 or more
servers...

On Mon, Sep 28, 2015 at 3:51 PM, Ibrahim El-sanosi (PGR) <
i.s.el-sanosi@newcastle.ac.uk> wrote:

> Thank you Alex for replaying.
>
> When you said " the leader gets re-elected and the operation is truncated
> from logs at other servers". I though the new leader will sync the its logs
> with other followers (synchronization phase), resulting in the operation
> will commit by new quorum.  Let me make the scenarios as steps:
>
> 1. leader  (L)  sends a proposal p with zxid =10 to F1 and F2.
> 2. F1 logs, sends an ACK, commits, replays to clients and crashes. F2
> crashes before receiving P10. L has not received any ACKs
>
> Possible solution  (1)
> The leader will move to LOOKING phase as there is no quorum supporting its
> leadership. Now Assume F2 wakes up. F2 forms a quorum with the L (pervious
> leader), L becomes new leader again as it has latest zxid (10) in its log.
> L syncs its state with F2, as a result L, F1 (before crashing) and F2
> commit P10.  Is that correct?
>
> Possible solution  (2)
> The leader will move to LOOKING phase as there is no quorum supporting its
> leadership. Now Assume F1 (with Zxid =10  committed) wakes up. I am not
> sure who should be a leader (F1 with Zxid =10 committed or L (pervious
> leader) with Zxid = 10 logged), I think F1 become a new leader as it has
> Zxid = 10 committed. F1 forms a quorum with the L (pervious leader), F1
> becomes new leader as it has latest zxid (10) . L (new leader) syncs its
> state with L (pervious leader now become a follower), as a result Zxid10
> commits by new quorum.  Is that correct?
>
> What do you think?
>
> Ibrahim
>
>
>
>
>
> -----Original Message-----
> From: Alexander Shraer [mailto:shralex@gmail.com]
> Sent: Monday, September 28, 2015 07:27 م
> To: user@zookeeper.apache.org
> Cc: dev@zookeeper.apache.org
> Subject: Re: 3-server Zab cluster
>
> Committing locally when sending an ACK at a server would lead to loss of
> consistency - it is possible that this is the only server that acks, e.g.,
> this server is temporarily disconnected from the leader, the leader gets
> re-elected and the operation is truncated from logs at other servers. Its
> ok to ACK it but its not ok to commit since this exposes this to users as a
> committed operation that they can see.
>
> On Mon, Sep 28, 2015 at 4:19 AM, Ibrahim El-sanosi (PGR) <
> i.s.el-sanosi@newcastle.ac.uk> wrote:
>
> > In Zab, assume we have a cluster consists of 3-servers. To deliver a
> > write request, it must run 3 communication steps proposal,
> > acknowledgement and commit.
> > As Zab uses reliable FIFO, it is possible to remove commit round. As
> > soon as a follower receives a proposal, it logs, sends an ACK and
> > commits locally. Upon receiving ACK from any follower, leader commits
> > a proposal locally, no COMMIT message need to be sent to followers. In
> > this case, all servers commit a proposal in two round-trips, resulting
> > in reducing latency particularly in followers.
> >
> > Note that this optimization can only work in 3-servers cluster
> > (follower reaches a majority as soon as it acks).
> > Does anyone see any problems with such (small) optimization?
> > Ibrahim
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message