[
https://issues.apache.org/jira/browse/HBASE-13087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345430#comment-14345430
]
Andrey Stepachev commented on HBASE-13087:
------------------------------------------
[~eclark] I understand your concern for meta. but keep in mind, that meta is
only special table which is handled separately. During first implementation (in
table descriptors) I thought about introducing special table for tables or
state or whatever, but I dropped that idea. It complicates table state
management, because we need to keep two tables online to do most operations, so
we can't start recovering until we are onlined meta _and_ our new table. That
will definitely introduce more methods named like assignMeta which is
definitely bad.
With introduction of meta replicas we can go further and prohibit requests to
primary replica and always try secondary for state requests first.
But in general I agree that may be this change is too early for branch-1.
[~stack] As for steps for fixing that, here are two problems at once:
1. we need(?) to be compatible with 0.98 clients, which use zk for table
states. That can be solved by optionally duplicating states in readonly mode to
zk (actually nobody doing writes there, so basically it will not hurt clients,
they just can be a bit lagged)
2. we faced with no sharing of knowledge of compatibility between master and
regions. We can solve that in two ways:
- hackery way, adding 'mark' coprocessor to ServerLoad report, say
'compatCoprocessor:haveMeta,disabledZk,whateverWeHave' and find out which
region servers will be capable to handle new meta (i.e thay were upgraded)
- send/request additional information once on registration or later by
additional RPC which allows to query (that definitely need to be with new jira):
a) any config values if needed (say ask do regions server thinks zk
assigment enabled?)
b) list of compatibilities in strict enum-like list (meta, branch-1,
release, amInZk...) and master can make conscious decisions on what is going on.
just my 5 cents.
> branch-1 isn't rolling upgradable from 0.98
> -------------------------------------------
>
> Key: HBASE-13087
> URL: https://issues.apache.org/jira/browse/HBASE-13087
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.1.0
> Reporter: Elliott Clark
> Assignee: Rajesh Nishtala
> Priority: Blocker
> Fix For: 1.1.0
>
> Attachments: HBASE-13087-v1.txt
>
>
> {code}org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException:
> Failed 1 action:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family table does not exist in region hbase:meta,,1.1588230740 in table
> 'hbase:meta', {TABLE_ATTRIBUTES => {IS_META => 'true', coprocessor$1 =>
> '|org.apache.hadoop.hbase.coprocessor.MultiRowMutationEndpoint|536870911|'},
> {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'}
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.doBatchOp(HRegionServer.java:4513)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.doNonAtomicRegionMutation(HRegionServer.java:3687)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:3576)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:30816)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2029)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> : 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1700(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1689)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:208)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:183)
> at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1404)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1017)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.put(MetaTableAccessor.java:1123)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.putToMetaTable(MetaTableAccessor.java:1113)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.updateTableState(MetaTableAccessor.java:1436)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.updateTableState(MetaTableAccessor.java:948)
> at
> org.apache.hadoop.hbase.master.TableStateManager.writeMetaState(TableStateManager.java:195)
> at
> org.apache.hadoop.hbase.master.TableStateManager.setTableState(TableStateManager.java:69)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.setEnabledTable(AssignmentManager.java:3427)
> at org.apache.hadoop.hbase.master.HMaster.assignMeta(HMaster.java:903)
> at
> org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:698)
> at org.apache.hadoop.hbase.master.HMaster.access$500(HMaster.java:166)
> at org.apache.hadoop.hbase.master.HMaster$1.run(HMaster.java:1494)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
