[
https://issues.apache.org/jira/browse/HBASE-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025038#comment-13025038
]
stack commented on HBASE-3675:
------------------------------
@Prakash We could do that. Same w/ being liberal about ignoring errors in last
file.
This is a kind of tough one in that on the one hand, the first time this option
comes up is when folks are trying to get their cluster back online and they
can't because it won't process the logs. In this context, they are usually a
bit pissed off. On the other hand, we don't want data loss.
I suppose we need to doc this as one of the important configs. over in our
website book. We also need to make this flag work properly as part of this
issue.
> hbase.hlog.split.skip.errors is false by default but we don't act properly
> when its true; can make for inconsistent view
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-3675
> URL: https://issues.apache.org/jira/browse/HBASE-3675
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Priority: Critical
>
> So, by default hbase.hlog.split.skip.error is false so we should not be
> skipping errors (What should we do, abort?).
> Anyways, see https://issues.apache.org/jira/browse/HBASE-3674. It has
> checksum error on near to last log BUT it writes out recovered.edits gotten
> so far. We then go and assign the regions anyways, applying edits gotten so
> far, though there are edits behind the checksum error still to be recovered.
> Not good.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
