[
https://issues.apache.org/jira/browse/CASSANDRA-12222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383153#comment-15383153
]
Nate McCall commented on CASSANDRA-12222:
-----------------------------------------
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-12222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12222
> 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)
