[
https://issues.apache.org/jira/browse/ZOOKEEPER-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129973#comment-16129973
]
Hadoop QA commented on ZOOKEEPER-2872:
--------------------------------------
-1 overall. GitHub Pull Request Build
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 6 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 failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/942//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/942//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/942//console
This message is automatically generated.
> Interrupted snapshot sync causes data loss
> ------------------------------------------
>
> Key: ZOOKEEPER-2872
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2872
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.10, 3.5.3, 3.6.0
> Reporter: Brian Nixon
>
> There is a way for observers to permanently lose data from their local data
> tree while remaining members of good standing with the ensemble and
> continuing to serve client traffic when the following chain of events occurs.
> 1. The observer dies in epoch N from machine failure.
> 2. The observer comes back up in epoch N+1 and requests a snapshot sync to
> catch up.
> 3. The machine powers off before the snapshot is synced to disc and after
> some txn's have been logged (depending on the OS, this can happen!).
> 4. The observer comes back a second time and replays its most recent snapshot
> (epoch <= N) as well as the txn logs (epoch N+1).
> 5. A diff sync is requested from the leader and the observer broadcasts
> availability.
> In this scenario, any commits from epoch N that the observer did not receive
> before it died the first time will never be exposed to the observer and no
> part of the ensemble will complain.
> This situation is not unique to observers and can happen to any learner. As a
> simple fix, fsync-ing the snapshots received from the leader will avoid the
> case of missing snapshots causing data loss.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
