[
https://issues.apache.org/jira/browse/CASSANDRA-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pedro Gordo updated CASSANDRA-15069:
------------------------------------
Description:
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.
was:
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.
> 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.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]
