November 08, 2017 09:02AM
Thank you for your reply.

What I want to solve is that backup servers can be selected when all the
primary servers are unavailable.

Now I use error_page to solve it, but it's not convenient in the case of
multi-servers-locations.
Especially some locations have already config error_page directive.

upstream backends {
hash $uri consistent;
server 10.0.0.1;
server 10.0.0.2;
}

upstream backup {
server 10.0.0.3;
}

server {
...
location / {
error_page 502 504 = @fallback;
proxy_pass http://backends;
}

location @fallback {
proxy_pass http://backup;
}
}

But if hash support backup, it would be handier, such as following.

upstream backends {
hash $uri consistent;
server 10.0.0.1;
server 10.0.0.2;
server 10.0.0.3 backup; # Unfortunately it's now allowed.
}

server {
...
location / {
proxy_pass http://backends;
}
}

Anyway.

1. Can you share the reason for "backup" option is not allowed combined
with the hash module?
2. Is there any problem if I add the flag 'NGX_HTTP_UPSTREAM_BACKUP' in
the hash module?
I know it's not an ideal design.

Thanks again.


On Wed, Nov 8, 2017 at 9:11 PM, Ruslan Ermilov <ru@nginx.com> wrote:

> On Mon, Nov 06, 2017 at 09:35:14PM +0800, 洪志道 wrote:
> > Hi!
> > We know that consistent hash upstream improve its selection in the
> latest
> > version.
> >
> > - if (hp->tries >= points->number) {
> > - pc->name = hp->rrp.peers->name;
> > + if (hp->tries > 20) {
> > ngx_http_upstream_rr_peers_unlock(hp->rrp.peers);
> > - return NGX_BUSY;
> > + return hp->get_rr_peer(pc, &hp->rrp);
> >
> > Does it mean that "backup" option is allowed in the module?
>
> It just means that if, after 20 tries, we weren't able to select
> a peer using the hash algorithm, then we'll continue a selection
> process using the round-robin algorithm. This is also consistent
> with the ip_hash module.
>
> > |NGX_HTTP_UPSTREAM_MAX_CONNS
> > |NGX_HTTP_UPSTREAM_MAX_FAILS
> > |NGX_HTTP_UPSTREAM_FAIL_TIMEOUT
> > + |NGX_HTTP_UPSTREAM_BACKUP
> > |NGX_HTTP_UPSTREAM_DOWN;
>
> We do not support backup servers with ip_hash and hash balancers,
> though there's currently a bypass that allows to have backup
> servers in configurations with hash balancers. But these backup
> servers will be used only when falling back to round-robin, which
> is unlikely.
>
> > I wonder how to archive the effect of "backup" in hash like round robin,
> > even if we don't want to use error_page.
>
> I'm not sure what did you mean here.
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

[upstream] consistent hash support backup?

karton 715 November 06, 2017 08:36AM

Re: [upstream] consistent hash support backup?

ru@nginx.com 474 November 08, 2017 08:12AM

Re: [upstream] consistent hash support backup?

karton 482 November 08, 2017 09:02AM

Re: [upstream] consistent hash support backup?

ru@nginx.com 898 November 08, 2017 03:12PM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 274
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready