[
https://issues.apache.org/jira/browse/BOOKKEEPER-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490288#comment-13490288
]
Yixue (Andrew) Zhu commented on BOOKKEEPER-365:
-----------------------------------------------
To add more detail, the recovery needs to consult at least read-quorum (2)
bookies to get last-confirmed entry id, instead of max of all, uses the max
entry id which at least two bookies have. Let us call this read_quorum_rule.
Now we go back to your example,
1) can proceed since both A, B claim no entries for the ledger, the
last-confirmed-entry-id is 0 based on the read_quorum_rule.
2) is correct, as B and C claim no entries for the ledger.
Of course, if recovery cannot reach at least read-quorum(2) bookies, then it
cannot close the ledger.
The reasoning is based on the fact that if Write-quorum is not reached, then
the entry is not acknowledged to clients. It is legal for it to be lost.
> Ledger will never recover if one of the quorum bookie is down forever and
> others dont have entry
> ------------------------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-365
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-365
> Project: Bookkeeper
> Issue Type: Bug
> Affects Versions: 4.0.0, 4.1.0
> Reporter: Sijie Guo
> Fix For: 4.2.0
>
>
> As discussed in BOOKKEEPER-355, current fix to handle the below issue is not
> correct. Need to find out new solution
> If some bookies of a quorum gone forever, some bookies of this quorum are
> still alive but doesn't have that entry (NoSuchEntry or NoSuchLedger), then
> the ledger doesn't have any evidence to recovery/close 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
