[
https://issues.apache.org/jira/browse/HBASE-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106947#comment-13106947
]
stack commented on HBASE-4282:
------------------------------
What we going to do here?
bq. We could easily flag this state and only ride over the close error if there
aren't unflushed entries.
This sounds good (with the aborting regionserver). If DEFERRED_LOG_FLUSH and a
few edits missing after the abort, then that should be no surprise.
bq. ...unflushed WALEdit entries for that table in the current SequenceFile
writer buffer
Unsure what to do here. At a minimum we should doc in hbase-default.xml for
hbase.regionserver.logroll.errors.tolerated the above. Maybe tolerated being
on by default is a mistake (I know I was the one who suggested we do it but
having second thoughts)?
> Potential data loss in retries of WAL close introduced in HBASE-4222
> --------------------------------------------------------------------
>
> Key: HBASE-4282
> URL: https://issues.apache.org/jira/browse/HBASE-4282
> Project: HBase
> Issue Type: Bug
> Reporter: Gary Helmling
> Assignee: Gary Helmling
> Priority: Blocker
> Fix For: 0.92.0, 0.90.5
>
>
> The ability to ride over WAL close errors on log rolling added in HBASE-4222
> could lead to missing HLog entries if:
> * A table has DEFERRED_LOG_FLUSH=true
> * There are unflushed WALEdit entries for that table in the current
> SequenceFile writer buffer
> Since the writes were already acknowledged to the client, just ignoring the
> close error to allow for another log roll doesn't seem like the right thing
> to do here.
> We could easily flag this state and only ride over the close error if there
> aren't unflushed entries. This would bring the above condition back to the
> previous behavior of aborting the region server. However, aborting the
> region server in this state is still guaranteeing data loss. Is there
> anything we can do better in this case?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
