cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Olsson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10299) Issue with sstable selection when anti-compacting
Date Thu, 10 Sep 2015 12:55:45 GMT

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

Marcus Olsson commented on CASSANDRA-10299:
-------------------------------------------

Created a pull request for a dtest available [here|https://github.com/riptano/cassandra-dtest/pull/544].

> 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
>             Fix For: 3.0.0 rc1, 2.1.10, 2.2.2
>
>         Attachments: CASSANDRA-10299-2.2.patch, CASSANDRA-10299-3.0.patch, 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)

Mime
View raw message