[ 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)