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)