Hi Andrew, Thanks for the info but I’m afraid I’m not seeing anything here that would affect the issue I’m seeing, and by the way the docs don’t indicate that the cookie names have to match the server names.
That being said, I tried using your settings and am still seeing the issue (see below for new full config). And like I say, this is only an issue with v1.8.1, it works as expected in v1.7.9. defaults mode http option redispatch retries 3 timeout queue 20s timeout client 50s timeout connect 5s timeout server 50s listen stats bind :1936 stats enable stats uri / stats hide-version stats admin if TRUE frontend main bind :9080 default_backend main backend main balance leastconn cookie SERVERID maxidle 30m maxlife 12h insert nocache indirect server server-1-google www.google.com:80 weight 100 cookie server-1-google check port 80 inter 4000 rise 2 fall 2 minconn 0 maxconn 0 on-marked-down shutdown-sessions server server-2-yahoo www.yahoo.com:80 weight 100 cookie server-2-yahoo check port 80 inter 4000 rise 2 fall 2 minconn 0 maxconn 0 on-marked-down shutdown-sessions On Wed, Dec 20, 2017 at 8:57 PM, Andrew Smalley <asmal...@loadbalancer.org> wrote: > Also our cookie line looks as below > > cookie SERVERID maxidle 30m maxlife 12h insert nocache indirect > Andruw Smalley > > Loadbalancer.org Ltd. > > www.loadbalancer.org > +1 888 867 9504 / +44 (0)330 380 1064 > asmal...@loadbalancer.org > > Leave a Review | Deployment Guides | Blog > > > On 20 December 2017 at 20:55, Andrew Smalley <asmal...@loadbalancer.org> > wrote: > > Greg > > > > its just been pointed out your cookies are wrong, they would usually > > match your server name. > > I would change this > > > > server server-1-google www.google.com:80 check cookie google > > server server-2-yahoo www.yahoo.com:80 check cookie yahoo > > > > > > to this > > > > server server-1-google www.google.com:80 check cookie server-1-google > > server server-2-yahoo www.yahoo.com:80 check cookie server-2-yahoo > > > > > > We use something like this as a default server line > > > > server RIP_Name 172.16.1.1 weight 100 cookie RIP_Name check port > > 80 inter 4000 rise 2 fall 2 minconn 0 maxconn 0 on-marked-down > > shutdown-sessions > > Andruw Smalley > > > > Loadbalancer.org Ltd. > > > > www.loadbalancer.org > > +1 888 867 9504 / +44 (0)330 380 1064 > > asmal...@loadbalancer.org > > > > Leave a Review | Deployment Guides | Blog > > > > > > On 20 December 2017 at 20:52, Andrew Smalley <asmal...@loadbalancer.org> > wrote: > >> Hi Greg > >> > >> Apologies I was confused with the terminology we use here, > >> > >> Indeed MAINT should be the same as our HALT feature, > >> > >> Maybe you can share your config and we can see what's wrong? > >> > >> > >> Andruw Smalley > >> > >> Loadbalancer.org Ltd. > >> > >> www.loadbalancer.org > >> +1 888 867 9504 / +44 (0)330 380 1064 > >> asmal...@loadbalancer.org > >> > >> Leave a Review | Deployment Guides | Blog > >> > >> > >> On 20 December 2017 at 20:45, Greg Nolle <greg.no...@voidbridge.com> > wrote: > >>> Hi Andrew, > >>> > >>> I can’t find any reference to a “HALTED” status in the manual. I’m > >>> *not* referring to “DRAIN” though (which I would expect to behave as > >>> you describe), I’m referring to "MAINT", i.e. disabling the backend > >>> server. Here’s the snippet from the management manual to clarify what > >>> I’m referring to: > >>> > >>>> “Setting the state to “maint” disables any traffic to the server as > well as any health checks" > >>> > >>> Best regards, > >>> Greg > >>> > >>> On Wed, Dec 20, 2017 at 8:29 PM, Andrew Smalley > >>> <asmal...@loadbalancer.org> wrote: > >>>> Hi Greg > >>>> > >>>> You say traffic still goes to the real server when in MAINT mode, > >>>> Assuming you mean DRAIN Mode and not HALTED then this is expected. > >>>> > >>>> Existing connections still goto a server while DRAINING but no new > >>>> connections will get there. > >>>> > >>>> If the real server is HALTED then no traffic gets to it. > >>>> > >>>> > >>>> Andruw Smalley > >>>> > >>>> Loadbalancer.org Ltd. > >>>> > >>>> www.loadbalancer.org > >>>> +1 888 867 9504 / +44 (0)330 380 1064 > >>>> asmal...@loadbalancer.org > >>>> > >>>> Leave a Review | Deployment Guides | Blog > >>>> > >>>> > >>>> On 20 December 2017 at 20:26, Greg Nolle <greg.no...@voidbridge.com> > wrote: > >>>>> When cookie persistence is used, it seems that the status of the > >>>>> servers in the backend is ignored in v1.8.1. I try marking as MAINT a > >>>>> backend server for which my browser has been given a cookie but > >>>>> subsequent requests still go to that server (as verified in the > >>>>> stats). The same issue happens when I use a stick table. > >>>>> > >>>>> I’ve included a simple example config where this happens at the > >>>>> bottom. The exact same config in v1.7.9 gives the expected behaviour > >>>>> that new requests are migrated to a different active backend server. > >>>>> > >>>>> Any ideas? > >>>>> > >>>>> Many thanks, > >>>>> Greg > >>>>> > >>>>> defaults > >>>>> mode http > >>>>> option redispatch > >>>>> retries 3 > >>>>> timeout queue 20s > >>>>> timeout client 50s > >>>>> timeout connect 5s > >>>>> timeout server 50s > >>>>> > >>>>> listen stats > >>>>> bind :1936 > >>>>> stats enable > >>>>> stats uri / > >>>>> stats hide-version > >>>>> stats admin if TRUE > >>>>> > >>>>> frontend main > >>>>> bind :9080 > >>>>> default_backend main > >>>>> > >>>>> backend main > >>>>> balance leastconn > >>>>> cookie SERVERID insert indirect nocache > >>>>> server server-1-google www.google.com:80 check cookie google > >>>>> server server-2-yahoo www.yahoo.com:80 check cookie yahoo > >>>>> > >>>> >
