cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5745) Minor compaction tombstone-removal deadlock
Date Thu, 11 Jul 2013 15:37:49 GMT


Jonathan Ellis commented on CASSANDRA-5745:

bq. Now, if for a sstable that value reaches some threshold (say 30% by default), then we
could check if there is one or more sstable that potentially could block this gcing (based
on the min/max sstable timestamp), and if we find one (or more), we could force a compaction
of those sstables together (for LCS, we could take the sstable at the smallest level, and
compact it to all overlapping sstable up until the max level sstable

The problem is that you have the 10x magnification per level in LCS, so if you want to compact
"everything that overlaps with one sstable" from L1, you're compacting ~10% of all your data.

At least with the "big hammer" approach, it only does massive amounts of compaction when you
explicitly ask for it. :)
> Minor compaction tombstone-removal deadlock
> -------------------------------------------
>                 Key: CASSANDRA-5745
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jonathan Ellis
>             Fix For: 2.0.1
> From a discussion with Axel Liljencrantz,
> If you have two SSTables that have temporally overlapping data, you can get lodged into
a state where a compaction of SSTable A can't drop tombstones because SSTable B contains older
data *and vice versa*. Once that's happened, Cassandra should be wedged into a state where
CASSANDRA-4671 no longer helps with tombstone removal. The only way to break the wedge would
be to perform a compaction containing both SSTable A and SSTable B. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message