It's actually correct to do it how it is today. Insertion date does not matter, what matters is the time after tombstones are supposed to be deleted. If the delete got to all nodes, sure, no problem, but if any of the nodes didn't get the delete, and you would get rid of the tombstones before running a repair, you might have nodes that still has that data. Then following a repair, that data will be copied to other replicas, and that data you thought you deleted, will be brought back to life.
On Sat, Mar 16, 2024 at 5:39 PM Sebastian Marsching <sebast...@marsching.com> wrote: > > 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. > >
