The yelp solution I can't do because it requires a newer kernel then I have access to, but the unbounce solution is interesting, I may be able to work up something around that.
On Fri, Jan 22, 2016 at 4:07 AM, Pedro Mata-Mouros <[email protected] > wrote: > Hi, > > Haven’t had the chance to implement this yet, but maybe these links can > get you started: > > > http://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.html > http://inside.unbounce.com/product-dev/haproxy-reloads/ > > It’d be cool to have a sort of “officially endorsed” way of achieving this. > > Best, > > Pedro. > > > > On 22 Jan 2016, at 00:38, CJ Ess <[email protected]> wrote: > > One of our sore points with HAProxy has been that when we do a reload > there is a ~100ms gap where neither the old or new HAproxy processes accept > any requests. See attached graphs. I assume that during this time any > connections received to the port are dropped. Is there anything we can do > so that the old process keeps accepting requests until the new process is > completely initialized and starts accepting connections on its own? > > I've looked into fencing the restart with iptable commands to blackhole > TCP SYNs, and I've looked into the huptime utility though I'm not sure > overloading libc functions is the best approach long term. Any other > solutions? > > > <hist_restart_1.png> > <hist_restart2.png> > > > >
