[jira] [Commented] (CASSANDRA-12222) Per-node overrides for table settings
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383802#comment-15383802
]
Sylvain Lebresne commented on CASSANDRA-1:
--
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:
{noformat}
ALTER TABLE foo WITH node_overrides = {
'use-leveled' : { settings : { 'compaction' : { 'class' :
'LeveledCompactionStrategy' } }, nodes : { '192.168.0.1', '192.168.0.2'} },
'aggressive-read-repair' : { settings : { 'read_repair_change' : '1.0' },
nodes : { '192.168.0.1' } }
}
{noformat}
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:
{noformat}
ALTER TABLE foo with node_overrides['use-leveled'].nodes =
node_overrides['use-leveled'].nodes + { '192.168.0.3' };
{noformat}
> Per-node overrides for table settings
> -
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> 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 = { '192.168.0.1' : { '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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12222) Per-node overrides for table settings
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383153#comment-15383153
]
Nate McCall commented on CASSANDRA-1:
-
bq. 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.
Agreed. I really like the idea of having 'node_overrides' persisted in the
schema. Given the syntax and statement above, to alter 2 nodes with LCS are we
talking about:
{noformat}
ALTER TABLE foo
WITH node_overrides = {
'192.168.0.1' : { 'compaction' : { 'class' : 'LeveledCompactionStrategy' } }
,
'192.168.0.2' : { 'compaction' : { 'class' : 'LeveledCompactionStrategy' } }
}
{noformat}
If so, even though it's on the verbose side, I like the idea of being quite
explicit when "snowflaking." IME, we never test things like
{{setCompactionParameters()}} with more than a very small number of nodes
anyway.
> Per-node overrides for table settings
> -
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> 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 = { '192.168.0.1' : { '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
(v6.3.4#6332)
