[ 
https://issues.apache.org/jira/browse/HBASE-25761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17319641#comment-17319641
 ] 

Michael Stack commented on HBASE-25761:
---------------------------------------

bq. If we fully follow the bigtable way, then we need to split the meta region 
first to separate the special 'ROOT' region, it will break the old client...

I was thinking that you didn't have to do this; that if meta split is disabled, 
we just carry-on as we do now with a single hbase:meta,,1 Region (old clients 
would continue to work -- no need of a proxy).

bq. In SCP and other places we still need to treat the first meta region 
specially, which is the same with introducing an extra ROOT region, but the 
code will be more confusing...

Yeah, we'd give this Region precedence. It would be named hbase:meta,,1 rather 
than ROOT,,1 but otherwise, the special handling will be there.

In the BT table, they are trying to avoid adding in an extra tier of assign 
which is a concern of ours. Let me play around w/ the idea. Will bring what I 
find back to the design doc.

> POC: hbase:meta,,1 as ROOT
> --------------------------
>
>                 Key: HBASE-25761
>                 URL: https://issues.apache.org/jira/browse/HBASE-25761
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Michael Stack
>            Priority: Major
>
> One of the proposals up in the split-meta design doc suggests a 
> sleight-of-hand where the current hard-coded hbase:meta,,1 Region is 
> leveraged to serve as first Region of a split hbase:meta but also does 
> double-duty as 'ROOT'. This suggestion was put aside as a complicating 
> recursion in chat but then Francis noticed on a re-read of the BigTable 
> paper, that this is how they describe they do 'ROOT': "The root tablet is 
> just the first tablet in the METADATA table, but is treated specially -- it 
> is never split..."
> This issue is for playing around with this notion to see what the problems 
> are so can do a better description of this approach here, in the design:
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.ikbhxlcthjle



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to