Re: changing compaction strategy

[kurt greaves]

The rogue pending task is likely a non-issue. If your jmx command went
through without errors and you got the log message you can assume it
worked. It won't show in the schema unless you run the ALTER statement
which affects the whole cluster.

If you were switching from STCS then you wouldn't expect any recompaction,
as SSTables will just be calculated to be in their relevant window. On the
other hand switching from LCS would generate many compactions.
​
The only way to really tell is to confirm SSTables are expiring as you
would expect them to, or verify that new SSTables are not being compacted
with older ones. You might need to wait for at least one time window to
pass to check this.

Re: changing compaction strategy

[Mike Torra]

Some more info:
- running C* 3.9
- I tried `nodetool flush` on the column family this change applies to, and
while it does seem to trigger compactions, there is still one pending that
won't seem to run
- I tried `nodetool compact` on the column family as well, with a similar
affect

Is there a way to tell when/if the local node has successfully updated the
compaction strategy? Looking at the sstable files, it seems like they are
still based on STCS but I don't know how to be sure.

Appreciate any tips or suggestions!

On Mon, Mar 13, 2017 at 5:30 PM, Mike Torra  wrote:

> I'm trying to change compaction strategy one node at a time. I'm using
> jmxterm like this:
>
> `echo 'set -b 
> org.apache.cassandra.db:type=ColumnFamilies,keyspace=my_ks,columnfamily=my_cf
> CompactionParametersJson \{"class":"TimeWindowCompactionStrategy",
> "compaction_window_unit":"HOURS","compaction_window_size":"6"\}' | java
> -jar jmxterm-1.0-alpha-4-uber.jar --url localhost:7199`
>
> and I see this in the cassandra logs:
>
> INFO  [RMI TCP Connection(37)-127.0.0.1] 2017-03-13 20:29:08,251
> CompactionStrategyManager.java:841 - Switching local compaction strategy
> from 
> CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
> options={max_threshold=32, min_threshold=4}} to CompactionParams{class=org.
> apache.cassandra.db.compaction.TimeWindowCompactionStrategy,
> options={min_threshold=4, max_threshold=32, compaction_window_unit=HOURS,
> compaction_window_size=6}}}
>
> After doing this, `nodetool compactionstats` shows 1 pending compaction,
> but none running. Also, cqlsh describe shows the old compaction strategy
> still. Am I missing a step?
>

changing compaction strategy

[Mike Torra]

I'm trying to change compaction strategy one node at a time. I'm using
jmxterm like this:

`echo 'set -b
org.apache.cassandra.db:type=ColumnFamilies,keyspace=my_ks,columnfamily=my_cf
CompactionParametersJson
\{"class":"TimeWindowCompactionStrategy","compaction_window_unit":"HOURS","compaction_window_size":"6"\}'
| java -jar jmxterm-1.0-alpha-4-uber.jar --url localhost:7199`

and I see this in the cassandra logs:

INFO  [RMI TCP Connection(37)-127.0.0.1] 2017-03-13 20:29:08,251
CompactionStrategyManager.java:841 - Switching local compaction strategy
from
CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
options={max_threshold=32, min_threshold=4}} to
CompactionParams{class=org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy,
options={min_threshold=4, max_threshold=32, compaction_window_unit=HOURS,
compaction_window_size=6}}}

After doing this, `nodetool compactionstats` shows 1 pending compaction,
but none running. Also, cqlsh describe shows the old compaction strategy
still. Am I missing a step?

Impact of Changing Compaction Strategy

[Anuj Wadehra]

Hi,
I need to understand whether all existing sstables are recreated/updated when 
we change compaction strategy from STCS to DTCS?

Sstables are immutable by design but do we take an exception for such cases and 
update same files when an Alter statement is fired to change the compaction 
strategy?

ThanksAnuj
Sent from Yahoo Mail on Android

Re: Impact of Changing Compaction Strategy

[Jeff Jirsa]

When you change compaction strategy, nothing happens until the next flush. On 
the next flush, the new compaction strategy will decide what to do – if you 
change from STCS to DTCS, it will look at various timestamps of files, and 
attempt to group them by time windows based on the sstable’s minTimestamp, and 
your DTCS base_time_seconds and an ever-growing multiple of min_threshold

Generally, many people recommend doing a STCS major before changing to DTCS 
(essentially to force all sstables into the oldest possible bucket). Whether or 
not that’s ideal for you depends on why you’re using DTCS (do you want to cut 
down on compaction, or are you setting yourself up for efficient TTL 
expiration). If it’s the latter, you should be sure you understand the impact 
of STCS major on your TTL use case (no data will TTL out until all of the data 
currently on disk is ready to expire).



From:  Anuj Wadehra
Reply-To:  "user@cassandra.apache.org"
Date:  Friday, January 15, 2016 at 10:16 AM
To:  "user@cassandra.apache.org"
Subject:  Impact of Changing Compaction Strategy

Hi, 

I need to understand whether all existing sstables are recreated/updated when 
we change compaction strategy from STCS to DTCS?


Sstables are immutable by design but do we take an exception for such cases and 
update same files when an Alter statement is fired to change the compaction 
strategy?


Thanks
Anuj

Sent from Yahoo Mail on Android



smime.p7s
Description: S/MIME cryptographic signature