[ https://issues.apache.org/jira/browse/FLINK-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889901#comment-16889901 ]
Quan Shi commented on FLINK-10052: ---------------------------------- hi [~Tison] Sounds reasonable. Elect a new leader and recovery from checkpoints is a concise way for HA. What happens to FLINK if zookeeper split-brain or zookeeper cluster shutdown? Does FLINK has fencing mechanism like HDFS? > Tolerate temporarily suspended ZooKeeper connections > ---------------------------------------------------- > > Key: FLINK-10052 > URL: https://issues.apache.org/jira/browse/FLINK-10052 > Project: Flink > Issue Type: Improvement > Components: Runtime / Coordination > Affects Versions: 1.4.2, 1.5.2, 1.6.0, 1.8.1 > Reporter: Till Rohrmann > Assignee: Dominik Wosiński > Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > This issue results from FLINK-10011 which uncovered a problem with Flink's HA > recovery and proposed the following solution to harden Flink: > The {{ZooKeeperLeaderElectionService}} uses the {{LeaderLatch}} Curator > recipe for leader election. The leader latch revokes leadership in case of a > suspended ZooKeeper connection. This can be premature in case that the system > can reconnect to ZooKeeper before its session expires. The effect of the lost > leadership is that all jobs will be canceled and directly restarted after > regaining the leadership. > Instead of directly revoking the leadership upon a SUSPENDED ZooKeeper > connection, it would be better to wait until the ZooKeeper connection is > LOST. That way we would allow the system to reconnect and not lose the > leadership. This could be achievable by using Curator's {{LeaderSelector}} > instead of the {{LeaderLatch}}. -- This message was sent by Atlassian JIRA (v7.6.14#76016)