[
https://issues.apache.org/jira/browse/HBASE-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290300#comment-13290300
]
Zhihong Ted Yu commented on HBASE-5360:
---------------------------------------
{code}
- Path referencePath = getReferredToFile(p);
+ Path referencePath = StoreFileUtil.getReferredToFile(p);
{code}
Can you outline the rationale behind moving methods to StoreFileUtil ?
For sidelineSplitParent():
{code}
+ if (needReassign) {
+ toBeReassigned.add(child);
+ }
{code}
The above code is inside inner loop. Would a child be added to toBeReassigned
multiple times ?
{code}
+ // scenario (2)
+ errors.reportError(ERROR_CODE.FAILED_SPLIT_PARENT, "Region "
+ + descriptiveName + ", key=" + key + ", on HDFS, failed split parent");
+ if (shouldFixSplitParents()) {
+ resetSplitParent(hbi);
{code}
Do we need to do something about the children in above scenario ?
I think we should provide two flags to user corresponding to the two scenarios
so that they can decide which scenario(s) to fix.
{code}
+ * Daughters do refer to parent.
+ */
+ @Test
+ public void testLingeringSplitParent2() throws Exception {
{code}
Please give the two test cases meaningful names that are consistent with
javadoc.
> [uberhbck] Add options for how to handle offline split parents.
> ----------------------------------------------------------------
>
> Key: HBASE-5360
> URL: https://issues.apache.org/jira/browse/HBASE-5360
> Project: HBase
> Issue Type: Improvement
> Components: hbck
> Affects Versions: 0.90.7, 0.92.1, 0.94.0
> Reporter: Jonathan Hsieh
> Assignee: Jimmy Xiang
> Attachments: hbase-5360.path
>
>
> In a recent case, we attempted to repair a cluster that suffered from
> HBASE-4238 that had about 6-7 generations of "leftover" split data. The hbck
> repair options in an development version of HBASE-5128 treat HDFS as ground
> truth but didn't check SPLIT and OFFLINE flags only found in meta. The net
> effect was that it essentially attempted to merge many regions back into its
> eldest geneneration's parent's range.
> More safe guards to prevent "mega-merges" are being added on HBASE-5128.
> This issue would automate the handling of the "mega-merge" avoiding cases
> such as "lingering grandparents". The strategy here would be to add more
> checks against .META., and perform part of the catalog janitor's
> responsibilities for lingering grandparents. This would potentially include
> options to sideline regions, deleting grandparent regions, min size for
> sidelining, and mechanisms for cleaning .META..
> Note: There already exists an mechanism to reload these regions -- the bulk
> loaded mechanisms in LoadIncrementalHFiles can be used to re-add grandparents
> (automatically splitting them if necessary) to HBase.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
