You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Michael Stack (Jira)" <ji...@apache.org> on 2019/11/21 22:12:00 UTC
[jira] [Updated] (HBASE-23328) info:regioninfo goes wrong when
region replicas enabled
[ https://issues.apache.org/jira/browse/HBASE-23328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Stack updated HBASE-23328:
----------------------------------
Description:
Noticed that the info:regioninfo content in hbase:meta can become that of a serialized replica. I think it mostly harmless but accounting especially debugging is frustrated because hbase:meta row name does not match the info:regioninfo.
Here is an example:
{code}
t1,c6e977ef,1572669121340.0b455b2d57f91c153d5088533205c268. column=info:regioninfo, timestamp=1574367093772, value={ENCODED => 5199f7826c340ba944517e97c6ebaf04, NAME => 't1,c6e977ef,1572669121340_0001.5199f7826c340ba944517e97c6ebaf04.', STARTKEY => 'c6e977ef', ENDKEY => 'c72b0126', REPLICA_ID => 1}
{code}
Notice how hbase:meta row name is like that of the info:regioninfo content only we are listing REPLICA_ID content and the encoded name is different (as it factors replicaid).
The original Region Replica design describes how the info:regioninfo is supposed to have the default HRI serialized only. See comment on HRI changes in https://issues.apache.org/jira/secure/attachment/12627276/hbase-10347_redo_v8.patch
-Going back over history, this may have been a bug since Region Replicas came in.- <= No. Looking at an old cluster w/ region replicas, it doesn't have this issue.
was:
Noticed that the info:regioninfo content in hbase:meta can become that of a serialized replica. I think it mostly harmless but accounting especially debugging is frustrated because hbase:meta row name does not match the info:regioninfo.
Here is an example:
{code}
t1,c6e977ef,1572669121340.0b455b2d57f91c153d5088533205c268. column=info:regioninfo, timestamp=1574367093772, value={ENCODED => 5199f7826c340ba944517e97c6ebaf04, NAME => 't1,c6e977ef,1572669121340_0001.5199f7826c340ba944517e97c6ebaf04.', STARTKEY => 'c6e977ef', ENDKEY => 'c72b0126', REPLICA_ID => 1}
{code}
Notice how hbase:meta row name is like that of the info:regioninfo content only we are listing REPLICA_ID content and the encoded name is different (as it factors replicaid).
The original Region Replica design describes how the info:regioninfo is supposed to have the default HRI serialized only. See comment on HRI changes in https://issues.apache.org/jira/secure/attachment/12627276/hbase-10347_redo_v8.patch
Going back over history, this may have been a bug since Region Replicas came in.
> info:regioninfo goes wrong when region replicas enabled
> -------------------------------------------------------
>
> Key: HBASE-23328
> URL: https://issues.apache.org/jira/browse/HBASE-23328
> Project: HBase
> Issue Type: Bug
> Components: read replicas
> Reporter: Michael Stack
> Assignee: Michael Stack
> Priority: Major
>
> Noticed that the info:regioninfo content in hbase:meta can become that of a serialized replica. I think it mostly harmless but accounting especially debugging is frustrated because hbase:meta row name does not match the info:regioninfo.
> Here is an example:
> {code}
> t1,c6e977ef,1572669121340.0b455b2d57f91c153d5088533205c268. column=info:regioninfo, timestamp=1574367093772, value={ENCODED => 5199f7826c340ba944517e97c6ebaf04, NAME => 't1,c6e977ef,1572669121340_0001.5199f7826c340ba944517e97c6ebaf04.', STARTKEY => 'c6e977ef', ENDKEY => 'c72b0126', REPLICA_ID => 1}
> {code}
> Notice how hbase:meta row name is like that of the info:regioninfo content only we are listing REPLICA_ID content and the encoded name is different (as it factors replicaid).
> The original Region Replica design describes how the info:regioninfo is supposed to have the default HRI serialized only. See comment on HRI changes in https://issues.apache.org/jira/secure/attachment/12627276/hbase-10347_redo_v8.patch
> -Going back over history, this may have been a bug since Region Replicas came in.- <= No. Looking at an old cluster w/ region replicas, it doesn't have this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)