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
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 wrote:
> Because you did a
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 A
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 wrote:
> if i stop
If you shutdown c* and remove an sstable (and it associated data,
index, bloom filter , and etc) files it is safe. I would delete any
saved caches as well.
It is safe in the sense that Cassandra will start up with no issues,
but you could be missing some data.
On Sun, Nov 11, 2012 at 11:09 PM, B.
