You would need to swap your class from the com.jeffjirsa variant (probably from 2.1 / 2.2) to the official TWCS class.
Once that happens I suspect it'll happen quite quickly, but I'm not sure. On Wed, Mar 27, 2019 at 7:30 AM Nick Hatfield <nick.hatfi...@metricly.com> wrote: > Awesome, thank you Jeff. Sorry I had not seen this yet. So we have this > enabled, I guess it will just take time to finally chew through it all? > > > > *From:* Jeff Jirsa [mailto:jji...@gmail.com] > *Sent:* Tuesday, March 26, 2019 9:41 PM > *To:* user@cassandra.apache.org > *Subject:* Re: TWCS Compactions & Tombstones > > > > Or Upgrade to a version with > https://issues.apache.org/jira/browse/CASSANDRA-13418 and enable that feature > > > > -- > > Jeff Jirsa > > > > > On Mar 26, 2019, at 6:23 PM, Rahul Singh <rahul.xavier.si...@gmail.com> > wrote: > > What's your timewindow? Roughly how much data is in each window? > > > > If you examine the sstable data and see that is truly old data with little > chance that it has any new data, you can just remove the SStables. You can > do a rolling restart -- take down a node, remove mc-254400-* and then start > it up. > > > > > rahul.xavier.si...@gmail.com > > > > http://cassandra.link > > > > > > > > On Tue, Mar 26, 2019 at 8:01 AM Nick Hatfield <nick.hatfi...@metricly.com> > wrote: > > How does one properly rid of sstables that have fallen victim to > overlapping timestamps? I realized that we had TWCS set in our CF which > also had a read_repair = 0.1 and after correcting this to 0.0 I can clearly > see the affects over time on the new sstables. However, I still have old > sstables that date back some time last year, and I need to remove them: > > > > Max: 09/05/2018 Min: 09/04/2018 Estimated droppable tombstones: > 0.8832057909932046 13G Mar 26 11:34 mc-254400-big-Data.db > > > > > > What is the best way to do this? This is on a production system so any > help would be greatly appreciated. > > > > Thanks, > >
