[
https://issues.apache.org/jira/browse/HBASE-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203269#comment-13203269
]
stack commented on HBASE-5335:
------------------------------
bq ...but you'd need to do a large refactor to handle truly online
configuration transitions.
What if we just did the 'important' ones?
On the locking primitives, if a long or something, we could just have the
config. volatile? Would be more costly than a final long but could make a
local copy per method invocation I suppose.
bq. Note that, with your region server draining, you can change global config
values in an online fashion on a per-server basis by issuing a 'regionserver
restart --draining' or something like that.
We can do that now, right? Make the change then do our rolling restart with
graceful shedding of regions from the server, and then graceful replacement.
The addition of the HBaseTableConfiguration and HBaseStoreConfiguration would
make it all a little nicer. I'm interested in how the HBaseStoreConfiguration
configs make it into the schema and then get undone on the other side (You
could ask me how a config. change in a zk callback makes it up into a
regionserver Configuration instance... not sure)
bq. ...have you done a lot of testing with killing ZKQuorumPeers on clusters
with a lot of regions
Haven't done any. Sounds like we should? Does the ensemble have to have a
bunch of znodes afloat for you to see the spikes or is it just catching up the
restarted peers state regardless of the particular znode loading at the time?
> Dynamic Schema Configurations
> -----------------------------
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
> Issue Type: New Feature
> Reporter: Nicolas Spiegelberg
> Assignee: Nicolas Spiegelberg
> Labels: configuration, schema
>
> Currently, the ability for a core developer to add per-table & per-CF
> configuration settings is very heavyweight. You need to add a reserved
> keyword all the way up the stack & you have to support this variable
> long-term if you're going to expose it explicitly to the user. This has
> ended up with using Configuration.get() a lot because it is lightweight and
> you can tweak settings while you're trying to understand system behavior
> [since there are many config params that may never need to be tuned]. We
> need to add the ability to put & read arbitrary KV settings in the HBase
> schema. Combined with online schema change, this will allow us to safely
> iterate on configuration settings.
--
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
