Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> 0.92/0.94 compatibility and HBASE-5206


Copy link to this message
-
0.92/0.94 compatibility and HBASE-5206
There has been some discussion on the JIRA lately about what to do about a
0.92/0.94 compatibility issue.  I wanted to bring this up to a larger
audience in order to solicit additional opinions.

HBASE-5206 (https://issues.apache.org/jira/browse/HBASE-5206), which is in
0.94.0 and 0.94.1, breaks compatibility with 0.92.0 and 0.92.1.  The issue
is described in the release notes for HBASE-5155 (of which HBASE-5206 is a
forward port).  Excerpted here:

  This issue is an incompatible change.
  If an HBase client with the changes for HBASE-5155 and a server (master)
without the changes for HBASE-5155 is used, then the is_enabled (from HBase
Shell) or isTableEnabled() (from HBaseAdmin) will return false though the
table is already enabled as per the master.

  If the HBase client does have the changes for HBASE-5155 and the server
does not have the changes for HBASE-5155, then if we try to Enable a table
then the client will hang.

  The reason is because,
  Prior to HBASE-5155 once the table is enabled the znode in the zookeeper
created for the table is deleted.
  After HBASE-5155 once the table is enabled the znode in the zookeeper
created for the table is not deleted, whereas the same node is updated with
the status ENABLED.

  The client also expects the status of the znode in the zookeeper to be in
the ENABLED state if the table has been enabled successfully.
  The above changes makes the client behaviour incompatible if the client
does not have this fix whereas the server has this fix.
  If both the client and the server does not have this fix, then the
behaviour is as expected.

So we have a situation where 0.92.0 and 0.92.1 clients are not compatible
with 0.94.0 and 0.94.1 servers and visa-versa.

The issue is, what should we do about the 0.94.2 server?  As far as I can
tell, we cannot make both {0.92.0,0.92.1} and {0.94.0,0.94.1} clients
happy.  I propose we make the 0.94.2 server compatible with the {0.92.0,
0.92.1} client set.  My thinking is that we should optimize for the most
common use case.  Given that both CDH4 and HDP 1.0 ship 0.92.1, and that
0.94 is relatively new, it seems more likely that users will upgrade
servers from 0.92.1 to 0.94.2+ than from an earlier 0.94 version.  I think
we can do this while actually fixing the issue that HBASE-5206 purports to
fix by moving the ENABLED state to a different znode.  I'll even volunteer
to do that :).  I don't think there is an obvious or easy answer here, so
wanted to get other's opinions.

As for the client, HBASE-6268 (
https://issues.apache.org/jira/browse/HBASE-6268) was introduced in 0.92.2
to handle both cases of servers ({0.92.0,0.92.1} and {0.94.0,0.94.1}) by
accepting both possibilities for the table znode.  I think that approach
works whether we leave the server as is or go with what I've proposed --
but we should test.

Greg
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB