[
https://issues.apache.org/jira/browse/HBASE-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-869.
-------------------------
Resolution: Duplicate
Its fixed by HBASE-2461, which will roll back reopening parent if fault. If
the parent edit goes in, then the fixup in basescanner would have taken it from
there. So fixed in current TRUNK. Resolving (We'll need to come up w/ a
replacement for basescanner fixup when new master goes in and no basescanner).
Marking duplicate.
> On split, if failure updating of .META., table subsequently broke
> -----------------------------------------------------------------
>
> Key: HBASE-869
> URL: https://issues.apache.org/jira/browse/HBASE-869
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Assignee: stack
> Fix For: 0.90.0
>
>
> On pset cluster -- running 0.2.0 -- I saw the following:
> + Deadlock on server carrying .META. made the .META. table inaccessible
> (deadlock has been fixed)
> + Out on a regionserver, we split; two new daughters are created and parent
> region is closed.
> + Regionserver fails to update the .META. with change in parent state and
> addition of two new daughter regions
> Restarting the server carrying .META. got us over the deadlock but
> subsequently, the parent region is no longer online nor its replacements.
> Attempting restart of regionserver to see if parent will come back on line
> (since it was not 'offlined' in .META. should come back on line again and
> resplit). Ugly will be the fact that the filesystem has some trash in it --
> the new daughter regions.
> To consider: Do not close the parent until the .META. has been successfully
> updated. Also, if .META. update fails, remove daughter regions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
