You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@cassandra.apache.org by Sotirios Delimanolis <so...@yahoo.com.INVALID> on 2017/08/18 23:05:48 UTC

Moving all LCS SSTables to a repaired state

I have a table that uses LeveledCompactionStrategy on Cassandra 2.2. At the moment, it has two SSTables, both in level 1, one that's repaired and one that isn't.
$ sstablemetadata lb-135366-big-Data.db | head
SSTable: /home/cassandra/data/my_keyspace/my_table/lb-135366-big
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.100000
Minimum timestamp: 635879632038598571
Maximum timestamp: 636386914930971960
SSTable max local deletion time: 2147483647
Compression ratio: 0.3329089923791937
Estimated droppable tombstones: 0.04952060383516932
SSTable Level: 1
Repaired at: 1503094842214
$ sstablemetadata lb-135367-big-Data.db | head
SSTable: /home/cassandra/data/my_keyspace/my_table/lb-135367-big
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.100000
Minimum timestamp: 636386903663409770
Maximum timestamp: 636386932592309420
SSTable max local deletion time: 2147483647
Compression ratio: 0.34908682568154525
Estimated droppable tombstones: 0.4720670391061452
SSTable Level: 1
Repaired at: 0

What can I do to get these both into a repaired state? I tried running a full repair, but that didn't set the "Repaired at" state in the metadata and Cassandra still manages the SSTables separately as "repaired" and "unrepaired".
I've never ran this cluster through the migration steps detailed here. Is that what's necessary in my case?

Re: Moving all LCS SSTables to a repaired state

Posted by kurt greaves <ku...@instaclustr.com>.

Pretty much, I wouldn't set your heart on having 0 unrepaired SSTables.

Re: Moving all LCS SSTables to a repaired state

Posted by Sotirios Delimanolis <so...@yahoo.com.INVALID>.

See my other email to this list that you replied to (I most recently replied late last week), titled "Cassandra isn't compacting old files". It's not just a few. It's tens/hundreds. I'm worried there's some "starvation" going on and disk is being filled with data that could be compacted away. 

On Monday, August 21, 2017, 4:21:47 PM PDT, kurt greaves <ku...@instaclustr.com> wrote:

Is there any specific reason you are trying to achieve this? It shouldn't really matter if you have a few SSTables in the unrepaired pool.

Re: Moving all LCS SSTables to a repaired state

Posted by kurt greaves <ku...@instaclustr.com>.

Is there any specific reason you are trying to achieve this? It shouldn't
really matter if you have a few SSTables in the unrepaired pool.

Re: Moving all LCS SSTables to a repaired state

Posted by Sotirios Delimanolis <so...@yahoo.com.INVALID>.

We are on 2.2.11 so we're all right on that front. The advice is difficult to implement unfortunately, with so many nodes.
Thanks for the information!On Sunday, August 20, 2017, 4:28:36 PM PDT, kurt greaves <ku...@instaclustr.com> wrote:

Correction: Full repairs do mark SSTables as repaired in 2.2 (CASSANDRA-7586). My mistake, I thought that was only introduced in 3.0. Note that if mixing full and incremental repairs you probably want to be using at least 2.2.10 because of CASSANDRA-13153. Advice still stands you'll likely still have to stop writes and repair to get 0 unrepaired SSTables.

Re: Moving all LCS SSTables to a repaired state

Posted by kurt greaves <ku...@instaclustr.com>.

Correction: Full repairs do mark SSTables as repaired in 2.2 (CASSANDRA-7586
<https://issues.apache.org/jira/browse/CASSANDRA-7586>). My mistake, I
thought that was only introduced in 3.0. Note that if mixing full and
incremental repairs you probably want to be using at least 2.2.10 because
of CASSANDRA-13153 <https://issues.apache.org/jira/browse/CASSANDRA-13153>.
Advice still stands you'll likely still have to stop writes and repair to
get 0 unrepaired SSTables.

Re: Moving all LCS SSTables to a repaired state

Posted by Sotirios Delimanolis <so...@yahoo.com.INVALID>.

That's the only way to get this done then, break writes and fix them with incremental repairs?

On Friday, August 18, 2017, 5:17:38 PM PDT, kurt greaves <ku...@instaclustr.com> wrote:

You need to run an incremental repair for sstables to be marked repaired. However only if all of the data in that Sstable is repaired during the repair will you end up with it being marked repaired, otherwise an anticompaction will occur and split the unrepaired data into its own sstable.It's pretty unlikely you will get all SSTables marked as repaired unless you stop writing data and run inc repair multiple times.

Re: Moving all LCS SSTables to a repaired state

Posted by kurt greaves <ku...@instaclustr.com>.

You need to run an incremental repair for sstables to be marked repaired.
However only if all of the data in that Sstable is repaired during the
repair will you end up with it being marked repaired, otherwise an
anticompaction will occur and split the unrepaired data into its own
sstable.
It's pretty unlikely you will get all SSTables marked as repaired unless
you stop writing data and run inc repair multiple times.