zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ibrahim El-sanosi (PGR)" <i.s.el-san...@newcastle.ac.uk>
Subject RE: 3-server Zab cluster
Date Mon, 28 Sep 2015 22:51:47 GMT
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
View raw message