https://issues.apache.org/bugzilla/show_bug.cgi?id=55152
Bug ID: 55152
Summary: graceful restart adjusts to new balancer members, but
load balancing does not; fails over to first in list
Product: Apache httpd-2
Version: 2.2.20
Hardware: Macintosh
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_balancer
Assignee: [email protected]
Reporter: [email protected]
Using a load balancer to split traffic roughly evenly between a few servers, I
have a conf block like this:
ProxyPass /munin balancer://balancer-group
ProxyPassReverse /munin balancer://balancer-group
ProxyTimeout 3600
<Proxy "balancer://balancer-group">
BalancerMember http://10.0.1.1:1234/munin route=munin1
BalancerMember http://10.0.1.2:1234/munin route=munin2
BalancerMember http://10.0.1.3:1234/munin route=munin3
# BalancerMember http://10.0.1.4:1234/munin route=munin4
</Proxy>
To find out which worker route the query is taking I have adjusted the log to
be this:
CustomLog "/var/log/apache2/access_log" "%h direct port %p fwd
%{BALANCER_WORKER_ROUTE}e %l %u %t \"%r\" %>s %b %D micsec"
In attempting to add, remove, and maintain the members, I comment out some of
them and uncomment as I bring them offline and online. After adjusting this
conf block I gracefully restart the server with a kill -USR1.
I have noticed that although a graceful restart succeeds in blocking the flow
of traffic to a commented out server, sometimes I got into a situation where
apache would direct traffic only to the first server in the list, ignoring all
the other supposedly live members. When this occurred, the access log would
mention it's attempting to send traffic to "munin4", which was commented out.
Likely it then would default to the first member in the list.
After a full (not graceful) restart of httpd, it succeeded in balancing traffic
between all live members.
It could be a bug that a graceful restart does not successfully restart the
load balancing algorithm, even though it reloads the member configuration
settings. Or if this is intentional, it does not seem to be called out in the
documentation, and causes angst among those trying to debug their setups.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
