[
https://issues.apache.org/jira/browse/ZOOKEEPER-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576906#comment-13576906
]
Thawan Kooburat commented on ZOOKEEPER-1642:
--------------------------------------------
committeLog is just for optimization, if the follower doesn't have it when it
elected as a leader, the system still behave correctly. The bug that I saw
previously is that if loadDatabase() is called twice without clearing the
committedLog, it will have duplicate txns which may or may not cause the
problem. But in the patch that you proposed, it shouldn't happen.
Since we are just checking the flag before loading the db which we already do
something similar in ZooKeeperServer#startData(), we might not need a test if
the scope of the patch is what mentioned in the title.
Now that we know that ZooKeeper#shutdown() will clear the DB, so I guess the db
will need to be reloaded again during leader election after leader failure. I
think the optimization of keeping the db across leader election (except when
getting a SNAP or TRUNC) is worth doing, but that can be in a separate JIRA.
> Leader loading database twice
> -----------------------------
>
> Key: ZOOKEEPER-1642
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1642
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Flavio Junqueira
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1642.patch
>
>
> The leader server currently loads the database before running leader election
> when trying to figure out the zxid it needs to use for the election and again
> when it starts leading. This is problematic for larger databases so we should
> remove the redundant load if possible.
> The code references are:
> # getLastLoggedZxid() in QuorumPeer;
> # loadData() in ZooKeeperServer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
