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

Francis Christopher Liu commented on HBASE-25761:
-------------------------------------------------

I see, thanks for clarifying. I think I do understand, I just don't think it 
would go down the route of dying for reasons mention earlier: possibly enabling 
it by default in all or subset of tests, removing the compatibility switch and 
then there's adoption. In general I think the death of a feature is because of 
a mix of lack of support and adoption. Since we are guaranteeing rolling 
upgradeabbility from 2.x it is something that I think all implementations would 
run into, perhaps maybe a little more for single meta region than the others 
but arguably inconsequential from this perspective (eg the code for multiple 
meta is not exercised). 

Perhaps this is something we can discuss further in a video call sync-up with 
[~stack] and hopefully a bunch of other folks that are interested? I think we 
should have a sync-up discussion for split meta in general anyway.

> 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
>            Assignee: Francis Christopher Liu
>            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