> 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.
You are right. I do not understand why it is implemented this way, but you are 100 % correct that it works this way. I thought that gc_grace_seconds is all about being able to repair the table before tombstones are removed, so that deleted data cannot repappear. But when the data has a TTL, it should not matter whether the original data ore the tombstone is synchronized as part of the repair process. After all, the original data should turn into a tombstone, so if it was present on all nodes, there is no risk of deleted data reappearing. Therefore, I think it would make more sense to start gc_grace_seconds when the data is inserted / updated. I don’t know why it was not implemented this way.
smime.p7s
Description: S/MIME cryptographic signature
