[
https://issues.apache.org/jira/browse/HBASE-29021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ke Han updated HBASE-29021:
---------------------------
Description:
h1. Symptoms
After upgrading from HBase 2.5.10 to HBase 2.6.1, I observed an inconsistent
read across versions.
Before the upgrade, I created a table with one row. Invoking a count command
returns 1. After upgrading to 2.6.1, execute the same count command, it returns
0.
{code:java}
count 'uuid476430f7363d49d082405889a720a3c7'
Old Version Result:
1 row(s)
Took 0.5582 seconds
=> 1
New Version Result:
0 row(s)
Took 1.4439 seconds
=> 0 {code}
h1. Reproduce
It can be reproduced deterministically with the following steps
Step1: Start up the HBase cluster in 2.5.10 (1 HM, 1RS, 1 HDFS cluster) and
execute the following commands
{code:java}
create 'uuid476430f7363d49d082405889a720a3c7', {NAME =>
'uuid24f09c3c481640bf86306bb5719cf762', VERSIONS => 3, IN_MEMORY => 'true', TTL
=> 665620, CONFIGURATION => { 'hbase.store.file-tracker.impl' => 'FILE',
'hbase.acl.sync.to.hdfs.enable' => 'true' }}, {NAME =>
'uuid8f319a6fb75d43d38a2523064e302df0', VERSIONS => 3, COMPRESSION => 'NONE',
BLOOMFILTER => 'ROWCOL', IN_MEMORY => 'true', IS_MOB => false, MOB_THRESHOLD =>
1922878, MOB_COMPACT_PARTITION_POLICY => 'daily', CONFIGURATION => {
'CACHE_DATA_IN_L1' => 'true', 'hbase.store.file-tracker.impl' => 'FILE' }},
SPLIT_ENABLED => true, MERGE_ENABLED => true, SPLITALGO => 'HexStringSplit',
NUMREGIONS => 14, REGION_REPLICATION => 3
incr 'uuid476430f7363d49d082405889a720a3c7',
'uuid6f67db05e104412c82d6076d4d54792e',
'uuid8f319a6fb75d43d38a2523064e302df0:hregion2'{code}
Step2: Execute the count command in the old version
{code:java}
count 'uuid476430f7363d49d082405889a720a3c7'
1 row(s)
Took 0.5582 seconds
=> 1 {code}
Step3: Stop the entire cluster, upgrade to 2.6.1 cluster (full-stop upgrade)
and execute the same count command
{code:java}
count 'uuid476430f7363d49d082405889a720a3c7'
0 row(s)
Took 0.0842 seconds
=> 0{code}
h1. Analysis
Instead of upgrading to 2.6.1, I tried to restart the 2.5.10 cluster and the
result of the count command is still correct. This indicates that it could be
an incompatibility across 2 versions.
was:
h1. Symptoms
After upgrading from HBase 2.5.10 to HBase 2.6.1, I observed an inconsistent
read across versions.
Before the upgrade, I created a table with one row. Invoking a count command
returns 1. After upgrading to 2.6.1, execute the same count command, it returns
0.
{code:java}
count 'uuid476430f7363d49d082405889a720a3c7'
Old Version Result:
1 row(s)
Took 0.5582 seconds
=> 1
New Version Result:
0 row(s)
Took 1.4439 seconds
=> 0 {code}
h1. Reproduce
It can be reproduced deterministically
Start up the HBase cluster in 2.5.10 (1 HM, 1RS, 1 HDFS cluster) and execute
the following commands
{code:java}
create 'uuid476430f7363d49d082405889a720a3c7', {NAME =>
'uuid24f09c3c481640bf86306bb5719cf762', VERSIONS => 3, IN_MEMORY => 'true', TTL
=> 665620, CONFIGURATION => { 'hbase.store.file-tracker.impl' => 'FILE',
'hbase.acl.sync.to.hdfs.enable' => 'true' }}, {NAME =>
'uuid8f319a6fb75d43d38a2523064e302df0', VERSIONS => 3, COMPRESSION => 'NONE',
BLOOMFILTER => 'ROWCOL', IN_MEMORY => 'true', IS_MOB => false, MOB_THRESHOLD =>
1922878, MOB_COMPACT_PARTITION_POLICY => 'daily', CONFIGURATION => {
'CACHE_DATA_IN_L1' => 'true', 'hbase.store.file-tracker.impl' => 'FILE' }},
SPLIT_ENABLED => true, MERGE_ENABLED => true, SPLITALGO => 'HexStringSplit',
NUMREGIONS => 14, REGION_REPLICATION => 3
incr 'uuid476430f7363d49d082405889a720a3c7',
'uuid6f67db05e104412c82d6076d4d54792e',
'uuid8f319a6fb75d43d38a2523064e302df0:hregion2'{code}
Execute the count command in the old version
{code:java}
count 'uuid476430f7363d49d082405889a720a3c7'
1 row(s)
Took 0.5582 seconds
=> 1 {code}
Stop the entire cluster, upgrade to 2.6.1 cluster and execute the same count
command
{code:java}
count 'uuid476430f7363d49d082405889a720a3c7'
0 row(s)
Took 0.0842 seconds
=> 0{code}
h1. Analysis
Instead of upgrading to 2.6.1, I tried to restart the 2.5.10 cluster and the
result of the count command is still correct. This indicates that it could be
an incompatibility across 2 versions.
> Data loss after upgrade from 2.5.10 to 2.6.1
> --------------------------------------------
>
> Key: HBASE-29021
> URL: https://issues.apache.org/jira/browse/HBASE-29021
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.6.1, 2.5.10
> Reporter: Ke Han
> Priority: Major
>
> h1. Symptoms
> After upgrading from HBase 2.5.10 to HBase 2.6.1, I observed an inconsistent
> read across versions.
> Before the upgrade, I created a table with one row. Invoking a count command
> returns 1. After upgrading to 2.6.1, execute the same count command, it
> returns 0.
> {code:java}
> count 'uuid476430f7363d49d082405889a720a3c7'
> Old Version Result:
> 1 row(s)
> Took 0.5582 seconds
> => 1
> New Version Result:
> 0 row(s)
> Took 1.4439 seconds
> => 0 {code}
> h1. Reproduce
> It can be reproduced deterministically with the following steps
> Step1: Start up the HBase cluster in 2.5.10 (1 HM, 1RS, 1 HDFS cluster) and
> execute the following commands
> {code:java}
> create 'uuid476430f7363d49d082405889a720a3c7', {NAME =>
> 'uuid24f09c3c481640bf86306bb5719cf762', VERSIONS => 3, IN_MEMORY => 'true',
> TTL => 665620, CONFIGURATION => { 'hbase.store.file-tracker.impl' => 'FILE',
> 'hbase.acl.sync.to.hdfs.enable' => 'true' }}, {NAME =>
> 'uuid8f319a6fb75d43d38a2523064e302df0', VERSIONS => 3, COMPRESSION => 'NONE',
> BLOOMFILTER => 'ROWCOL', IN_MEMORY => 'true', IS_MOB => false, MOB_THRESHOLD
> => 1922878, MOB_COMPACT_PARTITION_POLICY => 'daily', CONFIGURATION => {
> 'CACHE_DATA_IN_L1' => 'true', 'hbase.store.file-tracker.impl' => 'FILE' }},
> SPLIT_ENABLED => true, MERGE_ENABLED => true, SPLITALGO => 'HexStringSplit',
> NUMREGIONS => 14, REGION_REPLICATION => 3
> incr 'uuid476430f7363d49d082405889a720a3c7',
> 'uuid6f67db05e104412c82d6076d4d54792e',
> 'uuid8f319a6fb75d43d38a2523064e302df0:hregion2'{code}
> Step2: Execute the count command in the old version
> {code:java}
> count 'uuid476430f7363d49d082405889a720a3c7'
> 1 row(s)
> Took 0.5582 seconds
> => 1 {code}
> Step3: Stop the entire cluster, upgrade to 2.6.1 cluster (full-stop upgrade)
> and execute the same count command
> {code:java}
> count 'uuid476430f7363d49d082405889a720a3c7'
> 0 row(s)
> Took 0.0842 seconds
> => 0{code}
> h1. Analysis
> Instead of upgrading to 2.6.1, I tried to restart the 2.5.10 cluster and the
> result of the count command is still correct. This indicates that it could be
> an incompatibility across 2 versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
