On Sat, Aug 28, 2010 at 2:34 PM, Anthony Molinaro <antho...@alumni.caltech.edu> wrote: > I think maybe he thought you meant put a layer between cassandra internal > communication.
No, I took the question to be about client connections. > There's no problem balancing client connections with > haproxy, we've been pushing several billion requests per month through > haproxy to cassandra. > Can it be done: yes. Is it best practice: no. Even 10 billion requests/month is an average of less than 4000 reqs/sec. Just not that many for a distributed database like Cassandra. > we use > > mode tcp > balance leastconn > server local 127.0.0.1:12350 check > > so basically just a connect based check, and it works fine > Cassandra can, and does, fail in ways that do not stop it from answering TCP connection requests. Are you saying it works fine because you have seen numerous types of node failures and this was sufficient? I would be quite surprised if that were so. Using an LB for service discovery is a fine thing (connect to a VIP, call describe_ring, open direct connections to cluster nodes). Relying on an LB to do the right thing when it is totally ignorant of what is going across those client connections (as is implied by simply checking for connectivity) is asking for trouble. Doubly so when you use a leastconn policy (a failing node can spit out an error and close a connection with impressive speed, sucking all the traffic to itself; common problem with HTTP servers giving back errors). b
