Re: killing persisent conections on backends marked down?

Hi,

On Thu, Feb 25, 2010 at 10:54:35PM +0100, XANi wrote:
> Dnia 2010-02-25, czw o godzinie 16:27 -0500, Greg Gard pisze:
>
> > hi willy and friends,
> >
> > i am working on a set of ruby scripts to do database failover and
> > stonith. so far all is working pretty well, but i have a few issues:
> >
> > 1) rails makes persistent connections to the backend database so when
> > a server is marked down, the connection remains ongoing. currently, i
> > deal with this by issuing a "stonith" command in my ruby "driver"
> > script for haproxy that shuts the backend down explicitly via ssh, but
> > it would be nice if i could rely on haproxy to kill the connection
> > explicitly. is there a setting to make haproxy kill existing
> > connections on a backend going down?
> >
> > 2) for rails i have tcp timeout set to 0 so it seems to be handling
> > the persistent connections ok, but when i do a reload using the
> > haproxy init script in the debian packages, i end up with two haproxy
> > backends as the persistent connections aren't killed. essentially the
> > original process is waiting for the connections to end before it kills
> > itself, but that will never happen with rails db connection. any ideas
> > or suggestions?
> >
> > ps: having rails not use persistent connections is not really what i
> > would like to do right now. i have run that in the past on production
> > and had wierd timeout problems and choppy connectivity.
> >
> > thanks...gg
> >
>
>
> 1) If i remember correctly client/server timeouts only trigger when
> there is no activity (no data send) so setting client and server timeout
> to like 5 min could solve problem
> so as long as app do some queries connection won't be dropped

Exactly. It is wrong to set infinite timeouts, it will always cause trouble. Still we see people using them from time to time, despite the huge annoying warning upon config reload.

> 2) u can do "/etc/init.d/haproxy stop ; /etc/init.d/haproxy start"

The correct timeout will also take care of that because the connections will eventually die and the old process exit.

This situation is the perfect illustration of why it's wrong to run with no timeouts.

Regards,
Willy Received on 2010/02/26 00:24