[
https://issues.apache.org/jira/browse/ZOOKEEPER-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064197#comment-14064197
]
Alexander Shraer commented on ZOOKEEPER-1967:
---------------------------------------------
If I understand correctly, QuorumPeer.start calls loadDataBase() which
processes both snapshots and transaction log.
A similar loadDataBase function is called if the log is truncated. So even if
non-committed transactions are initially applied, this is reverted if the log
is truncated.
BTW, how is your proposal O(1) ? It still requires processing the log, no ?
Actually, can you explain why your proposal is safe ? From your blog:
> when a server restarts it is able to truncate uncommitted logs and sync DIFF
> with leader.
What if a quorum of servers acked the transaction ? Preserving transactions
accepted (acked) by a quorum is a usual invariant both Paxos and ZK preserve.
For example, the previous leader could have seen the quorum of acks, committed
it locally, and even the commit message could have reached some minority of
servers. Then clients come and see the committed state, and then all servers
that have seen the commit crash. Next, according to your proposal, you truncate
the log at the other servers and the transaction disappears.
> 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)
