Thanks for your answer. Moreover, the issue you mentioned in the end was
the answer to the question I was going to ask next ;-)
Regards,
Michał
W dniu 02.01.2013 15:42, Sylvain Lebresne pisze:
WHEN does Cassandra remove expired (because of TTL) data?
When a compaction reads an expired column, it removes it and replaces it by
a tombstone (i.e. a deleted marker). So the first compaction after the
expiration is what actually removes the data, but it won't reclaim all the
disk space yet due to the tombstone. Said tombstone then follow the usual
rules for tombstones. I.e. it will be fully removed by compaction once
gc_grace seconds after the tombstone creation has elapsed. I note that
during reads, if a column is expired it is simply ignored by the read, but
nothing more is done.
Which operations cause Cassandra to check for TTL and create Tombstones
for
them if needed?
Only compaction does (for the 'create tombstones' part at least I mean).
For the rest of the system, an expired column is always handled exactly as
if it was a tombstone (so reads ignore them, scrub don't care specially
about them and repair don't do anything special either). I note that for
repair this could be a source of inconsistency between nodes; see more
details on https://issues.apache.org/jira/browse/CASSANDRA-4905.
--
Sylvain
