> 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:jbel...@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 <robin....@bluecoat.com> 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
