> 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
