You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "Mate Szalay-Beko (Jira)" <ji...@apache.org> on 2022/03/29 06:12:00 UTC
[jira] [Commented] (ZOOKEEPER-4503) A restarted node can be accessed before it finishing synchronization with leader
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17513828#comment-17513828 ]
Mate Szalay-Beko commented on ZOOKEEPER-4503:
---------------------------------------------
Hello [~willtoshare] ,
Thanks for raising the issue! Do you have any logs / can you reproduce this issue? This sounds bad. But as far as I remember (I was looking this part a while ago), the ZooKeeper server shouldn't start serving client request until the synchronization finished.
> A restarted node can be accessed before it finishing synchronization with leader
> --------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-4503
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4503
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.6.3
> Reporter: May
> Priority: Major
>
> Here is the bug triggering process:
>
> # A cluster with three nodes: zk1, zk2 and zk3. zk3 is the leader.
> # client create a znode "/bug" with value "bad"
> # client update znode "/bug" to value "good"
> # zk1 crashes before receiving proposal for leader for the request in step 3.
> # "/bug" is modified to "good"
> # zk1 was restarted
> # another client connects to zk1, reads "/bug" and gets "bad"
> # zk1 finish synchronization with current leader, and then modify "/bug" to "good".
> The problem is that zk1 should be accessed by a client when it finish synchronization with current leader in case of a client reads bad data.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)