Vishal K commented on ZOOKEEPER-917:

Hi Flavio,

Thanks for the clarification.

Looks like this scenario is not likely to happen if replace is done carefully. 
For the sake of argument, shouldn't we make the exception that you described 
only if the joining peer is going to be a follower? For the problem reported in 
this jira,  the server that was replaced (server 2) will not have seen the zxid 
received in the notifications from the other two nodes. Therefore, is this 
case, will it make sense for server 2 to start a new round of election?


> Leader election selected incorrect leader
> -----------------------------------------
>                 Key: ZOOKEEPER-917
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-917
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: leaderElection, server
>    Affects Versions: 3.2.2
>         Environment: Cloudera distribution of zookeeper (patched to never 
> cache DNS entries)
> Debian lenny
>            Reporter: Alexandre Hardy
>            Priority: Critical
>             Fix For: 3.3.3, 3.4.0
>         Attachments: zklogs-20101102144159SAST.tar.gz
> We had three nodes running zookeeper:
>   *
>   *
>   *
> failed, and was replaced by a new node 
> (automated startup). The new node had not participated in any zookeeper 
> quorum previously. The node was permanently removed from 
> service and could not contribute to the quorum any further (powered off).
> DNS entries were updated for the new node to allow all the zookeeper servers 
> to find the new node.
> The new node was selected as the LEADER, despite the fact that 
> it had not seen the latest zxid.
> This particular problem has not been verified with later versions of 
> zookeeper, and no attempt has been made to reproduce this problem as yet.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to