[
https://issues.apache.org/jira/browse/CASSANDRA-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699547#comment-14699547
]
Benedict commented on CASSANDRA-7066:
-------------------------------------
bq. We could follow the disk failure policy as it's done in
FileUtils.handleStartupFSError(), which is currently called during startup when
we encounter a corrupt sstable. So we would exit unless the policy is ignore,
in which case we log an error and possibly stash files.
Yes, that seems reasonable. In this case it may even be reasonable to not worry
about stashing, at least in the near term, and using this parameter to decide
if we should just apply the transaction.
bq. If we stash the sstables without the txn log file itself, then we keep on
logging errors each time we start up. Is this really what you meant Benedict?
I meant I don't mind what happens to the txn log file - deleting it would be
fine, but stashing it would also be fine.
bq. The stashing should perhaps be extended to corrupt sstables regardless of
transactions, see CASSANDRA-9812.
This also sounds like an excellent idea.
> Simplify (and unify) cleanup of compaction leftovers
> ----------------------------------------------------
>
> Key: CASSANDRA-7066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7066
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Stefania
> Priority: Minor
> Labels: benedict-to-commit, compaction
> Fix For: 3.0 alpha 1
>
> Attachments: 7066.txt
>
>
> Currently we manage a list of in-progress compactions in a system table,
> which we use to cleanup incomplete compactions when we're done. The problem
> with this is that 1) it's a bit clunky (and leaves us in positions where we
> can unnecessarily cleanup completed files, or conversely not cleanup files
> that have been superceded); and 2) it's only used for a regular compaction -
> no other compaction types are guarded in the same way, so can result in
> duplication if we fail before deleting the replacements.
> I'd like to see each sstable store in its metadata its direct ancestors, and
> on startup we simply delete any sstables that occur in the union of all
> ancestor sets. This way as soon as we finish writing we're capable of
> cleaning up any leftovers, so we never get duplication. It's also much easier
> to reason about.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
