zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Wassermann <baruc...@hotmail.com>
Subject RE: Leader election scenario
Date Mon, 01 Feb 2016 13:49:01 GMT
Hi Adam, 

Yes, makes sense. If s1 committed the transaction, it means that at least one of the other
servers has promised to execute this transaction as well and given that the new quorum will
overlap in at least one node, the new leader will process the corresponding proposal before
accepting any new ones. A temporary lapse in my understanding of the zab protocol :-)

Thank you, 
-- Bruno

> Date: Mon, 1 Feb 2016 13:26:01 +0000
> Subject: Re: Leader election scenario
> From: adam@milne-smith.co.uk
> To: user@zookeeper.apache.org
> Hi Bruno,
> S1 can't have a later zxid than both S2 and S3 as at least 2 of the 3 servers need to
have seen the transaction for it to have completed.
> This state shouldn't be possible:
> s1, zxid=4
> s2, zxid=3
> s3, zxid=3
> Instead you'll at least have either:
> s1, zxid=4
> s2, zxid=4
> s3, zxid=3 
> In this case s2 and s3 will decide s2 is the new leader.
> Or:
> s1, zxid=4
> s2, zxid=3
> s3, zxid=4
> In this case s2 and s3 will decide s3 is the new leader.
> Hope this helps.
> Thanks,
> Adam
> On 1 Feb 2016 13:04, Bruno Wassermann <baruch_w@hotmail.com> wrote:
> >
> > My apologies, if this should be non-sensical, but what would happen in the following
> >
> > A leader election takes place in a three-server ensemble as the previous leader,
s1, has been partitioned off. The previous leader had a later zxid than the remaining servers.
The remaining servers exchange election notifications and elect s3 to be the new leader, form
a quorum consisting of s2 and s3 and accept write requests. 
> >
> > s1, zxid=4s2, zxid=3s3, zxid=3 
> >
> > Is it the case that at least one of s2 or s3 should have seen and agreed to the
write leading to zxid=4 and that the new quorum will thus write zxid=4 first before handling
other requests? 
> > -- Bruno     
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message