THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Warning |
|---|
The wiki pages are not used for documentation any more. Please visit http://bookkeeper.apache.org for latest documentation. |
BookKeeper auto recovery discussed in BOOKKEEPER-237 JIRA and already implemented many sub-tasks in it.
We have to discuss about Fsck feature. Edit this page
...
When any Bookie goes down in the BookKeeper cluster, there is no way to recover the lost data from that Bookie server. For example, if we have 2 replicas for a ledger in BK cluster, and a node goes down from it, we will be running the cluster with single replica. Running clusters with single or no replicas will be a risk, as nodes may fail in general. To avoid such situations, we need a mechanism for recovering the data to new bookies for meeting the enough replica criteria (quorum size) and it is called as Auto-Recovery in BookKeeper.
...
This Auto-recovery node has to be started in each Bookie machine. All recovery nodes will participate in leader election and one Auditor may become as the leader and others will just watch the elected auditor failure to participate again in next election.
Auditor:
Once the Auditor thread is started, the auditor elector will go for the election to win the auditing job for Bookie cluster. Here, auditing job would be that, it has to detect the under-replicated ledgers in the cluster due to Bookie failures.
Auditor will keep watch on the available Bookies in the cluster. Bookie will add its entry in the available bookie during Bookie server startup. So, when the Bookie is crashed or killed, Auditor will get a notification about the children change in available Bookie list. Auditor will immediately scan the complete ledger list related to that failed Bookie. On getting the details of ledgers, Auditor node publishes the under-replicated
ledgers in under-replication znode path in Zookeeper. After this, again it will be watching Bookie failures (by resetting Zookeeper watcher) on available Bookie list.
...