Thanks everyone for their insights, it is really helpful, I will go forward with the suggestion to apply it on one node and then issue the alter command if everything seems fine
@Jeff Jirsa your remark is actually interesting, I am using a 7 DAY time windows in TWCS and migrating to UCS ( 'scaling_parameters': 'T4,T8', 'base_shard_count': '8') as a starting point do you think this will trigger a full compaction? Do u suggest different starting params for UCS? Regards ________________________________ From: Yuqi Yan <[email protected]> Sent: Monday, November 24, 2025 11:53 PM To: [email protected] <[email protected]> Subject: Re: Changing compaction strategy on a 'large' table I think it makes sense for you to run this setCompactionParametersJson on a single node to first see how things work. I've done a similar migration at a very large scale to LCS last year, and we did this very carefully in a batch-by-batch manner. The same experience should apply for you to move to UCS: * We utilized the setCompactionParametersJson method, bundled with a custom patch that will call setCompactionParametersJson at startup to override the local compaction strategy, which allows us to roll out the strategy change in batch-by-batch manner, and preserve the overrides on restart Though we ran into other issues e.g. the physical host didn't have enough disk (we did STCS -> LCS, probably not an issue for you). So we ended up doing a rebuild method for some special cases. For reference, this is the poster<https://drive.google.com/file/d/1KAGSBgtfx2_dPzQmYTEtJgRMV_sfT0LX/view?usp=drive_link> we had in Cassandra meetup last time On Mon, Nov 24, 2025 at 10:02 AM Jeff Jirsa <[email protected]<mailto:[email protected]>> wrote: There are certainly blog posts (probably from a decade ago) around that describe this, largely because in the past this would essentially guarantee ~100% of your data gets re-compacted at the same time on all nodes, which usually means a latency hit. If you do it one or two nodes at a time, you can speculate around the increased latency. If you do it on all nodes, your query latency is likely to be impacted. You can sometimes mitigate this with throttles (fewer threads, fewer bytes per thread), but then you run the risk of falling behind with compaction in general. That said - it’s not obvious to me if TWCS -> UCS even forces a full compaction, or if the time tiering is close enough that UCS will just leave it alone. On Nov 24, 2025, at 9:56 AM, Tolbert, Andy <[email protected]<mailto:[email protected]>> wrote: I think Isaeed may be referring to the setCompactionParametersJson JMX method (https://issues.apache.org/jira/browse/CASSANDRA-9965, https://github.com/apache/cassandra/blob/cassandra-5.0.6/src/java/org/apache/cassandra/db/ColumnFamilyStoreMBean.java#L109) This is a good way of evaluating a new compaction configuration, but it's probably not worth rolling out a compaction change on one node at a time unless you are really super risk-averse. Maybe try it out on one node and observe a little bit, and if everything looks good then just make the alter call like Patrick suggests. Ideally you'd have a test environment with a similar data size that you could test the compaction change against. Unless you are running pretty close to the edge of disk or cpu utilization, it should be fine to alter the compaction strategy, but the JMX call could be a useful tool to try it out on a canary node and observe how things work. Thanks, Andy On Mon, Nov 24, 2025 at 10:08 AM Patrick McFadin <[email protected]<mailto:[email protected]>> wrote: I tried to find the previous discussion about JMX you are referring too, but didn’t find it. In general, if you are switching to UCS, just use the alter statement. If that isn’t working for you or you have some special circumstance, it would be good to know what that is so we can address the problem. Patrick On Nov 20, 2025, at 1:34 AM, Isaeed Mohanna <[email protected]<mailto:[email protected]>> wrote: Hi I have a table with ~250GB per node of ~ 530 sstables per node that is using TWCS today without TTL running cassandra 5.0.5 I am planning to migrate the table into UCS, is it safe just to issue the alter command in cqlsh or is it advised to do it per node via JMX and at the end issue the cql command as was recommended to me here in the past with earlier versions of cassandra? Thanks for the input
