cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (Updated) (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-2261) During Compaction, Corrupt SSTables with rows that cause failures should be identified and blacklisted.
Date Tue, 28 Feb 2012 19:51:46 GMT


Pavel Yaskevich updated CASSANDRA-2261:

    Attachment: CASSANDRA-2261-v3.patch

changes in v3:

# LeveledManifest now returns list with suspected SSTables filtered out if original candidates
happen to have at least one suspected SSTables (originally it was just aborting compaction
by returning empty list).

# Blacklisting test now supportes both SizeTiered and Leveled strategies. Also for(;;) replaced
with bounded loop to avoid the situation when we can get into infinite loop if forceMajorCompaction
does not fail.

# Styling and nits is fixed.
> During Compaction, Corrupt SSTables with rows that cause failures should be identified
and blacklisted.
> -------------------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-2261
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benjamin Coverston
>            Assignee: Pavel Yaskevich
>            Priority: Minor
>              Labels: not_a_pony
>             Fix For: 1.1.1
>         Attachments: 2261-v2.patch, 2261.patch, CASSANDRA-2261-v3.patch
> When a compaction of a set of SSTables fails because of corruption it will continue to
try to compact that SSTable causing pending compactions to build up.
> One way to mitigate this problem would be to log the error, then identify the specific
SSTable that caused the failure, subsequently blacklisting that SSTable and ensuring that
it is no longer included in future compactions. For this we could simply store the problematic
SSTable's name in memory.
> If it's not possible to identify the SSTable that caused the issue, then perhaps blacklisting
the (ordered) permutation of SSTables to be compacted together is something that can be done
to solve this problem in a more general case, and avoid issues where two (or more) SSTables
have trouble compacting a particular row. For this option we would probably want to store
the lists of the bad combinations in the system table somewhere s.t. these can survive a node
failure (there have been a few cases where I have seen a compaction cause a node failure).

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


View raw message