cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Caleb Rackliffe <>
Subject Re: repair broke TTL based expiration
Date Mon, 19 Mar 2012 20:46:18 GMT
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 |

From: "<>" <<>>
Reply-To: "<>" <<>>
Date: Mon, 19 Mar 2012 15:28:40 -0400
To: "<>" <<>>
Subject: Re: repair broke TTL based expiration


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

-----Original Message-----
From: Radim Kolar <<>>
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

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
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.

View raw message