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