You can also kick off a user defined compaction via JMX. 

https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionManagerMBean.java#L58

This will allow you to compact big files, medium files, and teeny tinny little 
files.

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 13/11/2012, at 7:46 AM, B. Todd Burruss <bto...@gmail.com> wrote:

> thx, i was pretty sure it would be ok (from a cassandra point of view)
> to remove it, but needed to check.
> 
> voted up.  i like having tools, but i think a few more dials to play
> with to control compaction would be nice too
> 
> On Mon, Nov 12, 2012 at 9:01 AM, Edward Capriolo <edlinuxg...@gmail.com> 
> wrote:
>> Because you did a major compaction that table is larger then all the
>> rest. So it will never go away until you have 3 other tables about
>> that size or you run major compaction again.
>> 
>> You should vote on the ticket:
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-4766
>> 
>> On Mon, Nov 12, 2012 at 11:51 AM, Jason Wee <peich...@gmail.com> wrote:
>>> The existence of sstable X will give an impact to the system or cluster?
>>> when the compaction threshold is reach, the sstable x and sstable y will be
>>> compacted. it's more like the system responsibility than human intervention.
>>> 
>>> 
>>> On Mon, Nov 12, 2012 at 12:09 PM, B. Todd Burruss <bto...@gmail.com> wrote:
>>>> 
>>>> if i stop a node and remove an SSTABLE, let's call it X, is that safe?
>>>> 
>>>> ok, more info.  i know that the data in SSTABLE X has been tombstoned
>>>> but the tomstones are in SSTABLE Y.  i want to simply delete X and get
>>>> rid of the data.
>>>> 
>>>> how do i know this .. i did a major compaction a while back and the
>>>> SSTABLE is so large it has not yet been compacted.  we "delete" data
>>>> daily and only keep 7 days of data.  the SSTABLE is almost 30 days
>>>> old.
>>>> 
>>>> whattayathink?
>>> 
>>> 

Reply via email to