[
https://issues.apache.org/jira/browse/HBASE-26996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890240#comment-17890240
]
Hernan Gelaf-Romer commented on HBASE-26996:
--------------------------------------------
I think there's a scenario in which this bug is indeed harmful. When a region
is flushed, we check to see whether the region split request can be created. If
it can't, it will be compacted. In the case where the start key == new split
point, we run into a situation where a region will never split, or compact its
storefiles. This can result in HBase running into the blocking storefile limit
due to the buildup of storefiles on a single region.
> SteppingSplitPolicy and RegionSplitRestriction can result in illegal split
> noise
> --------------------------------------------------------------------------------
>
> Key: HBASE-26996
> URL: https://issues.apache.org/jira/browse/HBASE-26996
> Project: HBase
> Issue Type: Bug
> Reporter: Bryan Beaudreault
> Priority: Minor
>
> I set this to minor because I don't think it causes any real harm aside from
> log noise. But we should probably fix it up.
> Create a table with splits 0, 1, 2, 3, 4, 5. Then set
> {{hbase.regionserver.region.split_restriction.type}} to {{KeyPrefix}} and
> {{hbase.regionserver.region.split_restriction.prefix_length}} to 1.
> If you do enough writes to these regions, the SteppingSplitPolicy will try to
> split them. So it will try to split, for example, 1 in half. This is possible
> without KeyPrefix restriction, but with the restriction the split point will
> be truncated to value 1. The split will be submitted to the master with
> splitRow = 1 and that will fail because "Split row is equal to start key: 1"
> Setting up splits in this way, with the restriction, is useful for when
> you're adding a salt prefix to your rowkeys (i.e to better distribute
> timestamp rowkeys).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
