[
https://issues.apache.org/jira/browse/CASSANDRA-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073239#comment-15073239
]
Andrew From edited comment on CASSANDRA-10898 at 12/28/15 10:59 PM:
--------------------------------------------------------------------
[~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 (since it uses paxos which could be used as a distributed
semaphore)?
was (Author: fromanator):
[~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)
