cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12222) Per-node overrides for table settings
Date Tue, 19 Jul 2016 08:38:20 GMT


Sylvain Lebresne commented on CASSANDRA-12222:

Yes, my initial syntax did imply some duplication, but I can't say I have though it through
a lot either :)

For instance, we could change the syntax a bit to be:
ALTER TABLE foo WITH node_overrides = {
    'use-leveled' : { settings : { 'compaction' : { 'class' : 'LeveledCompactionStrategy'
} }, nodes : { '', ''} },
    'aggressive-read-repair' : { settings : { 'read_repair_change' : '1.0' }, nodes : { ''
} }
I.e. you'd have a map of named overrides, where each override is the settings overriden and
the set of nodes on which it is overriden. The only purpose of naming the override being to
make update easier through things like:
ALTER TABLE foo with node_overrides['use-leveled'].nodes = node_overrides['use-leveled'].nodes
+ { '' };

> Per-node overrides for table settings
> -------------------------------------
>                 Key: CASSANDRA-12222
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Sylvain Lebresne
>            Priority: Minor
> There is a few cases where it's convenient to set some table parameters on only one of
a few nodes. For instance, it's useful for experimenting with settings like caching options,
compaction, compression, read repair chance, gcGrace ... Another case is when you want to
completely migrate to a new setting, but want to do that node-per-node (mainly useful when
switching compaction strategy, see CASSANDRA-10898).
> I'll note that we can already do some of this through JMX for some of the settings as
we have methods like {{ColumnFamilyStoreMBean.setCompactionParameters()}}, but:
> # parameters settings are initially set in CQL. Having to go to JMX for this sounds less
consistent to me. The fact we have both a {{ColumnFamilyStoreMBean.setCompactionParameters()}}
and a {{ColumnFamilyStoreMBean.setCompactionParametersJson()}} (as I assume the former one
is inconvenient to use) is also proof to me than JMX ain't terribly appropriate.
> # I think this can be potentially useful for almost all table settings, but we don't
expose JMX methods for all settings, and it would be annoying to have to. The method suggested
below wouldn't have to be updated every time we add a new settings (if done right).
> # Changing options through JMX is not persistent across restarts. This may arguably be
fine in some cases, but if you're trying to migrate your compaction strategy node per node,
or want to experiment with a setting over a mediumish time period, it's mostly a pain.
> So what I suggest would be add node overrides in the normal table setting (which would
be part of the schema as any other setting). In other words, if you want to set LCS for only
one specific node, you'd do:
> {noformat}
> ALTER TABLE foo WITH node_overrides = { '' : { 'compaction' : { 'class' :
'LeveledCompactionStrategy' } } }
> {noformat}
> I'll note that I already suggested that idea on CASSANDRA-10898, but as it's more generic
than what that latter ticket is about, so creating its own ticket.

This message was sent by Atlassian JIRA

View raw message