On Tue, 2 Dec 2008, Jim Jones wrote:
> Hello Willy and list,
> We're running haproxy with (roughly) the following config:
> listen foo 0.0.0.0:8080
> balance leastconn
> cookie C insert indirect nocache
> option persist
> option redispatch
> option allbackups
> option httpchk HEAD /test HTTP/1.0
> fullconn 200
> server www1 192.168.0.1 weight 1 minconn 3 maxconn 100 cookie A check inter 5000
> server www2 192.168.0.2 weight 1 minconn 3 maxconn 100 cookie B check inter 5000
> server www3 192.168.0.3 weight 1 minconn 3 maxconn 100 cookie C check inter 5000
> server bu1 192.168.0.10 weight 1 minconn 3 maxconn 100 check inter 20000 backup
> When we shut down all www servers (www1-www3) haproxy will shortly after
> route requests to the backup server - just as intended.
> Our problem is that *during* the failover some requests will get a 503
> response from haproxy: "No server available to serve your request".
This is simply because haproxy needs some time to detect and mark all the active servers (www1-www3) down and to activate the backup one (bu1).
> More precisely: When we shut down all www servers and then make a
> request before the 5 second timeout has elapsed this request will
> receive the 503 response.
It should take even longer (fall*inter = 3*5s=15s). However, you may use "fastinter 1000" to make it much shorter.
> Is there a way to avoid this gap and make the failover
> completely transparent?
Currently backup servers are only activated if there are no other active servers, moreover redispatcher (option redispatch) does not redispatch to an inactive backup server. I have a patch that mitigates this behavior but as it was a quick&dirty solution I have never intended to make public, but now I think I'll get on this, clean it and post it here. ;)
Krzysztof Olędzki Received on 2008/12/02 20:12
This archive was generated by hypermail 2.2.0 : 2008/12/02 20:15 CET