On 4/17/2018 3:41 AM, Willy Tarreau wrote:
Here I'm afraid we're all wasting a lot of time trying to guess what
you have in your config that causes the problem. It's OK if you cannot
post your config here, but please at least post a smaller one reproducing
the issue so that we can help you.

I did send a message with the config, but it turns out that it was only in an accidental unicast to Lukas.  Sorry about that! Here is the redacted version of my config (one month expiration):

https://apaste.info/xVwg

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.
This is normally done with the "backup" keyword on server lines.

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.
Then I don't see how it can work for you. It's a bit confusing I'm afraid.

Originally, the "hollywood" entry on the be-cdn-9000 backend (which you can see at the config I linked above) had the backup keyword.  But what I noticed happening was that when planet went down, it took about ten additional seconds (no precise timing was done) for hollywood to go active, and during that time, the client got "no server available" messages.  Removing the backup keyword caused hollywood to be active full time and requests to be load balanced to both servers, so when one server goes down, the other is already active and everything works.

Removing the backup keyword from this particular backend is not a problem, but I do have other backends where I really do want only one server to get requests unless that server goes down.  I would like the highest weight backup server to take over immediately when the primary is marked down, not wait for another timeout to pass.

Thanks,
Shawn


Reply via email to