[
https://issues.apache.org/jira/browse/HBASE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835615#action_12835615
]
stack commented on HBASE-2235:
------------------------------
@Kannan
See CompactSplitThread#split. See how we do a few puts to the .META. table:
One to disable parent split, and one each to add new daughter regions. We then
add to the queue of messages to send the server a 'split' message. These gets
sent on the next heartbeat over to the master 'informing' it of the split so it
will go about assigning the new daughters (IIRC, if this message never made it
across, the periodic scan of .META. would notice the new unassigned daughters
and add them to the to-be-assigned list).
Let me know if you need more.
> 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.
