Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=received:user-agent:date:subject:from:to:message-id:
	thread-topic:thread-index:in-reply-to:mime-version:content-type:
	content-transfer-encoding:x-originalarrivaltime;
	b=tYjZTmWIqMenAUyyX9OP4zmgfkUDLW9c3wjk1DVXurfBHJa2eHdOOH1VIOHwKNPB
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 20 Apr 2010 17:37:28 -0700
Subject: Re: odd error message
From: Mahadev Konar <mahadev@yahoo-inc.com>
To: <zookeeper-user@hadoop.apache.org>
Message-ID: <C7F396D8.33FED%mahadev@yahoo-inc.com>
Thread-Topic: odd error message
Thread-Index: Acrg6tHIXyxlUx4JB0GTDOFveac4CQ==
In-Reply-To: <q2yc7d45fc71004201414hb4d1b01dx9bb509cc29c7d376@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Ok, I think this is possible.
So here is what happens currently. This has been a long standing bug and
should be fixed in 3.4!!!!

https://issues.apache.org/jira/browse/ZOOKEEPER-335

A newly elected leader currently doesn't log the new leader transaction to
its database

In your case, the follower (the 3rd server) did log it but the leader never
did. Now when you brought up the 3rd server it had the transaction log
present but the leader did not have that. In that case the 3rd server cried
fowl and shut down.

Removing the DB is totally fine. For now, we should update our docs on 3.3
and mention that this problem might occur during upgrade and fix it in 3.4.


Thanks for bringing it up Ted.


Thanks
mahadev

On 4/20/10 2:14 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:

> We have just done an upgrade of ZK to 3.3.0.  Previous to this, ZK has been
> up for about a year with no problems.
> 
> On two nodes, we killed the previous instance and started the 3.3.0
> instance.  The first node was a follower and the second a leader.
> 
> All went according to plan and no clients seemed to notice anything.  The
> stat command showed connections moving around as expected and all other
> indicators were normal.
> 
> When we did the third node, we saw this in the log:
> 
> 2010-04-20 14:07:49,010 - FATAL [QuorumPeer:/0.0.0.0:2181:Follower@71] -
> Leader epoch 18 is less than our epoch 19
> 
> The third node refused all connections.
> 
> We brought down the third node, wiped away its snapshot, restarted and it
> joined without complaint.  Note that the third node
> was originally a follower and had never been a leader during the upgrade
> process.
> 
> Does anybody know why this happened?
> 
> We are fully upgraded and there was no interruption to normal service, but
> this seems strange.