[
https://issues.apache.org/jira/browse/ZOOKEEPER-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610270#comment-13610270
]
Thawan Kooburat commented on ZOOKEEPER-1674:
--------------------------------------------
If that is the case, I think we might be able to do something about this. Seem
like it should be possible to reuse db instance across leader election.
>From the top of my head at the moment, the tricky part is when last process
>zxid in db and the last logged zxid is not the same on the follower. So I
>think we need the dirty snapshot patch before we can work on this one.
I recently tested an ensemble with 4G of data, it takes almost 2 mins to
recover from leader election. In our branch, the followers also take snapshot
after they detected a leader failure, so they don't need to replay txnlog when
reloading the db. This optimization is good for an ensemble with high write
rate but not for an ensemble with large data size.
> There is no need to clear & load the database across leader election
> --------------------------------------------------------------------
>
> Key: ZOOKEEPER-1674
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1674
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Jacky007
>
> It is interesting to notice the piece of codes in QuorumPeer.java
> /* ZKDatabase is a top level member of quorumpeer
> * which will be used in all the zookeeperservers
> * instantiated later. Also, it is created once on
> * bootup and only thrown away in case of a truncate
> * message from the leader
> */
> private ZKDatabase zkDb;
> It is introduced by ZOOKEEPER-596. Now, we just drop the database every
> leader election.
> We can keep it safely with ZOOKEEPER-1549.
--
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
