Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
3.2.0
-
None
-
Each machine:
CentOS 5.2 64-bit
2GB ram
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixedNetwork Topology:
DC : central data center
POD(N): remote data centerZookeeper Topology:
Leaders may be elected only in DC (weight = 1)
Only followers are elected in PODS (weight = 0)Each machine: CentOS 5.2 64-bit 2GB ram java version "1.6.0_13" Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0)
-
Reviewed
Description
In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0.
What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1.