[ 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