[
https://issues.apache.org/jira/browse/HBASE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083268#comment-13083268
]
Ming Ma commented on HBASE-2399:
--------------------------------
Jonathan, if you aren't looking this, I can investigate this more. It looks
like in trunk the issue of "if the first family isn't splittable, then whole
region isn't split" has been fixed as part of split/compaction refactoring. The
issue about "using first splittable family's midkey for the whole region" is
still there. It can be fixed by picking the midkey of the family with largest
store files size.
> Forced splits only act on the first family in a table
> -----------------------------------------------------
>
> Key: HBASE-2399
> URL: https://issues.apache.org/jira/browse/HBASE-2399
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.20.3
> Reporter: Jonathan Gray
> Assignee: Jonathan Gray
> Priority: Critical
> Labels: moved_from_0_20_5
> Fix For: 0.92.0
>
> Attachments: HBASE-2399-test-v1.patch
>
>
> While working on a patch for HBASE-2375, I came across a few bugs in the
> existing code related to splits.
> If a user triggers a manual split, it flips a forceSplit boolean to true and
> then triggers a compaction (this is very similar to my current implementation
> for HBASE-2375). However, the forceSplit boolean is flipped back to false at
> the beginning of Store.compact(). So the force split only acts on the first
> family in the table. If that Store is not splittable for some reason (it is
> empty or has only one row), then the entire region will not be split,
> regardless of what is in other families.
> Even if there is data in the first family, the midKey is determined based
> solely on that family. If it has two rows and the next family has 1M rows,
> we pick the split key based on the two rows.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
