[
https://issues.apache.org/jira/browse/HBASE-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204346#comment-13204346
]
Jonathan Gray commented on HBASE-3171:
--------------------------------------
Thanks for taking a look. Need to think about backward compatibility more.
Might need to hold off until some future big client/server change?
Were you think that meta locations would be in both the META region(s) as well
as up in ZK? Or just in ZK? If it was in both, then should be easier to
provide backwards compatibility.
Which would be source of truth and which would be relied upon for persistence?
I suppose all the data in meta is recoverable from the regions themselves (or
should be) between restarts so we wouldn't have a hard requirement on zk
persistence between restarts. Doing the meta edits in zk might help suss out
some of those trickier race conditions around region movement, splitting, meta
updating, and crashing.
Was also thinking we should revisit the idea of more intelligent redirecting of
clients along with NSREs while looking at this stuff.
> 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
