TTL, Tombstones, and gc_grace

[Michael Theroux <mt...@yahoo.com>]

Hello,

Quick question on Cassandra, TTLs, tombstones, and GC grace.  If we have a column family whose only mechanism of deleting columns is utilizing TTLs, is repair really necessary to make tombstones consistent, and therefore would it be safe to set the gc grace period of the column family to a very low value?

I ask because of this blog post based on Cassandra .7: http://www.datastax.com/dev/blog/whats-new-cassandra-07-expiring-columns.

"The first time the expired column is compacted, it is transformed into a tombstone. This transformation frees some disk space: the size of the value of the expired column. From that moment on, the column is a normal tombstone and follows the tombstone rules: it will be totally removed by compaction (including minor ones in most cases since Cassandra 0.6.6) after GCGraceSeconds."

Since tombstones are not written using a replicated write, but instead written during compaction, theoretically, it shouldn't be possible to lose a tombstone?  Or is this blog post inaccurate for later versions of cassandra?  We are using cassandra 1.1.11.

Thanks,
-Mike

Re: TTL, Tombstones, and gc_grace

[horschi <ho...@gmail.com>]

Hi Michael,

yes, you should never loose a delete, because there are no real deletes. No
matter what version you are using.

btw: There is actually a ticket that builds an optimization on top of that
assumption: CASSANDRA-4917. Basically, if TTL>gc_grace then do not create
tombstones for expiring-columns. This works because disappear anyway if TTL
is over.

cheers,
Christian


On Thu, Jul 25, 2013 at 3:24 PM, Michael Theroux <mt...@yahoo.com>wrote:

> Hello,
>
> Quick question on Cassandra, TTLs, tombstones, and GC grace.  If we have a
> column family whose only mechanism of deleting columns is utilizing TTLs,
> is repair really necessary to make tombstones consistent, and therefore
> would it be safe to set the gc grace period of the column family to a very
> low value?
>
> I ask because of this blog post based on Cassandra .7:
> http://www.datastax.com/dev/blog/whats-new-cassandra-07-expiring-columns.
>
> "The first time the expired column is compacted, it is transformed into a
> tombstone. This transformation frees some disk space: the size of the value
> of the expired column. From that moment on, the column is a normal
> tombstone and follows the tombstone rules: it will be totally removed by
> compaction (including minor ones in most cases since Cassandra 0.6.6) after
> GCGraceSeconds."
>
> Since tombstones are not written using a replicated write, but instead
> written during compaction, theoretically, it shouldn't be possible to lose
> a tombstone?  Or is this blog post inaccurate for later versions of
> cassandra?  We are using cassandra 1.1.11.
>
> Thanks,
> -Mike
>
>
>