> If your ops team really can't be trusted with "push this new config file out" then that should be a separate tool. One that leaves a boot print? ;) I agree in principal, I've just grown cautious over the years. > Again, there are standard solutions for this. Use one. :) round robin dns, haproxy, ... *sigh*, I guess I didn't mention I'm alone on this evaluation project. Meh, automatic failover can wait for when I get sign-off. :) Thanks, Robin. -----Original Message----- From: Jonathan Ellis [mailto:jbellis@gmail.com] Sent: December 3, 2009 5:30 PM To: cassandra-user@incubator.apache.org Subject: Re: data modeling question On Thu, Dec 3, 2009 at 4:23 PM, Coe, Robin wrote: > I *think* I like the idea of Cassandra pushing a CF change to its peers, as opposed to managing it by a separate admin task, simply because I wouldn't want a change managed by an application admin to be missed because of bad communication, forgetfulness, etc., with the Ops team. Managing this w/in cassandra is bad separation of concerns. If your ops team really can't be trusted with "push this new config file out" then that should be a separate tool. > So, considering that I currently have to take down a node to make a CF change, I'm wondering how to perform automatic failover from my application?  Is there a mechanism by which I can request from Cassandra all the destination IP:ports for the nodes in a cluster, so I can adapt dynamically? Again, there are standard solutions for this. Use one. :) round robin dns, haproxy, ... -Jonathan