[
https://issues.apache.org/jira/browse/BOOKKEEPER-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rakesh R updated BOOKKEEPER-237:
--------------------------------
Attachment: Auto Recovery Detection - distributed chain approach.doc
bq.I'm getting to realize that the main difference between what you're
proposing and my half-baked proposal is that I'm trying to get rid of master
accountant election and have each bookie individually figuring out what it has
to replicate in the case of a crash. I believe that's the key difference.
bq. Also, should design multiple groups and pointers to withstand multiple
crashes. Instead can we make it simple by choosing one guy for monitoring?
I'm just attaching(Auto Recovery Detection - distributed chain approach.doc) my
thoughts about, how does chaining based distributed approach works?. Hope you
are also thinking about similar approach. Please review.
> Automatic recovery of under-replicated ledgers and its entries
> --------------------------------------------------------------
>
> Key: BOOKKEEPER-237
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-237
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Affects Versions: 4.0.0
> Reporter: Rakesh R
> Assignee: Rakesh R
> Attachments: Auto Recovery Detection - distributed chain
> approach.doc, Auto Recovery and Bookie sync-ups.pdf
>
>
> As per the current design of BookKeeper, if one of the BookKeeper server
> dies, there is no automatic mechanism to identify and recover the under
> replicated ledgers and its corresponding entries. This would lead to losing
> the successfully written entries, which will be a critical problem in
> sensitive systems. This document is trying to describe few proposals to
> overcome these limitations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
