[jira] [Commented] (CASSANDRA-10299) Issue with sstable selection when anti-compacting

["Marcus Eriksson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738509#comment-14738509 ] 

Marcus Eriksson commented on CASSANDRA-10299:
---------------------------------------------

nice catch, looks good to me, just letting CI run before committing

> Issue with sstable selection when anti-compacting
> -------------------------------------------------
>
>                 Key: CASSANDRA-10299
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10299
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: 4 node Cassandra 2.1.9 cluster (256 vnodes)
>            Reporter: Marcus Olsson
>            Assignee: Marcus Olsson
>         Attachments: sstable-selection-for-anticompaction-2.1.patch
>
>
> While running some tests with incremental repair we ran into some issues with some data being repaired over and over again. The repairs where scheduled to run every two hours on a different node. So e.g.
> {noformat}
> node1 would repair on hours 0,  8, 16
> node2 would repair on hours 2, 10, 18
> node3 would repair on hours 4, 12, 20
> node4 would repair on hours 6, 14, 22
> {noformat}
> The data being repaired over and over where in a table with static data, so it should've only been required to run repair once for that table. This table generated ~700 small sstables per repair, and when I checked one node had several thousands of sstables in that table alone.
> The repair command used on each node was:
> {noformat}
> repair -inc -par
> {noformat}
> So after stopping all clients and waiting for compactions to finish I ran sstablemetadata on the tables and saw that one table wasn't repaired. After checking in the logs I something like this:
> {noformat}
> SSTable ..-ka-X-Data.db (..) will be anticompacted on range (..)
> ...
> SSTable ..-ka-X-Data.db (..) does not intersect repaired range (..), not touching repairedAt.
> {noformat}
> So I checked the code and there seems to be an issue when one of the repaired ranges does not intersect the sstable range. In that case it just removes the sstable from the anticompaction regardless if any other repaired range intersects with it.
> Attaching patch for 2.1 that solves this and working on dtest for this. Will create patch for 2.2 and 3.0 as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)