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]> 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]> 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]> > 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]> 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 >> >> >> >
