cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Talbot <btal...@aeriagames.com>
Subject Re: repair, compaction, and tombstone rows
Date Thu, 01 Nov 2012 21:04:26 GMT
It seems like CASSANDRA-3442 might be an effective fix for this issue
assuming that I'm reading it correctly.  It sounds like the intent is to
automatically compact SSTables when a certain percent of the columns are
gcable by being deleted or with expired tombstones.  Is my understanding
correct?

Would such tables be compacted individually (1-1) or are several eligible
tables selected and compacted using the STCS compaction threshold bounds?

-Bryan


On Thu, Nov 1, 2012 at 9:43 AM, Rob Coli <rcoli@palominodb.com> wrote:

> On Thu, Nov 1, 2012 at 1:43 AM, Sylvain Lebresne <sylvain@datastax.com>
> wrote:
> > on all your columns), you may want to force a compaction (using the
> > JMX call forceUserDefinedCompaction()) of that sstable. The goal being
> > to get read of a maximum of outdated tombstones before running the
> > repair (you could also alternatively run a major compaction prior to
> > the repair, but major compactions have a lot of nasty effect so I
> > wouldn't recommend that a priori).
>
> If sstablesplit ("reverse compaction") existed, major compaction would
> be a simple solution to this case. You'd major compact and then split
> your One Giant SSTable With No Tombstones into a number of smaller
> ones. :)
>
> https://issues.apache.org/jira/browse/CASSANDRA-4766
>
> =Rob
>
> --
> =Robert Coli
> AIM&GTALK - rcoli@palominodb.com
> YAHOO - rcoli.palominob
> SKYPE - rcoli_palominodb
>

Mime
View raw message