[
https://issues.apache.org/jira/browse/HBASE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835618#action_12835618
]
stack commented on HBASE-2235:
------------------------------
@Kannan The report of split is not atomic; we are sending 3 separate puts. We
don't have means of making a cross-row transaction out of this operation. And
then there is the message to the master. The message to the master used to be
done as three messages but in head of branch it was collapsed into one. We
need to improve upon the above. Using something like the Todd-suggested
receipe, we'd write first to our WAL all details on the split (parent and
daughters). If we died in the middle of update of .META. or report to master,
the replay of the log on open of the region post-crash in the new location
would find the split recording and check .META. that split made it in doing
fixup if split is not all present (If the split was incompletely recorded in
the log, clean up the failed split and retry it).
> Mechanism that would not have -ROOT- and .META. on same server caused failed
> assign of .META.
> ---------------------------------------------------------------------------------------------
>
> Key: HBASE-2235
> URL: https://issues.apache.org/jira/browse/HBASE-2235
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: stack
> Fix For: 0.20.4, 0.21.0
>
>
> Here is the short story:
> Scenario is a cluster of 3 servers. Server 1. crashed. It was carrying the
> .META. We split the logs. .META. is put on the head of the assignment
> queue. Server 2. happens to be in a state where it wants to report a split.
> The master fails the report because there is no .META. (It fails it ugly with
> a NPE). Server 3. checks in and falls into the assignment code
> (RegionManager#regionsAwaitingAssignment). In here we have this bit of code
> around line #412:
> {code}
> if (reassigningMetas && isMetaOrRoot && !isSingleServer) {
> return regionsToAssign; // dont assign anything to this server.
> }
> {code}
> Because we think this not a single server cluster -- we think there are two
> 'live' nodes -- we won't assign meta.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
