On 4/16/2018 1:46 PM, Willy Tarreau wrote:
> On Mon, Apr 16, 2018 at 10:03:44AM -0600, Shawn Heisey wrote:
>> I am curious about why I couldn't use "track".
> "track" means that your current server will always be in the same state
> as the designated one. It will never run its own checks, and will receive
> notifications from the other one's state change events.
>
> So you can simply not have any check-specific stuff on a server tracking
> another one. However if you use disable-on-404 on the tracked one, the
> tracking one will obviously adapt.

Thanks to you and everyone else who has replied.

That didn't work.  I tried to use disable-on-404 on the tracked
backend.  I got the fatal configuration error I mentioned before:

[ALERT] 105/095234 (7186) : config : backend 'be-cdn-9000', server
'planet': unable to use chk-cdn-9000/planet fortracking: disable-on-404
option inconsistency.
[ALERT] 105/095234 (7186) : config : backend 'be-cdn-9000', server
'hollywood': unable to use chk-cdn-9000/hollywood fortracking:
disable-on-404 option inconsistency.
[ALERT] 105/095234 (7186) : Fatal errors found in configuration.

I also tried it with that option in both backend configurations.  That
didn't work either.  I don't recall the error, but it was probably the
same as one of the other errors I had gotten before.

This is on 1.5.12, and I can't really blame you if the "standard" mental
map you keep of the project doesn't include that version.  It's got to
be hard enough keeping that straight for just 1.8 and 1.9-dev!  Maybe
the error I encountered would be solved by upgrading.  Upgrading is on
the (really long) todo list.

I do have a config that works.  I'm no longer tracking another backend,
but doing the health checks in the load-balancing backend.  The whole
reason I had migrated server checks to dedicated back ends was because I
wanted to reduce the number of check requests being sent, and I'm
sharing the check backends with multiple balancing backends in some
cases.  For the one I've been describing, I don't need to share the
check backend.

I ran into other problems on the application side with how process
shutdowns work, but resolved those by adding an endpoint into my app
with the URL path of "/lbdisable" and handling the disable/pause in the
init script instead of the application.  I can now restart my custom
application at will without any loss, and without a client even noticing
there was a problem.

As of a little while ago, I have solved all the problems I encountered
on the road to graceful application restarts except the one where a
backup server is not promoted to active as soon as the primary servers
are all down.  I described that issue in a separate message to the
list.  I do have a workaround to that issue -- I'm no longer using
"backup" on any server entries for this service.

Thanks,
Shawn


Reply via email to