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