Pedro Gordo created CASSANDRA-15069:
---------------------------------------
Summary: 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
Fix For: 3.11.3
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]
