Thanks Erick I would like to explain how data resurrection can take place with single SSTable deletion.
Consider this case of table with Levelled Compaction Strategy 1. Data A written a long time back. 2. Data A is deleted and tombstone is created. 3. After GC grace tombstone is purgeable. 4. Now the SSTable containing purgeable tombstone in one node is corruputed. 4. The node with corrupt SSTable cannot compact the data and purgeable tombstone 6. From other two nodes Data A is removed after compaction. 7. Remove the corrupt SSTable from impacted node. 8. When you run repair Data A is copied to all the nodes. This table in quesiton is using Levelled Compaction Strategy. Regards Manish On Fri, Feb 14, 2020 at 12:00 PM Erick Ramirez <erick.rami...@datastax.com> wrote: > The log shows that the the problem occurs when decompressing the SSTable > but there's not much actionable info from it. > > I would like to know what will be "ordinary hammer" in this case. Do you >> want to suggest that deleting only corrupt sstable file ( in this case >> mc-1234-big-*.db) would be suffice ? > > > Exactly. I mean if it's just a one-off, why go through the trouble of > blowing away all the files? :) > > I am afraid that this may cause data resurrection (I have prior experience >> with same). > > > Whoa! That's a long bow to draw. Sounds like there's more history to it. > > Note that i am not willing to run the entire node rebuild as it will take >> lots of time due to presence of multiple big tables (I am keeping it as my >> last option) > > > I wasn't going to suggest that at all. I didn't like the sledge hammer > approach. I certainly wouldn't recommend bringing in a wrecking ball. 😁 > > Cheers! >
