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

Hongchao Deng commented on ZOOKEEPER-1967:
------------------------------------------

Hi,

When a server reboots, it shouldn't load (if you mean apply) the transaction 
log because it doesn't know which are committed. If so, processing the log and 
retrieving reconfig info will require O(n) disk operations; while in my 
suggestion, it's O(1).

Appending a commit flag will not only eliminate temp file in dynamic reconfig, 
but also simplify TRUNC logic and makes it possible to apply committed 
transactions on bootup. The original Zab is correct. It's just a 
choice/tradeoff. As you said, "All you need is to process the transaction log 
and find the last proposed reconfig". This will make the logic complicated on 
bootup.

> Eliminate the temp dynamic config file, find last proposed config in 
> transaction log.
> -------------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1967
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1967
>             Project: ZooKeeper
>          Issue Type: Improvement
>          Components: quorum, server
>            Reporter: Alexander Shraer
>
> The .next temporary config file is created when a server acks a reconfig 
> proposal.
> During reconfig commit this file becomes the permanent dynamic config file.
> This temp file is read (if exists) during server boot to determine whether 
> there is a reconfig potentially in progress. 
> This info is also available in the transaction log, since reconfig is a 
> transaction. Initially I chose not to take this information from the 
> transaction log, mainly for simplicity, since I believed that we need the 
> last proposed reconfig info before we're processing the transaction log (for 
> example, if we'd like to contact new config servers during FLE - this is 
> discussed in ZOOKEEPER-1807). 
> It would be useful to revisit this issue and check whether we could eliminate 
> the temporary dynamic config file, finding the last proposed reconfig in the 
> the transaction log.



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

Reply via email to