[
https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Greenwood-Geer updated ZOOKEEPER-498:
------------------------------------------
Attachment: zoo.cfg
pod-zook-logs-01.tar.gz
dc-zook-logs-01.tar.gz
Zookeeper Logs and configuration files:
dc1-zook01.log
dc1-zook02.log
dc1-zook03.log
dc1-zook04.log
dc1-zook05.log
pd1-zook01.log
pd1-zook02.log
pd4-zook01.log
pd4-zook02.log
zoo.cfg
> Unending Leader Elections : WAN configuration
> ---------------------------------------------
>
> Key: ZOOKEEPER-498
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498
> Project: Zookeeper
> Issue Type: Bug
> Components: leaderElection
> Affects Versions: 3.2.0
> Environment: 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)
> Reporter: Todd Greenwood-Geer
> Priority: Critical
> Fix For: 3.2.1
>
> Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zoo.cfg
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
