stack updated HBASE-16060:
    Release Note: 
By default, we mirror table state to zookeeper so hbase-1.x clients will work 
against an hbase-2 cluster (With this patch, hbase-1.x clients can do most 
Admin functions including table create; hbase-1.x clients can do all Table/DML 
against hbase-2 cluster).

Flag to disable mirroring is hbase.mirror.table.state.to.zookeeper; set it to 
false in Configuration.

Related, Master on startup will look to see if there are table state znodes 
left over by an hbase-1 instance. If any found, it will migrate the table state 
to hbase-2 setting the state into the hbase:meta table where table state is now 
kept. We will do this check on every Master start. Notion is that this will be 
overall beneficial with low impediment. To disable the migration check, set 
hbase.migrate.table.state.from.zookeeper to false.
          Status: Patch Available  (was: Open)

> 1.x clients cannot access table state talking to 2.0 cluster
> ------------------------------------------------------------
>                 Key: HBASE-16060
>                 URL: https://issues.apache.org/jira/browse/HBASE-16060
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: stack
>            Priority: Blocker
>             Fix For: 2.0.0-beta-2
>         Attachments: 
> 0002-HBASE-16060-1.x-clients-cannot-access-table-state-ta.patch, 
> HBASE-16060.branch-2.001.patch, HBASE-16060.branch-2.002.patch
> Since table state is migrated to meta instead of zk in 2.0, 1.x clients 
> talking to 2.0 cluster cannot access the table state. This causes some weird 
> behavior since from a client perspective, {{Admin.isTableEnabled()}} and 
> {{Admin.isTableDisabled()}} both return false. 
> One option we can do is to add code in 1.x clients so that they can access 
> the table state in meta if needed. Otherwise, we can mirror the table state 
> in zk (while keeping meta as the source of truth) during 2.x lifecycle so 
> that any 1.x client can still work correctly. 

This message was sent by Atlassian JIRA

Reply via email to