[
https://issues.apache.org/jira/browse/BOOKKEEPER-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497061#comment-13497061
]
Rakesh R commented on BOOKKEEPER-249:
-------------------------------------
bq.after updating failed bookie's ledgers in '/ledgers/deleted/Bi' when
changing ensemble
In general, I agree with your suggestion of first update for deletion and then
go to rereplication. Please go through the corner case in the ZKLedgerManager
impl and causing data loss like, successfully updated the failed bookie's
ledgers in '/ledgers/deleted/Bi' and while changing ensemble for
auto-rereplication zk got disconnected. Now Bi will go ahead with ledger
deletion if it rejoins, also rereplication process will see the bookie is live
and stops rereplication. I feel, this is very straight scenario with
ZKLedgerManager and nothing comes in my mind otherthan multi-transaction api
usage:(
> Revisit garbage collection algorithm in Bookie server
> -----------------------------------------------------
>
> Key: BOOKKEEPER-249
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-249
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-server
> Reporter: Sijie Guo
> Fix For: 4.2.0
>
> Attachments: gc_revisit.pdf
>
>
> Per discussion in BOOKKEEPER-181, it would be better to revisit garbage
> collection algorithm in bookie server. so create a subtask to focus on it.
--
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
