Thank you, both Michael and Robert for your suggestions. I actually saw 5760, but we were running on 2.0.0, which it seems like this was fixed in.
That said, I noticed that my Chef scripts were failing to set the broadcast_address correctly, which I'm guessing is the cause of the problem, fixing that and trying a redeploy. I am curious, though, how any of this worked in the first place spread across three AZ's without that being set? -Skye On Sep 25, 2013, at 3:56 PM, Robert Coli <rc...@eventbrite.com> wrote: > On Wed, Sep 25, 2013 at 12:41 PM, Skye Book <skye.b...@gmail.com> wrote: > I have a three node cluster using the EC2 Multi-Region Snitch currently > operating only in US-EAST. On having a node go down this morning, I started > a new node with an identical configuration, except for the seed list, the > listen address and the rpc address. The new node comes up and creates its > own cluster rather than joining the pre-existing ring. I've tried creating a > node both before ad after using `nodetool remove` for the bad node, each time > with the same result. > > What version of Cassandra? > > This particular confusing behavior is fixed upstream, in a version you should > not deploy to production yet. Take some solace, however, that you may be the > last Cassandra administrator to die for a broken code path! > > https://issues.apache.org/jira/browse/CASSANDRA-5768 > > Does anyone have any suggestions for where to look that might put me on the > right track? > > It must be that your seed list is wrong in some way, or your node state is > wrong. If you're trying to bootstrap a node, note that you can't bootstrap a > node when it is in its own seed list. > > If you have installed Cassandra via debian package, there is a possibility > that your node has started before you explicitly started it. If so, it might > have invalid node state. > > Have you tried wiping the data directory and trying again? > > What is your seed list? Are you sure the new node can reach the seeds on the > network layer? > > =Rob
