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 subrange repair
>
> Jeff you're
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 r
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 something similar
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
> wrote:
>
> Hi everyone,
>
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
ssta
