[ https://issues.apache.org/jira/browse/ZOOKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819802#comment-15819802
]
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_r95703179
--- Diff: bin/zkServer-initialize.sh ---
@@ -113,6 +113,8 @@ initialize() {
else
echo "No myid provided, be sure to specify it in $ZOO_DATADIR/myid if using non-standalone"
fi
+
+ date > "$ZOO_DATADIR/initialize"
--- End diff --
Nit: If the sole purpose of this file is to act as a marker, in spite of its content,
then a
```touch $ZOO_DATADIR/initialize```
would be enough, wouldn't it?
Of course, `date` is fine as well, no problem.
> 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)
|