hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: [DISCUSS] Dynamic switches in master
Date Thu, 04 Feb 2016 06:28:40 GMT
+1 to reducing dependency on zookeeper 

> On Feb 3, 2016, at 9:50 PM, 张铎 <palomino219@gmail.com> wrote:
> My opinion, use conf file as default, and use code to override the config
> in conf file.
> And we need to persist the overridden value somewhere, not zk I'd say. I
> agree with Matteo that we should reduce the dependency of zk. Maybe we
> could introduce an hbase:config table?
> And for the dynamic configuration framework, it is difficult to treat all
> configurations in the same way I think. I prefer changing all
> configurations with a shell command(the actual implementation should an RPC
> call to master maybe), but if we have regionservers with different
> hardwares in cluster, they may have different configurations so modify conf
> file directly on the machine is a more proper way? I have no idea...
> Thanks.
> 2016-02-04 11:40 GMT+08:00 Enis Söztutar <enis@hortonworks.com>:
>> This came up in the review for HBASE-15128, but we thought that we should
>> surface this discussion in dev@.
>> The idea for HBASE-15128 is that, we should have a dynamic switch in master
>> so that the operator (or HBCK) can disable all region splits or merges.
>> We currently have such dynamic switches for balancer and normalizer which
>> keep their state in zk. We also have a switch for catalog janitor which
>> keeps its state only in memory (not sure why). For the new switches Heng
>> Chen implemented a "set_switch" RPC to master, a switch type, a zk node.
>> The idea is to move balancer, catalog janitor and normalizer switches to
>> this after this patch.
>> However, Matteo raised a point about this framework being an alternative
>> way of doing dynamic configuration. The problem is that we do not have a
>> dynamic conf framework that we can piggyback on, and since balancer and
>> other switches already work this way, it does not make sense to block the
>> issue. What do you guys think? If we want to implement dynamic conf, how
>> would we handle things like enabling / disabling balancer from conf and or
>> from code? Any good ideas?
>> Enis

View raw message