incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Coli <rc...@eventbrite.com>
Subject Re: Recovering from mystical cassandra errors.
Date Wed, 30 Oct 2013 00:03:08 GMT
On Tue, Oct 29, 2013 at 4:40 PM, Jacob Rhoden <jacob.rhoden@me.com> wrote:

> Im testing out Cassandra with a 2.0.1 install [and having this issue where
> nodes won't start after being stopped]
>

Someone else having what looks like this same issue (in C* 2.0.2 iirc) came
into #cassandra yesterday.

I encourage you to :

1) search the apache cassandra JIRA for an existing ticket on this problem
2) if one does not exist, file a ticket including the error log and as much
info to help reproduce the issue as possible


> Normally I just delete the files and restart the node. If you are in a
> production environment, how do you deal with this type of issue?
>

By not running X.Y.Z in production where Z<= 5.

https://engineering.eventbrite.com/what-version-of-cassandra-should-i-run/

But seriously, in general people nuke node state until the node starts, and
then replace/repair the node.


> (I suspect there may be some sort of bug with replaying commit logs in
> 2.0.1, probably associated with replaying a commit log after you have
> deleted a table, and recreated with a different definition.)
>

This problem exists in general when you DROP and reCREATE tables and
keyspaces.

The workaround is to use TRUNCATE and then ALTER instead of DROP and CREATE.

https://issues.apache.org/jira/browse/CASSANDRA-4857
which references
https://issues.apache.org/jira/browse/CASSANDRA-4221

=Rob

Mime
View raw message