This is actually both relatively hard and also potentially straightforward to resolve
It’s hard because you’re going to have to write code because Cassandra can’t do this without customization. It’s straightforward though You have to add a mechanism to sstable scrub that looks for known unsafe timestamps (in the future more than X years) and scrubs them to “now” You’ll want to be safe against the micros/millis difference to pay attention to that. You’ll obviously want to test this extensively before running it in real life > On Jul 15, 2026, at 12:47 AM, Panagiotis Melidis via user > <[email protected]> wrote: > > > Hi all, > > I'm looking for guidance on a scenario involving NTP clock skew and its > impact on Cassandra data. > > If an NTP malfunction causes the system clock on multiple Cassandra nodes to > jump far into the future (e.g., 100 years), any writes processed during that > window will carry far-future timestamps. Once the clock is corrected, these > entries effectively become permanent and shadow any new write/delete in the > affected partition keys. > > The only viable recovery approach at scale I've been able to identify is > truncating the affected tables. > Are there any other known viable recovery procedures that don't require a > full truncate? > Are there any known existing or planned preventive measures in Cassandra to > guard against such scenarios? > > Any pointers to prior discussions, tooling, or patches would be greatly > appreciated. > > Thanks.
