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:[email protected]] Sent: Monday, September 28, 2015 07:27 م To: [email protected] Cc: [email protected] 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) < [email protected]> 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 >
