You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2016/01/04 11:19:39 UTC

[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&focusedCommentId=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)