[
https://issues.apache.org/jira/browse/ZOOKEEPER-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000717#comment-17000717
]
Fangmin Lv commented on ZOOKEEPER-3607:
---------------------------------------
[~jiangjiafu] in the step 10, when zk3 tries to sync with zk2, it has different
epoch, and zk2 will use SNAP sync instead of TRUNC, right?
Is 3.4 has different behavior with 3.5 and 3.6?
> Potential data inconsistency due to the inconsistency between
> ZKDatabase.committedLog and dataTree in Trunc sync.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-3607
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3607
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
> Affects Versions: 3.4.14
> Reporter: Jiafu Jiang
> Priority: Critical
>
> I will describe the problem by a detail example.
> 1. Suppose we have three zk servers: zk1, zk2, and zk3. zk1 and zk2 are
> online, zk3 is offline, zk1 is the leader.
> 2. In TRUNC sync, zk1 sends a TRUNC request to zk2, then sends the remaining
> proposals in the committedLog. *When the follower zk2 receives the proposals,
> it applies them directly into the datatree, but not the committedLog.*
> 3. After the data sync phase, zk1 may continue to send zk2 more committed
> proposals, and they will be applied to both the datatree and the committedLog
> of zk2.
> 4. Then zk1 fails, zk3 restarts successfully, zk2 becomes the leader.
> 5. The leader zk2 sends a TRUNC request to zk3, then the remaining proposals
> from the committedLog. But since some proposals, which are from the leader
> zk1 in TRUNC sync(as I describe above), are not in the committedLog, they
> will not be sent to zk3.
> 6. Now data inconsistency happens between zk2 and zk3, since some data may
> exist in zk2's datatree, but not zk3's datatree.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
