I'm seeing this error on a 0.8.x node again. This node did suffer a crash
and the cassandra data is on a raid0 array. The array was remounted
correctly and the xfs filesystem did not report any issues.
Given that RF=3 I have the following question:
0. Can a storage problem cause this?
1. During re
A little feedback,
I scrubbed on each server and I haven't seen this error again. The load on
each server eems to be correct.
nodetool compactionstats shows boat-load of "Scrub" at 100% on my 3rd node
but not on the 2 others.
I left it that way and haven't restart yet.
2011/9/26 aaron morton
>
Looks like a mismatch between the key the index says should be at a certain
position in the date file and the key that is actually there.
I've not checked but scrub *may* fix this this. Try it and see.
(repair is for repairing consistency between nodes, scrub fixes local issues
with data. )
Juste did
Could there be data corruption or will repairs do this?
Thanks
Le 25 sept. 2011 15:30, "Jonathan Ellis" a écrit :
> Assertion errors are bugs, so that should worry you.
>
> However, I'd upgrade before filing a ticket. There were a lot of
> fixes in 0.8.5.
>
> On Sun, Sep 25, 2011 at 2:2
Assertion errors are bugs, so that should worry you.
However, I'd upgrade before filing a ticket. There were a lot of
fixes in 0.8.5.
On Sun, Sep 25, 2011 at 2:27 AM, Philippe wrote:
> Hello,
> I've seen a couple of these in my logs, running 0.8.4.
> This is a RF=3, 3-node cluster. 2 nodes incl
Hello,
I've seen a couple of these in my logs, running 0.8.4.
This is a RF=3, 3-node cluster. 2 nodes including this one are on 0.8.4 and
one is on 0.8.5
The node is still functionning hours later. Should I be worried ?
Thanks
ERROR [ReadStage:94911] 2011-09-24 22:40:30,043 AbstractCassandraDaem
