cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew From (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10898) Migrate Compaction Strategy Node by Node
Date Mon, 28 Dec 2015 22:58:49 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Mime
View raw message