[
https://issues.apache.org/jira/browse/ZOOKEEPER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064190#comment-14064190
]
Flavio Junqueira commented on ZOOKEEPER-1967:
---------------------------------------------
[~hdeng], I like your motivation, but there are some subtleties I'm not sure
you're getting:
bq. When a server reboots, it shouldn't load
The server needs to know the last zxid it accepted for the leader election, so
it loads the database (snapshot + txns in the log).
bq. (if you mean apply) the transaction log because it doesn't know which are
committed.
It doesn't matter if it is applying committed txns or not to the tentative
epoch state, as long as it doesn't create a snapshot of this tentative state. A
server loads the database (snapshot + suffix of txns from the log) before
leader election and it leaves the election as either a follower or a leader
(put observers on the side for now). If it is a leader, it will try to get its
tentative state committed, and note that the tentative state might already
contain a prefix of txns that has been committed already. A follower will try
to get just a diff from the leader, and in the worst case it will have to drop
its tentative state and take a snapshot from the leader.
bq. processing the log and retrieving reconfig info will require O( n ) disk
operations;
Just to emphasize, we need to go through the log when we load the database
before leader election, so we could piggyback on that operation.
> 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)
