I've been wondering about this too, but every column has both a timestamp and a TTL.  Unless the timestamp is not preserved, there should be no need to adjust the TTL, assuming the expiration time is determined from these two variables.

Does that make sense?

My question is how often Cassandra checks for TTL expirations.  Does it happen at compaction time? Some other time?


Caleb Rackliffe | Software Developer
M 949.981.0159 | caleb@steelhouse.com

From: "igor@4friends.od.ua" <igor@4friends.od.ua>
Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Date: Mon, 19 Mar 2012 15:28:40 -0400
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Subject: Re: repair broke TTL based expiration

Hello

Datasize should decrease during minor compactions. Check logs for compactions results.

 



-----Original Message-----
From: Radim Kolar <hsn@filez.com>
To: user@cassandra.apache.org
Sent: Mon, 19 Mar 2012 12:16
Subject: repair broke TTL based expiration

I suspect that running cluster wide repair interferes with TTL based
expiration. I am running repair every 7 days and using TTL expiration
time 7 days too. Data are never deleted.
Stored data in cassandra are always growing (watching them for 3 months)
but they should not. If i run manual cleanup, some data are deleted but
just about 5%. Currently there are about 3-5 times more rows then i
estimate.

I suspect that running repair on data with TTL can cause:

1. time check for expired records is ignored and these data are streamed
to other node and they will be alive again
  or
2. streaming data are propagated with full TTL. Lets say that i have ttl
7 days, data are stored for 5 days and then repaired, they should be
sent to other node with ttl 2 days not 7.

Can someone do testing on this case? I could not play with production
cluster too much.