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

Enis Soztutar commented on HBASE-15128:
---------------------------------------

bq. assuming we add this setSwitch() now, and later we add dynamic conf. how 
one decide when to use one vs the other? since they are able to do the same 
thing?
The current dynamic configuration we have is more like, change the 
hbase-site.xml, but load it from the daemon without restart. Here, we want to 
be able to change the behavior of some master chores on demand from code. So 
the current dynamic conf framework does not match I think. If we do  
{{hbase.loadbalancer.enable}} in configuration, and keep this persisted as a 
dynamic switch somewhere, how do we decide which one is in affect? 


> Disable region splits and merges in HBCK
> ----------------------------------------
>
>                 Key: HBASE-15128
>                 URL: https://issues.apache.org/jira/browse/HBASE-15128
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Heng Chen
>             Fix For: 2.0.0, 1.3.0
>
>         Attachments: HBASE-15128.patch, HBASE-15128_v1.patch, 
> HBASE-15128_v3.patch
>
>
> In large clusters where region splits are frequent, and HBCK runs take 
> longer, the concurrent splits cause further problems in HBCK since HBCK 
> assumes a static state for the region partition map. We have just seen a case 
> where HBCK undo's a concurrently splitting region causing number of 
> inconsistencies to go up. 
> We can have a mode in master where splits and merges are disabled like the 
> balancer and catalog janitor switches. Master will reject the split requests 
> if regionservers decide to split. This switch can be turned on / off by the 
> admins and also automatically by HBCK while it is running (similar to 
> balancer switch being disabled by HBCK). 
> HBCK  should also disable the Catalog Janitor just in case. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to