*From: *Malcolm Turnbull <malc...@loadbalancer.org> *Sent: * 2014-01-14 07:13:27 E *To: *haproxy@formilux.org <haproxy@formilux.org> *Subject: *Just a simple thought on health checks after a soft reload of HAProxy....
> Just a simple though on health checks after a soft reload of HAProxy.... > > If for example you had several backend servers one of which had crashed... > Then you make make a configuration change to HAProxy and soft reload, > for instance adding a new backend server. > > All the servers are instantly brought up and available for traffic > (including the crashed one). > So traffic will possibly be sent to a broken server... > > Obviously its only a small problem as it is fixed as soon as the > health check actually runs... > > But I was just wondering is their a way of saying don't bring up a > server until it passes a health check? I was just thinking of this issue myself and google turned up your post. Personally I would not like that every server is considered down until after the health checks pass. Basically this would result in things being down after a reload, which defeats the point of the reload being non-interruptive. I can think of 2 possible solutions: 1) When the new process comes up, do an initial check on all servers (just one) which have checks enabled. Use that one check as the verdict for whether each server should be marked 'up' or 'down'. After each server has been checked once, then signal the other process to shut down and start listening. 2) Use the stats socket (if enabled) to pull the stats from the previous process. Use its health check data to pre-populate the health data of the new process. This one has a few drawbacks though. The server & backend names must match between the old and new config, and the stats socket has to be enabled. It would probably be harder to code as well, but I really don't know on that. -Patrick
