[
https://issues.apache.org/jira/browse/HBASE-25761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370837#comment-17370837
]
Michael Stack commented on HBASE-25761:
---------------------------------------
I took a look at the one-pager [~toffer] . Suggest you integrate it into the
[https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit#heading=h.hdf0rnyevxz2]
design doc replacing the content of the current 4.1.1. section which is just
an outline of what your one-pager fills out (You can have your last paragraph
as 'Downside').
It is appealing that old clients will just continue to work if no split
(Requirement 2.0.4 and 2.0.5 rolling upgrade should be easier too). The 'first
meta region' conditional clauses are a little awkward but seems easier than
back-filling ROOT (again). The PoC seems fine... a bunch of if/thens w/ the
ugly comparator story but I think this not a particular of this approach – any
impl will have some version of this (I think).
[~zhangduo] Do you want to write up your re-intro of root table showing how it
would remain compatible – '...just need to copy location to zookeeper...'. How
would the old clients work and would it violate requirement 2.0.3?
Agree that if split meta is not on by default, it means it will not get
exercised and there is the danger that it could then stall as a feature and
become dead code.... but the path outlined above where it is off until the
cluster is migrated to splittable-meta and then later, splitting is enabled as
default makes sense to me.
Shall we do an online meeting to discuss? This week? Usual time? Can talk
about this approach and others to consider. Would be good to call an approach
so could get basics into 3.0.0.
> 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)
