[ https://issues.apache.org/jira/browse/ZOOKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819633#comment-15819633 ]
Hadoop QA commented on ZOOKEEPER-261: ------------------------------------- +1 overall. GitHub Pull Request Build +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 20 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 3.0.1) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/205//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/205//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/205//console This message is automatically generated. > Reinitialized servers should not participate in leader election > --------------------------------------------------------------- > > Key: ZOOKEEPER-261 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-261 > Project: ZooKeeper > Issue Type: Improvement > Components: leaderElection, quorum > Reporter: Benjamin Reed > > A server that has lost its data should not participate in leader election > until it has resynced with a leader. Our leader election algorithm and > NEW_LEADER commit assumes that the followers voting on a leader have not lost > any of their data. We should have a flag in the data directory saying whether > or not the data is preserved so that the the flag will be cleared if the data > is ever cleared. > Here is the problematic scenario: you have have ensemble of machines A, B, > and C. C is down. the last transaction seen by C is z. a transaction, z+1, is > committed on A and B. Now there is a power outage. B's data gets > reinitialized. when power comes back up, B and C comes up, but A does not. C > will be elected leader and transaction z+1 is lost. (note, this can happen > even if all three machines are up and C just responds quickly. in that case C > would tell A to truncate z+1 from its log.) in theory we haven't violated our > 2f+1 guarantee, since A is failed and B still hasn't recovered from failure, > but it would be nice if when we don't have quorum that system stops working > rather than works incorrectly if we lose quorum. -- This message was sent by Atlassian JIRA (v6.3.4#6332)