Re: manually removing sstable

On Wed, Jul 17, 2013 at 1:47 AM, Michał Michalski wrote: > According to my knowledge it's not necessarily true. In a specific case > this patch comes into play: > > https://issues.apache.org/**jira/browse/CASSANDRA-4671 > > "We could however p

Re: manually removing sstable

> https://issues.apache.org/jira/browse/CASSANDRA-4671 Thanks for the tip. A - Aaron Morton Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 17/07/2013, at 8:47 PM, Michał Michalski wrote: > Hi Aaron, > > > * Tombstones will only be purged if all

Re: manually removing sstable

Hi Aaron, > * Tombstones will only be purged if all fragments of a row are in the SStable(s) being compacted. According to my knowledge it's not necessarily true. In a specific case this patch comes into play: https://issues.apache.org/jira/browse/CASSANDRA-4671 "We could however purge tom

Re: manually removing sstable

thanks aaron, the second point I had not considered, and it could explain why the sstables don't always disapear completely, sometimes a small file (but megabytes instead of gigabytes) is left behind. T# On Fri, Jul 12, 2013 at 10:25 AM, aaron morton wrote: > That sounds sane to me. Couple of c

Re: manually removing sstable

That sounds sane to me. Couple of caveats: * Remember that Expiring Columns turn into Tombstones and can only be purged after TTL and gc_grace. * Tombstones will only be purged if all fragments of a row are in the SStable(s) being compacted. Cheers - Aaron Morton Cassandra C

Re: manually removing sstable

a colleague of mine came up with an alternative solution that also seems to work, and I'd just like your opinion on if it's sound. we run find to list all old sstables, and then use cmdline-jmxclient to run the forceUserDefinedCompaction function on each of them, this is roughly what we do (but wi

Re: manually removing sstable

thanks a lot. I can confirm that it solved our problem too. looks like the C* 2.0 feature is perfect for us. T# On Wed, Jul 10, 2013 at 7:28 PM, Marcus Eriksson wrote: > yep that works, you need to remove all components of the sstable though, > not just -Data.db > > and, in 2.0 there is this:

Re: manually removing sstable

yep that works, you need to remove all components of the sstable though, not just -Data.db and, in 2.0 there is this: https://issues.apache.org/jira/browse/CASSANDRA-5228 /Marcus On Wed, Jul 10, 2013 at 2:09 PM, Theo Hultberg wrote: > Hi, > > I think I remember reading that if you have sstabl

Re: manually removing sstable

On Wed, Jul 10, 2013 at 5:09 AM, Theo Hultberg wrote: > I think I remember reading that if you have sstables that you know contain > only data that whose ttl has expired, it's safe to remove them manually by > stopping c*, removing the *-Data.db files and then starting up c* again. is > this corr

Re: manually removing sstable

Theo, We have several CFs that we TTL all columns, set gc_grace=0 and we never overwrite or delete records. We will manually remove sstables from disk during a rolling C* restart process. You'll also want to remove all associated index/filter files with the sst -- so if foo-hf-123-Data.db is > TTL

manually removing sstable

Hi, I think I remember reading that if you have sstables that you know contain only data that whose ttl has expired, it's safe to remove them manually by stopping c*, removing the *-Data.db files and then starting up c* again. is this correct? we have a cluster where everything is written with a