You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Jens Rantil <je...@tink.se> on 2014/11/01 16:18:46 UTC
Force purging of tombstones
Hi,
I recently ran a migration where I modified (essentially, deleted and inserted) a large number of clustering keys. This obviously created a lot of tombstones and now I am receiving warnings in my logs that number of tombstones are above a certain threshold when I query all rows for a certain partition key. I suspect this might lead to RPC Timeouts in certain cases.
The migration was done more than `gc_grace_seconds` ago, so I can safely remove these tombstones by now.
Question: Is there any way for me to force Cassandra to purge tombstones for all sstables of a certain columnfamily (running LCS)? I asked this quesion on IRC and AFAIK the only way would be to switch to SizeTiered compaction strategy, issuing a major compaction, and then switching back to LCS. Would there be any implications/side effects executing this procedure?
Thanks,
Jens
———
Jens Rantil
Backend engineer
Tink AB
Email: jens.rantil@tink.se
Phone: +46 708 84 18 32
Web: www.tink.se
Facebook Linkedin Twitter
Re: Force purging of tombstones
Posted by Robert Coli <rc...@eventbrite.com>.
On Tue, Nov 18, 2014 at 12:41 AM, Rahul Neelakantan <ra...@rahul.be> wrote:
> Is this page incorrect then and needs to be updated or am I interpreting
> it incorrectly ?
>
>
> http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_about_deletes_c.html
>
> Particularly this sentence
>
> "After data is marked with a tombstone, the data is automatically removed
> during the normal compaction
> <http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_write_path_c.html#concept_ds_wt3_32w_zj__dml-compaction> and
> repair processes"
>
Yes, it is incorrect. Repair does not remove anything. I have bcc:ed docs
AT datastax for their information.
=Rob
Re: Force purging of tombstones
Posted by Rahul Neelakantan <ra...@rahul.be>.
Is this page incorrect then and needs to be updated or am I interpreting it incorrectly ?
http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_about_deletes_c.html
Particularly this sentence
"After data is marked with a tombstone, the data is automatically removed during the normal compaction and repair processes"
Rahul
> On Nov 17, 2014, at 6:57 PM, Robert Coli <rc...@eventbrite.com> wrote:
>
>> On Mon, Nov 17, 2014 at 3:10 PM, Rahul Neelakantan <ra...@rahul.be> wrote:
>> Doesn't repair also get rid of tombstones?
>
> Repair is a non-destructive activity, and therefore cannot purge tombstones.
>
> =Rob
>
Re: Force purging of tombstones
Posted by Robert Coli <rc...@eventbrite.com>.
On Mon, Nov 17, 2014 at 3:10 PM, Rahul Neelakantan <ra...@rahul.be> wrote:
> Doesn't repair also get rid of tombstones?
>
Repair is a non-destructive activity, and therefore cannot purge tombstones.
=Rob
Re: Force purging of tombstones
Posted by Rahul Neelakantan <ra...@rahul.be>.
Doesn't repair also get rid of tombstones?
Rahul Neelakantan
> On Nov 17, 2014, at 5:53 PM, Robert Coli <rc...@eventbrite.com> wrote:
>
>> On Mon, Nov 17, 2014 at 1:40 PM, Ken Hancock <ke...@schange.com> wrote:
>> You can use the JMX forceUserDefinedCompaction operation to compact each SSTable individually.
>>
>> https://github.com/hancockks/cassandra-compact-cf
>
> I don't recall why I think this, but I think "cleanup" now also discards expired tombstones, and is easier to use from nodetool than UserDefinedCompaction.
>
> =Rob
>
Re: Force purging of tombstones
Posted by Robert Coli <rc...@eventbrite.com>.
On Mon, Nov 17, 2014 at 1:40 PM, Ken Hancock <ke...@schange.com>
wrote:
> You can use the JMX forceUserDefinedCompaction operation to compact each
> SSTable individually.
>
> https://github.com/hancockks/cassandra-compact-cf
>
I don't recall why I think this, but I think "cleanup" now also discards
expired tombstones, and is easier to use from nodetool than
UserDefinedCompaction.
=Rob
Re: Force purging of tombstones
Posted by Ken Hancock <ke...@schange.com>.
You can use the JMX forceUserDefinedCompaction operation to compact each
SSTable individually.
https://github.com/hancockks/cassandra-compact-cf
On Sat, Nov 1, 2014 at 11:18 AM, Jens Rantil <je...@tink.se> wrote:
> Hi,
>
> I recently ran a migration where I modified (essentially, deleted and
> inserted) a large number of clustering keys. This obviously created a lot
> of tombstones and now I am receiving warnings in my logs that number of
> tombstones are above a certain threshold when I query all rows for a
> certain partition key. I suspect this might lead to RPC Timeouts in certain
> cases.
>
> The migration was done more than `gc_grace_seconds` ago, so I can safely
> remove these tombstones by now.
>
> Question: Is there any way for me to force Cassandra to purge tombstones
> for all sstables of a certain columnfamily (running LCS)? I asked this
> quesion on IRC and AFAIK the only way would be to switch to SizeTiered
> compaction strategy, issuing a major compaction, and then switching back to
> LCS. Would there be any implications/side effects executing this procedure?
>
> Thanks,
> Jens
>
> ——— Jens Rantil Backend engineer Tink AB Email: jens.rantil@tink.se
> Phone: +46 708 84 18 32 Web: www.tink.se Facebook Linkedin Twitter
>