[ https://issues.apache.org/jira/browse/ZOOKEEPER-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14570280#comment-14570280 ]
Patrick Hunt commented on ZOOKEEPER-2189: ----------------------------------------- Not sure re config registry. What would that entail? Git? :-) > multiple leaders can be elected when configs conflict > ----------------------------------------------------- > > Key: ZOOKEEPER-2189 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2189 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection > Affects Versions: 3.5.0 > Reporter: Akihiro Suda > > This sequence leads the ensemble to a split-brain state: > * Start server 1 (config=1:participant, 2:participant, 3:participant) > * Start server 2 (config=1:participant, 2:participant, 3:participant) > * 1 and 2 believe 2 is the leader > * Start server 3 (config=1:observer, 2:observer, 3:participant) > * 3 believes 3 is the leader, although 1 and 2 still believe 2 is the leader > Such a split-brain ensemble is very unstable. > Znodes can be lost easily: > * Create some znodes on 2 > * Restart 1 and 2 > * 1, 2 and 3 can think 3 is the leader > * znodes created on 2 are lost, as 1 and 2 sync with 3 > I consider this behavior as a bug and that ZK should fail gracefully if a > participant is listed as an observer in the config. > In current implementation, ZK cannot detect such an invalid config, as > FastLeaderElection.sendNotification() sends notifications to only voting > members and hence there is no message from observers(1 and 2) to the new > voter (3). > I think FastLeaderElection.sendNotification() should send notifications to > all the members and FastLeaderElection.Messenger.WorkerReceiver.run() should > verify acks. > Any thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)