You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "Pierre Yin (Jira)" <ji...@apache.org> on 2019/10/22 07:56:00 UTC
[jira] [Updated] (ZOOKEEPER-3589) 3.4-branch has potential data
inconsistency caused by ZOOKEEPER-3104
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre Yin updated ZOOKEEPER-3589:
----------------------------------
Description:
ZOOKEEPER-3104 describes one critical data inconsistency risk.
The risk also exists in 3.4 branch.
In our 3.4.13 production cluster, the data inconsistency happens for many times.
After digging some transaction logs and snapshot, we believe that ZOOKEEPER-3104 is the main risk to contributes to our data inconsistency.
The risk probability maybe higher than we can consider in real product environment. The serialization of big DataTree may leads to a big risk time window in the high write traffic situation. Any failure during the risk time window would cause the data inconsistency.
The data inconsistency is almost unacceptable in zookeeper semantic.
This issue is already fixed in 3.6. But I think it is very necessary to backport ZOOKEEPER-3104 to branch-3.4, especially in the situation that the migration from 3.4 to 3.5 actually take more effort to evaluate the compatibility risk in real product environment.
I will have submit a github pull request to fix it. Can anyone help us to review it please ?
Many thanks.
was:
ZOOKEEPER-3104 describes one critical data inconsistency risk.
The risk also exists in 3.4 branch.
In our 3.4.13 production cluster, the data inconsistency happens for many times.
After digging some transaction logs and snapshot, we believe that ZOOKEEPER-3104 is the main risk to contributes to our data inconsistency.
The risk probability maybe higher than we can consider in real product environment. The serialization of big DataTree may leads to a big risk time window in the high write traffic situation. Any failure during the risk time window would cause the data inconsistency.
The data inconsistency is almost unacceptable in zookeeper semantic.
This issue is already fixed in 3.6. But I think it is very necessary to backport ZOOKEEPER-3104 to branch-3.4, specially in the situation that the migration from 3.4 to 3.5 actually take more effort to evaluate the compatibility risk in real product environment.
I will have submit a github pull request to fix it. Can anyone help us to review it please ?
Many thanks.
> 3.4-branch has potential data inconsistency caused by ZOOKEEPER-3104
> --------------------------------------------------------------------
>
> Key: ZOOKEEPER-3589
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3589
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.13, 3.4.14
> Reporter: Pierre Yin
> Priority: Critical
> Labels: pull-request-available
>
> ZOOKEEPER-3104 describes one critical data inconsistency risk.
> The risk also exists in 3.4 branch.
> In our 3.4.13 production cluster, the data inconsistency happens for many times.
> After digging some transaction logs and snapshot, we believe that ZOOKEEPER-3104 is the main risk to contributes to our data inconsistency.
> The risk probability maybe higher than we can consider in real product environment. The serialization of big DataTree may leads to a big risk time window in the high write traffic situation. Any failure during the risk time window would cause the data inconsistency.
> The data inconsistency is almost unacceptable in zookeeper semantic.
> This issue is already fixed in 3.6. But I think it is very necessary to backport ZOOKEEPER-3104 to branch-3.4, especially in the situation that the migration from 3.4 to 3.5 actually take more effort to evaluate the compatibility risk in real product environment.
> I will have submit a github pull request to fix it. Can anyone help us to review it please ?
> Many thanks.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)