[
https://issues.apache.org/jira/browse/HBASE-19997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379872#comment-16379872
]
stack commented on HBASE-19997:
-------------------------------
Actual startup of hbase2 master goes pretty well until it tries to migrate
table state from zk to hbase:meta table; the 0.98 hbase:meta schema does not
include a 'table' columnfamily (table state is kept in zk in 0.98). hbase:meta
is not editable and is always 'enabled' so can't be disabled and altered to add
the column family (see schemas below). Need to figure some trick in here
editing hbase:meta and then moving it so new schema is picked up instead...
The above NPE comes of some destroyed state that comes of starting up the
hbase2 master; it does not happen on the first startup. Need to figure what it
is. Linked a doc on thoughts so far on rolling upgrade.
hbase0.98 hbase:meta schema
{code}
hbase(main):001:0> describe 'hbase:meta'
Table hbase:meta is ENABLED
hbase:meta, {TABLE_ATTRIBUTES => {IS_META => 'true', coprocessor$1 =>
'|org.apache.hadoop.hbase.coprocessor.MultiRowMutationEndpoint|536870911|'}
COLUMN FAMILIES DESCRIPTION
{NAME => 'info', BLOOMFILTER => 'NONE', VERSIONS => '10', IN_MEMORY => 'true',
KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER',
COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true', BLOCKSIZE =>
'8192', REPLICATION_SCOPE => '0'}
1 row(s) in 0.9800 seconds
{code}
hbase2 hbase:meta schema
{code}
hbase(main):004:0> describe 'hbase:meta'
Table hbase:meta is ENABLED
hbase:meta, {TABLE_ATTRIBUTES => {IS_META => 'true', REGION_REPLICATION => '1',
coprocessor$1 =>
'|org.apache.hadoop.hbase.coprocessor.MultiRowMutationEndpoint|536870911|'}
COLUMN FAMILIES DESCRIPTION
{NAME => 'info', VERSIONS => '3', EVICT_BLOCKS_ON_CLOSE => 'false',
NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE',
CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL =>
'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER =>
'NONE', CAC
HE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'true', CACHE_BLOOMS_ON_WRITE =>
'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE
=> 'true', BLOCKSIZE => '8192'}
{NAME => 'table', VERSIONS => '3', EVICT_BLOCKS_ON_CLOSE => 'false',
NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE',
CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL =>
'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER =>
'NONE', CA
CHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'true', CACHE_BLOOMS_ON_WRITE =>
'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE
=> 'true', BLOCKSIZE => '8192'}
2 row(s)
Took 0.1196 seconds
{code}
> [rolling upgrade] 1.x => 2.x
> ----------------------------
>
> Key: HBASE-19997
> URL: https://issues.apache.org/jira/browse/HBASE-19997
> Project: HBase
> Issue Type: Umbrella
> Reporter: stack
> Priority: Major
> Fix For: 2.0.0-beta-2
>
>
> An umbrella issue of issues needed so folks can do a rolling upgrade from
> hbase-1.x to hbase-2.x.
> (Recent) Notables:
> * hbase-1.x can't read hbase-2.x WALs -- hbase-1.x doesn't know the
> AsyncProtobufLogWriter class used writing the WAL -- see
> https://issues.apache.org/jira/browse/HBASE-19166?focusedCommentId=16362897&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16362897
> for exception.
> ** Might be ok... means WAL split fails on an hbase1 RS... must wait till an
> hbase-2.x RS picks up the WAL for it to be split.
> * hbase-1 can't open regions from tables created by hbase-2; it can't find
> the Table descriptor. See
> https://issues.apache.org/jira/browse/HBASE-19116?focusedCommentId=16363276&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16363276
> ** This might be ok if the tables we are doing rolling upgrade over were
> written with hbase-1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
