[
https://issues.apache.org/jira/browse/BOOKKEEPER-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233425#comment-13233425
]
Sijie Guo commented on BOOKKEEPER-126:
--------------------------------------
yup. scanner is a possible way to handle under-replicated blocks. following
just some thoughts from mine.
an entry might be placed multiple times in different entry log files, due to
journal replaying. the only referred entry position is recorded in ledger
index, so scanner may scan ledger by ledger. the place to run the scanner, I
guess, it would be better in GarbageCollectorThread, after gc actions (those gc
ledgers we don't need to care).
when scanning a ledger, bookie server should know what entries it should own.
which means, bookie server needs the distribution info of a ledger. maybe we
can record what DistributionSchedule a ledger used in ledger metadata.
for inter-bookie communication, why not consider using PerChannelBookieClient?
And it may be better to add a batch read op for performance consideration.
another tough thing is we need to tell closed ledger from opened/in-recovery
ledger, when handling last ensemble of opened/in-recovery ledger.
> EntryLogger doesn't detect when one of it's logfiles is corrupt
> ---------------------------------------------------------------
>
> Key: BOOKKEEPER-126
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-126
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Ivan Kelly
> Priority: Blocker
> Fix For: 4.1.0
>
>
> If an entry log is corrupt, the bookie will ignore any entries past the
> corruption. Quorum writes stops this being a problem at the moment, but we
> should detect corruptions like this and rereplicate if necessary.
--
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
