[
https://issues.apache.org/jira/browse/BOOKKEEPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234591#comment-13234591
]
Flavio Junqueira commented on BOOKKEEPER-112:
---------------------------------------------
There are two occasions during the lifetime of a ledger that we use consensus
through zookeeper: when we change the ensemble and when we close the ledger. By
design, the former is only proposed by the writer, whereas the latter can be
proposed by either the writer or another client trying to recover it. Trying to
change the design so that we can have multiple clients proposing changes to the
ensemble of a ledger would be difficult and prone to errors, so I suggest we
keep this part of the design the way it is.
One way to perform the fencing for recovery and still keep the original design
as is with respect to ensemble changes is to wait for the writer to mark in the
ledger metadata such a change. Say that we externally detect that a bookie C
has crashed. If the writer of a given ledger L removes C from its configuration
and writes to ZooKeeper, then we can safely recover the ledger fragment of C
for L. If the writer of L never makes such a change, then we assume that the
writer can still talk to C, and consequently we don't care.
We can monitor ensemble changes by watching the node in ZooKeeper. Using
watches will make it difficult to implement an HBase backend for metadata as we
proposed in another jira.
> Bookie Recovery on an open ledger will cause LedgerHandle#close on that
> ledger to fail
> --------------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-112
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-112
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Flavio Junqueira
> Assignee: Sijie Guo
> Fix For: 4.1.0
>
> Attachments: BK-112.patch, BOOKKEEPER-112.patch,
> BOOKKEEPER-112.patch_v2, BOOKKEEPER-112.patch_v3, BOOKKEEPER-112.patch_v4,
> BOOKKEEPER-112.patch_v5
>
>
> Bookie recovery updates the ledger metadata in zookeeper. LedgerHandle will
> not get notified of this update, so it will try to write out its own ledger
> metadata, only to fail with KeeperException.BadVersion. This effectively
> fences all write operations on the LedgerHandle (close and addEntry). close
> will fail for obvious reasons. addEntry will fail once it gets to the failed
> bookie in the schedule, tries to write, fails, selects a new bookie and tries
> to update ledger metadata.
> Update Line 605, testSyncBookieRecoveryToRandomBookiesCheckForDupes(), when
> done
> Also, uncomment addEntry in
> TestFencing#testFencingInteractionWithBookieRecovery()
--
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
