(repair would be done after all the nodes with obviously deletable sstables were deleted) (we may then do a purge program anyway) (this would seem to get rid of 60-90% of the purgable data without incurring a big round of tombstones and compaction)
On Tue, May 7, 2019 at 12:05 PM Carl Mueller <carl.muel...@smartthings.com> wrote: > Last my googling had some people doing this back in 2.0.x days, and that > you could do it if you brought a node down, removed the desired sstable > #'s artifacts (Data/Index/etc), and then started up. Probably also with a > clearing of the saved caches. > > A decent-ish amount of data (256G) in a 2.1 cluster we are trying to > upgrade has about 60-70% of the data that could be purged. > > The data has only partition keys (no column key) and is only written once. > So the sstables that are expired don't have data leaking across other > sstables. > > So can we do this: > > 1) bring down node > 2) remove an sstable with obviously old data (we use sstablemetadata tools > to doublecheck) > 3) clear saved caches > 4) start back up > > And then repair afterward? > > The table is STCS. We are trying to avoid writing a purge program and > prompting a full compaction. >
