I've seen the same behaviour (SLOW ephemeral disk) a few times.
You can't do anything with a single slow disk except not using it.
Our solution was always: Replace the m1.xlarge instance asap and everything is
good.
-Rudolf.
On 31.03.2013, at 18:58, Alexis Lê-Quôc wrote:
Alain,
Can you
Which version of Cassandra has your data been created initially with?
A bug in Cassandra 1.1.2 and earlier could cause out-of-order sstables
and inter-level overlaps in CFs with Leveled Compaction. Your sstables
generated with 1.1.3 and later should not have this issue [1] [2].
In case you
Could you, as Aaron suggested, open a ticket?
Done: https://issues.apache.org/jira/browse/CASSANDRA-4644
Hi,
I'm getting 5 identical assertions while running 'nodetool cleanup' on a
Cassandra 1.1.4 node with Load=104G and 80m keys.
From system.log :
ERROR [CompactionExecutor:576] 2012-09-10 11:25:50,265
AbstractCassandraDaemon.java (line 134) Exception in thread
Hi,
I'm currently testing the restore of a Cassandra 1.1.2 snapshot.
The steps to reproduce the problem:
- snapshot a 3-node production cluster (1.1.2) with RF=3 and LCS (leveled
compaction) == 8GB data/node
- create a new 3-node cluster (node1,2,3)
- stop node1 / copy data (SSTables) from
See https://issues.apache.org/jira/browse/CASSANDRA-4411
The bug is related to LCS (leveled compaction) and has been fixed.
On 16.07.2012, at 20:32, Bryce Godfrey wrote:
This may not be directly related to the upgrade to 1.1.2, but I was running
on 1.1.0 for a while with no issues, and
Stay with 1.1.2 and create your CF with
compaction_strategy_class='SizeTieredCompactionStrategy'
On 16.07.2012, at 22:17, Bryce Godfrey wrote:
Thanks, is there a way around this for now or should I fall back to 1.1.0?
From: Rudolf van der Leeden [mailto:rudolf.vanderlee
