[
https://issues.apache.org/jira/browse/BOOKKEEPER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13442478#comment-13442478
]
Ivan Kelly commented on BOOKKEEPER-208:
---------------------------------------
Re: #5
You're right. There's a window where entries will continue to write to the old
bookie, even though we've added a new bookie to the ensemble. I think
BOOKKEEPER-337 will handle some of it, but really we need to block all
completions of add operations once we've taken the decision to replace a
bookie. More specifically, once we take the lastAddConfirmed + 1 to set the
start entry of the segment, no entry after that can be confirmed to the client
until the bookie has been replaced in the ensemble.
> Separate write quorum from ack quorum
> -------------------------------------
>
> Key: BOOKKEEPER-208
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-208
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client
> Reporter: Flavio Junqueira
> Assignee: Ivan Kelly
> Fix For: 4.2.0
>
> Attachments: BOOKKEEPER-208.diff, BOOKKEEPER-208.diff,
> BOOKKEEPER-208.diff, BOOKKEEPER-208.diff
>
>
> There are use cases for bookkeeper that may require submitting add requests
> to a write set and returning upon receiving a confirmation from an ack set.
> The ack set must be a subset of the write set. An important special case is
> writing to all and returning upon hearing from a majority. Another important
> use case is avoiding *s* slow disks by writing to *f + s + 1* and returning
> upon receiving *f + 1* responses.
> Currently, the write set and the ack set are the same for a ledger. Internal
> changes to support these cases include changes to LedgerHandle and
> PendingAddOp. We also need to add a call to the client API to accept
> different sizes for the write set and the ack set upon ledger creation.
> It is also open for the discussion the need to implement a new distribution
> schedule. So far it looks like we can reuse the round robin implementation we
> currently have. We would need to implement a new one if, for example, the
> initial bookie of an add operation must be always the same.
--
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
