[ https://issues.apache.org/jira/browse/CASSANDRA-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Shuler updated CASSANDRA-15069: --------------------------------------- Fix Version/s: (was: 3.11.3) 3.11.x > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org