[
https://issues.apache.org/jira/browse/CASSANDRA-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218539#comment-13218539
]
Pavel Yaskevich edited comment on CASSANDRA-2261 at 2/28/12 7:53 PM:
---------------------------------------------------------------------
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.
was (Author: xedin):
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: https://issues.apache.org/jira/browse/CASSANDRA-2261
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
