[
https://issues.apache.org/jira/browse/HBASE-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204307#comment-13204307
]
stack commented on HBASE-3171:
------------------------------
I took a look at what is involved here. I first started out just hacking
-ROOT- out of hbase completely. It was fun while it lasted (The root location
in zk would instead become the meta location w/ a watcher, etc.). On my bike
ride home I figured it'd be better if I could make it so old clients looking
for a -ROOT- no longer there would still sort of work. I dug around but was
unable to figure a way of making this work, not w/o leaving a -ROOT-
placeholder in place and then adding interception code that would take a
different route if we were "scanning" the now non-existent to find the meta
location now up in zk rather than in a root table; in other words, adding more,
cryptic code. It looked to get ugly fast too.
So, I see no way of doing this w/o breaking backward compatibility. Old code
would go looking for a non-existent -ROOT- region. Do we want to do this?
> Drop ROOT and instead store META location(s) directly in ZooKeeper
> ------------------------------------------------------------------
>
> Key: HBASE-3171
> URL: https://issues.apache.org/jira/browse/HBASE-3171
> Project: HBase
> Issue Type: Improvement
> Components: client, master, regionserver, zookeeper
> Reporter: Jonathan Gray
>
> Rather than storing the ROOT region location in ZooKeeper, going to ROOT, and
> reading the META location, we should just store the META location directly in
> ZooKeeper.
> The purpose of the root region from the bigtable paper was to support
> multiple meta regions. Currently, we explicitly only support a single meta
> region, so the translation from our current code of a single root location to
> a single meta location will be very simple. Long-term, it seems reasonable
> that we could store several meta region locations in ZK. There's been some
> discussion in HBASE-1755 about actually moving META into ZK, but I think this
> jira is a good step towards taking some of the complexity out of how we have
> to deal with catalog tables everywhere.
> As-is, a new client already requires ZK to get the root location, so this
> would not change those requirements in any way.
> The primary motivation for this is to simplify things like CatalogTracker.
> The way we can handle root in that class is really simple but the tracking of
> meta is difficulty and a bit hacky. This hack on tracking of the meta
> location is what caused one of the bugs over in HBASE-3159.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
