zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-261) Reinitialized servers should not participate in leader election
Date Thu, 12 Jan 2017 03:42:17 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820065#comment-15820065
] 

ASF GitHub Bot commented on ZOOKEEPER-261:
------------------------------------------

Github user eribeiro commented on a diff in the pull request:

    https://github.com/apache/zookeeper/pull/120#discussion_r95721046
  
    --- Diff: src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java ---
    @@ -175,11 +193,20 @@ public long restore(DataTree dt, Map<Long, Integer> sessions,
                             "No snapshot found, but there are log entries. " +
                             "Something is broken!");
                 }
    -            /* TODO: (br33d) we should either put a ConcurrentHashMap on restore()
    -             *       or use Map on save() */
    -            save(dt, (ConcurrentHashMap<Long, Integer>)sessions);
    -            /* return a zxid of zero, since we the database is empty */
    -            return 0;
    +
    +            if (suspectEmptyDB) {
    +                /* return a zxid of -1, since we are possibly missing data */
    +                LOG.warn("Unexpected empty data tree, setting zxid to -1");
    --- End diff --
    
    Are we 100% sure the data tree is empty? Couldn't it be only partially complete? I mean
the machine recorded up to transaction n, but lost transactions n+1, n+2, n+3, etc?


> 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)

Mime
View raw message