That's not how gc_grace_seconds work. gc_grace_seconds controls how much time *after* a tombstone can be deleted, it can actually be deleted, in order to give you enough time to run repairs.
Say you have data that is about to expire on March 16 8am, and gc_grace_seconds is 10 days. After Mar 16 8am that data will be a tombstone, and only after March 26 8am, a compaction *might* remove it, if all other conditions are met. gil On Fri, Mar 15, 2024 at 12:58 AM Sebastian Marsching < sebast...@marsching.com> wrote: > > by reading the documentation about TTL > > https://cassandra.apache.org/doc/4.1/cassandra/operating/compaction/index.html#ttl > It mention that it creates a tombstone when data expired, how does it > possible without writing to the tombstone on the table ? I thought TTL > doesn't create tombstones since the ttl is present together with the write > time timestmap > at the row level > > > If you read carefully, you will notice that no tombstone is created and > instead the data is *converted* into a tombstone. So, after the TTL has > expired, the inserted data effectively acts as a tombstone. This is needed, > because the now expired data might hide older data that has not expired > yet. If the newer data was simply dropped after the TTL expired, older data > might reappear. > > If I understand it correctly, you can avoid data with a TTL being > converted into a tombstone by choosing a TTL that is greater than > gc_grace_seconds. Technically, the data is still going to be converted into > a tombstone when the TTL expires, but this tombstone will immediately be > eligible for garbage collection. > >
