[jira] [Commented] (CASSANDRA-15069) Tombstone/Partition not purged after gc_grace_seconds

["Pedro Gordo (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16880524#comment-16880524 ] 

Pedro Gordo commented on CASSANDRA-15069:
-----------------------------------------

[~mshuler] thanks for the edits. I forgot to update the ticket, sorry. I've found the issue. The reason is that one of the SSTables is repaired, and the other is unrepaired. This is why the result of major compaction was always two SSTables. Also, the two SSTables were overlapping, so Cassandra could never drop the tombstone. After resetting repaired status and compacting the two SSTables, they were merged, and the tombstones dropped.

> Tombstone/Partition not purged after gc_grace_seconds
> -----------------------------------------------------
>
>                 Key: CASSANDRA-15069
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15069
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local/Compaction, Local/SSTable
>            Reporter: Pedro Gordo
>            Priority: Normal
>             Fix For: 3.11.x
>
>         Attachments: schema.cql, sstables.tar
>
>
> During a tombstone purge (reducing gc_grace_seconds to zero and running `nodetool garbagecollect`), I noticed that when doing a dump of the SSTable, sometimes, there are a few partitions that do not get completely purged, even with gc_grace_seconds set to zero. I was able to replicate this in a small test dataset, from which I have attached the SSTable files and the schema to this ticket so that you can verify this as well. 
> Doing a dump of the mc-51-big-Data.db file, you'll notice the following partition:
> {
>     "partition" : {
>       "key" : [ "96" ],
>       "position" : 285,
>       "deletion_info" : { "marked_deleted" : "2019-03-14T21:31:55.244490Z", "local_delete_time" : "2019-03-14T21:31:55Z" }
>     },
>     "rows" : [ ]
>   },
> As you can see, the rows were removed correctly by the garbagecollect, but the partition record, continues there, and never goes away.
> From the client side, no data is returned, so it's good there. But regardless of that, this partition should not be present in the SSTable file.



--
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