[
https://issues.apache.org/jira/browse/ZOOKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819803#comment-15819803
]
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_r95709489
--- Diff:
src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java ---
@@ -167,6 +175,16 @@ public long restore(DataTree dt, Map<Long, Integer>
sessions,
PlayBackListener listener) throws IOException {
long deserializeResult = snapLog.deserialize(dt, sessions);
FileTxnLog txnLog = new FileTxnLog(dataDir);
+ boolean suspectEmptyDB;
--- End diff --
Could we rename this to `recoveringDB` or `recoveringNode`?
My rationale is: `suspectEmptyDB` looks vague to me, **plus** __if I
understood it right__ a node could have been shutdown and restarted after some
time. So, not necessarily its DB will be empty, but it is in a recovering
process so we want to avoid that it becoming the leader and messing up with
transactions performed while it was offline, right?
Could we rename this to `recoveringDB` or `recoveringNode`?
My rationale is: `suspectEmptyDB` looks vague to me, **plus** because __if
I understood it right__ a node could have been shutdown and restarted after
some time. So, not necessarily its DB will be empty, but it is in a recovering
process so we want to avoid that it becoming the leader and messing up with
transactions performed while it was offline, right?
> 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)
