[
https://issues.apache.org/jira/browse/CASSANDRA-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723405#comment-17723405
]
Tobias Lindaaker commented on CASSANDRA-18507:
----------------------------------------------
I have updated the branches to make sure they are in sync. I have also pushed
branches of {{4.1}} and {{trunk}} where the change history is based on merging
the changes forward from the previous version instead, in case that is more
helpful:
* {{4.1}}:
[thobe/CASSANDRA-18507-4.1-merge|https://github.com/thobe/cassandra/tree/CASSANDRA-18507-4.1-merge]
* {{trunk}}:
[thobe/CASSANDRA-18507-merge|https://github.com/thobe/cassandra/tree/CASSANDRA-18507-merge]
I also added a change to logging that would have made debugging this issue when
we first encountered it a little bit quicker.
> Partial compaction can resurrect deleted data
> ---------------------------------------------
>
> Key: CASSANDRA-18507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18507
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
> Reporter: Tobias Lindaaker
> Assignee: Tobias Lindaaker
> Priority: Normal
>
> If there isn't enough disk space available to compact all existing sstables,
> Cassandra will attempt to perform a partial compaction by removing sstables
> from the set of candidate sstables to be compacted, starting with the largest
> one. It is possible that the sstable removed from the set of sstables to
> compact contains data for which there are tombstones in another (more recent)
> sstable. Since the overlaps between sstables is computed when the
> {{CompactionController}} is created, and the {{CompactionController}} is
> created before the removal of any sstables from the set of sstables to be
> compacted this computed overlap will be outdated when checking which sstables
> are covered by certain tombstones. This leads to the faulty conclusion that
> the tombstones can be pruned during the compaction, causing the data to be
> resurrected.
> The issue is present in Cassandra 4.0 and 4.1. Cassandra 3.11 creates the
> {{CompactionController}} after the set of sstables to compact has been
> reduced, and is thus not affected. {{trunk}} does not appear to support
> partial compactions at all, but instead refuses to compact when the disk is
> full.
> This regression appears to have been introduced by CASSANDRA-13068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
