Re: STCS leaving sstables behind

Quick follow up : triggering a repair did the trick, sstables are starting to get compacted. Thank you On 13 November 2017 at 15:53, Nicolas Guyomar wrote: > Hi, > > I'm using default "nodetool repair" in 3.0.13 which I believe is full by > default. I'm not using

Re: STCS leaving sstables behind

Hi, I'm using default "nodetool repair" in 3.0.13 which I believe is full by default. I'm not using subrange repair Jeff you're right, "Nov 11 01:23 mc-6474-big-Data.db" is not yet marked as repaired, my repair routine is broken (sorry Alexander I'm not using repear yet ;) ) I'm gonna fix my

Re: STCS leaving sstables behind

And actually, full repair with 3.0/3.x would have the same effect (anticompation) unless you're using subrange repair. On Mon, Nov 13, 2017 at 3:28 PM Jeff Jirsa wrote: > Running incremental repair puts sstables into a “repaired” set (and an > unrepaired set), which results in

Re: STCS leaving sstables behind

Running incremental repair puts sstables into a “repaired” set (and an unrepaired set), which results in something similar to what you’re describing. Were you running / did you run incremental repair ? -- Jeff Jirsa > On Nov 13, 2017, at 5:04 AM, Nicolas Guyomar

STCS leaving sstables behind

Hi everyone, I'm facing quite a strange behavior on STCS on 3.0.13, the strategy seems to have "forgotten" about old sstables, and started a completely new cycle from scratch, leaving the old sstables on disk untouched : Something happened on Nov 10 on every node, which resulted in all those