[
https://issues.apache.org/jira/browse/ZOOKEEPER-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567101#comment-14567101
]
Akihiro Suda commented on ZOOKEEPER-2189:
-----------------------------------------
Hi Alexander Shraer,
Thank you for the feedback.
I understood we cannot solve the issue by verifying acks,
but could you tell me what config registry stands for?
(something like "discovery.etcd.io" or Consul's Atlas integration?)
> 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)
