You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Caleb Rackliffe (JIRA)" <ji...@apache.org> on 2018/06/28 16:56:01 UTC
[jira] [Commented] (CASSANDRA-14479) Secondary Indexes Can "Leak"
Records If Insert/Partition Delete Occur Between Flushes
[ https://issues.apache.org/jira/browse/CASSANDRA-14479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526532#comment-16526532 ]
Caleb Rackliffe commented on CASSANDRA-14479:
---------------------------------------------
Just to confirm, this wouldn't affect SASI, given it doesn't respond to deletes in the first place?
> Secondary Indexes Can "Leak" Records If Insert/Partition Delete Occur Between Flushes
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14479
> Project: Cassandra
> Issue Type: Bug
> Components: Secondary Indexes
> Reporter: Jordan West
> Priority: Major
> Attachments: 2i-leak-test.patch
>
>
> When an insert of an indexed column is followed rapidly (within the same memtable) by a delete of an entire partition, the index table for the column will continue to store the record for the inserted value and no tombstone will ever be written. This occurs because the index isn't updated after the delete but before the flush. The value is lost after flush, so subsequent compactions can't issue a delete for the primary key in the index column.
> The attached test reproduces the described issue. The test fails to assert that the index cfs is empty. The subsequent assertion that there are no live sstables would also fail. Looking on disk with sstabledump after running this test shows the value remaining.
> Originally reported on the mailing list by Roman Bielik:
> Create table with LeveledCompactionStrategy;
> 'tombstone_compaction_interval': 60; gc_grace_seconds=60
> There are two indexed columns for comparison: column1, column2
> Insert keys \{1..x} with random values in column1 & column2
> Delete \{key:column2} (but not column1)
> Delete \{key}
> Repeat n-times from the inserts
> Wait 1 minute
> nodetool flush
> nodetool compact (sometimes compact <keyspace> <table.index>
> nodetool cfstats
> What I observe is, that the data table is empty, column2 index table is
> also empty and column1 index table has non-zero (leaked) "space used" and
> "estimated rows".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org