[
https://issues.apache.org/jira/browse/HBASE-30149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101229#comment-18101229
]
mazhengxuan edited comment on HBASE-30149 at 8/3/26 6:55 AM:
-------------------------------------------------------------
Hi, I would like to work on HBASE-30149 if nobody else is already working on it.
I believe the root cause is in MetaCellComparator.compareRows. After comparing
the middle part of a meta row, the code checks leftDelimiter/rightDelimiter,
while it should check leftFarDelimiter/rightFarDelimiter. As a result, the
partial scan boundary "test," is incorrectly ordered after the complete
firstregion row "test,,<regionId>".
This also explains the PrefixFilter regression after HBASE-28621: its forward
seek hint is the prefix itself, so seeking to "test," skips the first region
under the incorrect meta ordering.
I propose fixing the delimiter checks and adding regression coverage for both a
range scan and PrefixFilter against hbase:meta.
Would this approach be acceptable? If so, could this issue be assigned to me?
was (Author: JIRAUSER298959):
Hi, I would like to work on HBASE-30149 if nobody else is already working on it.
I believe the root cause is in MetaCellComparator.compareRows. After comparing
the middle part of a meta row, the code checks leftDelimiter/rightDelimiter,
while it should check leftFarDelimiter/rightFarDelimiter. As a result, the
partial scan boundary "test," is incorrectly ordered after the complete
firstregion row "test,,<regionId>".
This also explains the PrefixFilter regression after HBASE-28621: its forward
seek hint is the prefix itself, so seeking to "test," skips the first region
under the incorrect meta ordering.
I propose fixing the delimiter checks and adding regression coverage for both a
range scan and PrefixFilter against hbase:meta.
Would this approach be acceptable? If so, could this issue be assigned to me?
> PrefixFilter and Range Scanning Bug for hbase::meta
> ---------------------------------------------------
>
> Key: HBASE-30149
> URL: https://issues.apache.org/jira/browse/HBASE-30149
> Project: HBase
> Issue Type: Bug
> Components: meta
> Affects Versions: 2.6.2, 2.6.4
> Reporter: Alexander Komyagin
> Priority: Minor
>
> Our database migration tool, [Dsync|https://github.com/adiom-data/dsync/],
> uses a query over hbase:meta to get all the regions for a table. We haven't
> had issues with Hbase 2.2 and 2.4, but while working with HBase 2.6.2 we
> noticed that queries on hbase:meta seem to be behaving weirdly:
> {code:java}
> // full scan starting with "test"; expecting to see two regions, and see both
> hbase:013:0> scan 'hbase:meta', {STARTROW => 'test', STOPROW => 'test.'}
> ROW COLUMN+CELL
> test column=table:state,
> timestamp=2026-05-07T17:11:01.333, value=\x08\x00
> test,,1778173914163.d8d8a3cdf6d466b32436d105524a3d3f column=info:regioninfo,
> timestamp=2026-05-07T17:11:55.625, value={ENCODED =>
> d8d8a3cdf6d466b32436d105524a3d3f, NAME =>
> 'test,,1778173914163.d8d8a3cdf6d466b3
> . 2436d105524a3d3f.',
> STARTKEY => '', ENDKEY => 'm'}
> test,,1778173914163.d8d8a3cdf6d466b32436d105524a3d3f
> column=info:seqnumDuringOpen, timestamp=2026-05-07T17:11:55.625,
> value=\x00\x00\x00\x00\x00\x00\x00\x0E
> .
> test,,1778173914163.d8d8a3cdf6d466b32436d105524a3d3f column=info:server,
> timestamp=2026-05-07T17:11:55.625,
> value=ip-172-31-3-98.us-west-1.compute.internal:16020
> .
> test,,1778173914163.d8d8a3cdf6d466b32436d105524a3d3f
> column=info:serverstartcode, timestamp=2026-05-07T17:11:55.625,
> value=1778166817935
> .
> test,,1778173914163.d8d8a3cdf6d466b32436d105524a3d3f column=info:sn,
> timestamp=2026-05-07T17:11:55.376,
> value=ip-172-31-3-98.us-west-1.compute.internal,16020,1778166817935
> .
> test,,1778173914163.d8d8a3cdf6d466b32436d105524a3d3f column=info:state,
> timestamp=2026-05-07T17:11:55.625, value=OPEN
> .
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd column=info:regioninfo,
> timestamp=2026-05-07T17:12:36.658, value={ENCODED =>
> 31c5b51c891bf4bc6254dbb281467dd9, NAME =>
> 'test,m,1778173914163.31c5b51c891bf4b
> 9. c6254dbb281467dd9.',
> STARTKEY => 'm', ENDKEY => ''}
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd
> column=info:seqnumDuringOpen, timestamp=2026-05-07T17:12:36.658,
> value=\x00\x00\x00\x00\x00\x00\x00\x12
> 9.
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd column=info:server,
> timestamp=2026-05-07T17:12:36.658,
> value=ip-172-31-3-159.us-west-1.compute.internal:16020
> 9.
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd
> column=info:serverstartcode, timestamp=2026-05-07T17:12:36.658,
> value=1778166817665
> 9.
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd column=info:sn,
> timestamp=2026-05-07T17:12:36.443,
> value=ip-172-31-3-159.us-west-1.compute.internal,16020,1778166817665
> 9.
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd column=info:state,
> timestamp=2026-05-07T17:12:36.658, value=OPEN
> 9.
> 3 row(s)
> Took 0.0223 seconds {code}
> {code:java}
> // full scan starting with "test,"; expecting to see two regions, BUT see
> just one
> hbase:007:0> scan 'hbase:meta', {STARTROW => 'test,', STOPROW => 'test.'} ROW
> COLUMN+CELL test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd
> column=info:regioninfo, timestamp=2026-05-07T17:12:36.658, value={ENCODED =>
> 31c5b51c891bf4bc6254dbb281467dd9, NAME =>
> 'test,m,1778173914163.31c5b51c891bf4b 9. c6254dbb281467dd9.', STARTKEY =>
> 'm', ENDKEY => ''} test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd
> column=info:seqnumDuringOpen, timestamp=2026-05-07T17:12:36.658,
> value=\x00\x00\x00\x00\x00\x00\x00\x12 9.
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd column=info:server,
> timestamp=2026-05-07T17:12:36.658,
> value=ip-172-31-3-159.us-west-1.compute.internal:16020 9.
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd
> column=info:serverstartcode, timestamp=2026-05-07T17:12:36.658,
> value=1778166817665 9. test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd
> column=info:sn, timestamp=2026-05-07T17:12:36.443,
> value=ip-172-31-3-159.us-west-1.compute.internal,16020,1778166817665 9.
> test,m,1778173914163.31c5b51c891bf4bc6254dbb281467dd column=info:state,
> timestamp=2026-05-07T17:12:36.658, value=OPEN 9. 1 row(s) Took 0.0179 seconds
> {code}
> When starting the scan with "test," or doing a prefixFilter on "test,",
> records with row key "test,,..." (corresponding to the first region) are
> reliably missing. This appears to be exclusive to the metadata table -
> regular tables behave as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
