[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968164#comment-13968164
 ] 

Flavio Junqueira commented on ZOOKEEPER-1794:
---------------------------------------------

The description is not really saying why you'd like to add this feature, 
[~abranzyck]. If I remember correctly, you're trying to cope with loss of disk 
state: a server gets its disk state wiped out or corrupted, possibly making the 
ensemble lose quorum for committed txns. Is this right? If so, what are you 
trying to guarantee here? Just to repeat it here, I find that adding a hash of 
the whole state preceding a txn is not ideal, and it is not clear this is the 
only option we have. 

> Add hash check to transaction history in quorum servers
> -------------------------------------------------------
>
>                 Key: ZOOKEEPER-1794
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1794
>             Project: ZooKeeper
>          Issue Type: Sub-task
>          Components: quorum
>    Affects Versions: 3.5.0
>            Reporter: Germán Blanco
>            Assignee: Germán Blanco
>             Fix For: 3.6.0
>
>         Attachments: ZOOKEEPER-1794.patch, ZOOKEEPER-1794.patch, 
> ZOOKEEPER-1794.patch
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> The goal of this task is to add a hash number to each transaction in the 
> transaction history. This hash number will depend on the entire transaction 
> history. This hash number will be the same in all members of the quorum, 
> since it shall have the same result if the members have the same transaction 
> history. That means that there will be no need to send any new information 
> between members of the quorum, during the broadcast phase. The hash number 
> will be checked by the leader when learners try to connect, and it shall also 
> be sent together with the snapshot during synchronisation. If the hash number 
> does not match, the synchronisation shall be done with a snapshot in order to 
> overwrite the conflicts in the transaction history.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to