[jira] [Commented] (CASSANDRA-10898) Migrate Compaction Strategy Node by Node
[
https://issues.apache.org/jira/browse/CASSANDRA-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17438881#comment-17438881
]
developthou commented on CASSANDRA-10898:
-
I wanted to try this but I am running into the following error
{code:java}
ALTER TABLE mytable1 with compaction = {'class' : 'SizeTieredCompaction',
'exceptions' : { 10.1.1.1 : {'class' : 'TimeWindowCompactionStrategy'} } };
SyntaxException: line 1:103 no viable alternative at input '.'
(...'SizeTieredCompaction', 'exceptions' : { 10.1[.]...){code}
I am not able to find any documentation. Can you please help?
I am in Cassandra
{noformat}
3.11.5{noformat}
> Migrate Compaction Strategy Node by Node
>
>
> Key: CASSANDRA-10898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10898
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Local/Compaction
>Reporter: Andrew From
>Priority: Normal
>
> It would be a great feature to be able to slowly change the compaction
> strategy of a ColumnFamily node-by-node instead of cluster wide. Currently if
> you change it cluster wide there's no good way to predict how long it will
> take. Thus the process could run for days while you still need the live data,
> but the cluster responds much more slowly due to the compaction strategy
> migration.
> I stumbled across
> http://blog.alteroot.org/articles/2015-04-20/change-cassandra-compaction-strategy-on-production-cluster.html
> which gave me the idea. I was thinking this would be a nice feature to add
> to NodeTool, provided that the strategy in the blog is sound I wouldn't mind
> going ahead with the dev work to automate it. If not I would love to hear
> other ideas on how to best make this happen.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10898) Migrate Compaction Strategy Node by Node
[ https://issues.apache.org/jira/browse/CASSANDRA-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15080936#comment-15080936 ] Sylvain Lebresne commented on CASSANDRA-10898: -- bq. it looks like in your example 1.1.1.1 and 1.1.1.2 would be the IP addresses of which Cassandra Nodes have been overridden to use a different compaction strategy? Right. bq. And honestly for how little you would need this a quick dirty script might be fine. Just to clarify, my suggestion is not meant to be _only_ for the use case you opened the ticket for. I just think it could be a neat option to be able to test specific settings on a single (or a couple of) node easily for settings that are intrinsically local (so at least compaction strategy, caching options and sstable compression for now). And while those changes can be done through JMX through scripts, it's slightly involved and not having it persist across can be operationally annoying. But this is nothing more than a nice to have in my mind. bq. Another option I thought of is having a mechanism to control the maximum simultaneous compactions for table in the cluster. Sure, though that solve a slightly different problem than the one I made my suggestion for (as explained above). But being able to somewhat limit the amount of concurrent compaction going on in the cluster is also an interesting suggestion, and not just for when changing compaction strategy in fact. It's probably a bit more involved however. > Migrate Compaction Strategy Node by Node > > > Key: CASSANDRA-10898 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10898 > Project: Cassandra > Issue Type: Wish > Components: Compaction, Tools >Reporter: Andrew From > > It would be a great feature to be able to slowly change the compaction > strategy of a ColumnFamily node-by-node instead of cluster wide. Currently if > you change it cluster wide there's no good way to predict how long it will > take. Thus the process could run for days while you still need the live data, > but the cluster responds much more slowly due to the compaction strategy > migration. > I stumbled across > http://blog.alteroot.org/articles/2015-04-20/change-cassandra-compaction-strategy-on-production-cluster.html > which gave me the idea. I was thinking this would be a nice feature to add > to NodeTool, provided that the strategy in the blog is sound I wouldn't mind > going ahead with the dev work to automate it. If not I would love to hear > other ideas on how to best make this happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10898) Migrate Compaction Strategy Node by Node
[ https://issues.apache.org/jira/browse/CASSANDRA-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15073239#comment-15073239 ] Andrew From commented on CASSANDRA-10898: - [~slebresne] it looks like in your example 1.1.1.1 and 1.1.1.2 would be the IP addresses of which Cassandra Nodes have been overridden to use a different compaction strategy? I poked around for a bit to see if there was a better way to uniquely identify a Cassandra Node and it seems like that is the best way. Implementing the feature that way would still require some manual intervention (or a script). And honestly for how little you would need this a quick dirty script might be fine. As long as you have a majority of your cluster has slowly converted to the new compaction strategy, then any ones that may have restarted during the process will have minimal impact vs the current. Another option I thought of is having a mechanism to control the maximum simultaneous compactions for table in the cluster. It would be useful in limiting performance impacts during compaction strategy changes or high write loads. However implementing this would mean something like a counter table in the system keyspace? > Migrate Compaction Strategy Node by Node > > > Key: CASSANDRA-10898 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10898 > Project: Cassandra > Issue Type: Wish > Components: Compaction, Tools >Reporter: Andrew From > > It would be a great feature to be able to slowly change the compaction > strategy of a ColumnFamily node-by-node instead of cluster wide. Currently if > you change it cluster wide there's no good way to predict how long it will > take. Thus the process could run for days while you still need the live data, > but the cluster responds much more slowly due to the compaction strategy > migration. > I stumbled across > http://blog.alteroot.org/articles/2015-04-20/change-cassandra-compaction-strategy-on-production-cluster.html > which gave me the idea. I was thinking this would be a nice feature to add > to NodeTool, provided that the strategy in the blog is sound I wouldn't mind > going ahead with the dev work to automate it. If not I would love to hear > other ideas on how to best make this happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10898) Migrate Compaction Strategy Node by Node
[
https://issues.apache.org/jira/browse/CASSANDRA-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063849#comment-15063849
]
Sylvain Lebresne commented on CASSANDRA-10898:
--
I agree that it would be a nice option to have in principle. In fact, while I
agree that compaction is probably the one option for which this is the most
useful, I would argue that this could be useful for any setting that
intrinsically change something local. So sstable compression parameters and
caching parameters could good candidates for this as it could allow to test
settings in real situation for extended periods of time but for only one or a
couple of nodes.
The one imo big gotcha of the strategy in this blog post however is that the
changes to a node are not persistant so a restarted node will revert back to
the default strategy and that's really not fun. This is totally called out by
the post btw and it's not at all a criticism of that post (which I think is a
great solution given the current status quo), but if we're gonna offer that
natively, I don't think we can ship with that "limitation".
Not sure what's the best solution for that though but one idea would be to
allow a list of "exceptions" to the table parameters, that is something like:
{noformat}
ALTER TABLE myTable with compaction = {'class' : 'SizeTieredCompaction',
'exceptions' : { 1.1.1.1 : { 'class' : 'LeveledCompactionStrategy'} } };
{noformat}
I do note that this solution has currently the one downside that if you want to
migrate nodes one by one, you'd have to re-sent the _whole_ {{ALTER TABLE}}
statement with the new
exception added, which, if done manually, is a tad annoying and error prone. We
could however add some syntax like:
{noformat}
ALTER TABLE myTable with compaction['exceptions'] = compaction['exceptions'] +
{ 1.1.1.2 : { 'class' : 'LeveledCompactionStrategy'} };
{noformat}
> Migrate Compaction Strategy Node by Node
>
>
> Key: CASSANDRA-10898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10898
> Project: Cassandra
> Issue Type: Wish
> Components: Compaction, Tools
>Reporter: Andrew From
>
> It would be a great feature to be able to slowly change the compaction
> strategy of a ColumnFamily node-by-node instead of cluster wide. Currently if
> you change it cluster wide there's no good way to predict how long it will
> take. Thus the process could run for days while you still need the live data,
> but the cluster responds much more slowly due to the compaction strategy
> migration.
> I stumbled across
> http://blog.alteroot.org/articles/2015-04-20/change-cassandra-compaction-strategy-on-production-cluster.html
> which gave me the idea. I was thinking this would be a nice feature to add
> to NodeTool, provided that the strategy in the blog is sound I wouldn't mind
> going ahead with the dev work to automate it. If not I would love to hear
> other ideas on how to best make this happen.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
