[ 
https://issues.apache.org/jira/browse/HBASE-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253187#comment-13253187
 ] 

Jonathan Hsieh commented on HBASE-5360:
---------------------------------------

@Anoop.  Partially.  HBASE-5719 sidelines potential overlapping regions but 
doesn't take .META.'s info about if the region is offline into account.  It 
could sideline a live region while it could have been more efficient to 
sideline an offline region.  However, HBASE-5719 was sufficient for the case we 
were dealing with.  

Let's make this a placeholder for ways to improve it.  Some ideas include:
* Taking a region's offline/splitparent state into account if .META. entry is 
present
* Making decisions about sidelining vs merging based on region size and max 
region size (instead of range) xml properties.
* Improving the heuristic used to decide which region are sidelined.


                
> [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
>
> 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

        

Reply via email to