[
https://issues.apache.org/jira/browse/ZOOKEEPER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064113#comment-14064113
]
Alexander Shraer commented on ZOOKEEPER-1967:
---------------------------------------------
Hi,
There is no doubt that it is possible - the only question is whether the
transaction log is processed in ZK before the information about the last acked
reconfig is needed. Even if this is not the case we could always just process
the log when we need the info. But it seems that this may not be necessary
since, if I understand correctly, when the server reboots it loads the database
and as part of that it reads the transaction log. So we may even be able to
look in the config znode at that point to find the last proposed reconfig.
Thanks for the pointer to your blog. Few comments (sorry for listing it here):
1)
> Note that the leader sending the reconfig commit should be in the new quorum;
> if not, transfer leadership after both
> quorums of acking.
The original leader sending the reconfig doesn't have to be in the new quorum.
In fact it could have crashed long ago. However, if the quorum collected during
FLE contains someone who acked a new reconfig and someone who didn't, then the
first guy will necessarily have seen a higher zxid and so the guy who didn't
see the reconfig will not become leader. If all the quorum participants didn't
see the reconfig, it will be lost.
2) There is no need to append a commit to each log entry in ZK to eliminate the
temp dynamic config file. All you need is to process the transaction log and
find the last *proposed* reconfig. In addition to that you have the last
committed config in the dynamic config file - this file is written every time a
reconfig is committed. If the version of the last proposed reconfig is bigger
than the one of the last committed config, you may have a reconfig in progress
(or you may just not have seen the commit yet).
Alex
> 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)
