There’s two problems with this approach if you need strict correctness 1) after you delete the sstable and before you repair you’ll violate consistency, so you’ll potentially serve incorrect data for a while
2) The sstable May have a tombstone past gc grace that’s shadowing data in another sstable that’s not corrupt and deleting it may resurrect that deleted data. The only strictly safe thing to do here, unfortunately, is to treat the host as failed and rebuild it from it’s neighbors (and again being pedantic here, that means stop the host, while it’s stopped repair the surviving replicas, then bootstrap a replacement on top of the same tokens) > On May 26, 2020, at 4:46 PM, Leon Zaruvinsky <leonzaruvin...@gmail.com> wrote: > > > Hi all, > > I'm looking to understand Cassandra's behavior in an sstable corruption > scenario, and what the minimum amount of work is that needs to be done to > remove a bad sstable file. > > Consider: 3 node, RF 3 cluster, reads/writes at quorum > SStable corruption exception on one node at keyspace1/table1/lb-1-big-Data.db > Sstablescrub does not work. > > Is it safest to, after running a repair on the two live nodes, > 1) Delete only keyspace1/table1/lb-1-big-Data.db, > 2) Delete all files associated with that sstable (i.e., > keyspace1/table1/lb-1-*), > 3) Delete all files under keyspace1/table1/, or > 4) Any of the above are the same from a correctness perspective. > > Thanks, > Leon > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
