[ 
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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to