hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry He <jerry...@gmail.com>
Subject Re: [DISCUSS] hbase-2.0.0 compatibility expectations
Date Mon, 30 Oct 2017 18:46:42 GMT
Hi, Stack

Coming back to this thread, i have meant to ask this question long ago.
Do we support hbase-2 client going against hbase-1 server?
We seem to be fine mix-and-match the clients and servers within the
hbase-1 releases.   And IIRC hbase-1 client is ok against 0.98 server.
Suppose I have a product  that depends and bundles HBase client. I
want to upgrade the dependency to hbase-2 so that it can take
advantages of and claim support of hbase-2.
But does it mean that I will need drop the claims that the new version
of the product support any hbase-1 backend?


On Tue, Sep 12, 2017 at 10:21 AM, Stack <stack@duboce.net> wrote:
> Let me put this one on this thread, G1GC on by default in hbase2?
> St.Ack
> On Wed, Aug 2, 2017 at 4:38 PM, Stack <stack@duboce.net> wrote:
>> What are our expectations regards compatibility between hbase1 and hbase2?
>> Lets have a chat about it. Here are some goal posts.
>> + You have to upgrade to hbase-1.x before you can migrate to hbase-2. No
>> migration from < hbase-1 (Is this too onerous? Should we support 0.98 =>
>> 2.0?).
>> + You do NOT have to upgrade to the latest release of hbase1 to migrate to
>> hbase2; being up on hbase-1.0.0+ will be sufficient.
>> + You'll have to update your hbase1 coprocessors to deploy them on hbase2.
>> A bunch of CP API has/will change by the time hbase2 comes out; e.g.
>> watching for region split on RegionServer no longer makes sense given
>> Master runs all splits now.
>> + An hbase1 client can run against an hbase2 cluster but it will only be
>> able to do DML (Get/Put/Scan, etc.). We do not allow being able to do admin
>> ops using an hbase1 Admin client against an hbase2 cluster. We have some
>> egregious API violations in branch-1; e.g. we have protobuf in our API (See
>> HBASE-15607). The notion is that we can't afford a deprecation cycle
>> purging this stuff from our Admin API.
>> What you all think?
>> St.Ack

View raw message