Hello Deepak, due to ZOOKEEPER-1732 and then ZOOKEEPER-1805, there are some cases in which an ensemble can be formed so that it doesn't allow any other zookeeper server to join. This has been fixed in branch 3.4, but it hasn't been fixed in trunk yet. Check if the Notifications sent around contain different values for the vote in the members of the ensemble. If you force a new election (e.g. by killing the leader) I guess everything should work normally, but don't take my word for it. Flavio should know more about this.
Cheers, German. On Wed, Feb 26, 2014 at 4:04 AM, Deepak Jagtap <[email protected]>wrote: > Hi, > > I replacing one of the zookeeper server from 3 node quorum. > Initially all zookeeper serves were running 3.5.0.1515976 version. > I successfully replaced Node3 with newer version 3.5.0.1551730. > When I am trying to replace Node2 with the same zookeeper version. > I couldn't start zookeeper server on Node2 as it is continuously stuck in > leader election loop printing following messages: > > 2014-02-26 02:45:23,709 [myid:3] - INFO > [QuorumPeer[myid=3]/0:0:0:0:0:0:0:0:2181:FastLeaderElection@837] - > Notification time out: 60000 > 2014-02-26 02:45:23,710 [myid:3] - INFO > [WorkerSender[myid=3]:QuorumCnxManager@195] - Have smaller server > identifier, so dropping the connection: (5, 3) > 2014-02-26 02:45:23,712 [myid:3] - INFO > [WorkerReceiver[myid=3]:FastLeaderElection@605] - Notification: 3 > (n.leader), 0x0 (n.zxid), 0x1 (n.round), LOOKING (n.state), 3 (n.sid), 0x0 > (n.peerEPoch), LOOKING (my state)1 (n.config version) > > > Network connections and configuration of the node being upgraded are fine. > The other 2 nodes in the quorum are fine and serving the request. > > Any idea what might be causing this? > > Thanks & Regards, > Deepak >
