primary and fallback to backup -- try_files, proxy_pass, upstream?

Denis Arh denis at arh.cc
Sun Feb 14 15:43:55 MSK 2010


What I would like to have is nginx first to try primary service and then to
fallback to the backup if primary is not available.

What I've tried:

1. try_files:


    location /api {
        try_files @primary @backup;
    }


    location @primary {
        proxy_pass http://localhost:81;
    }

    location @backup {
        include        /etc/nginx/fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME  $document_root/boot/api.php;
        fastcgi_pass   unix:/tmp/php-fpm.sock;
    }

This results in nginx only invoking @backup.
If I switch try_files params (try_files @backup @primary) then @primary is
invoked but in case it's not running I get 502 error (error log: 9228#0:
*1850 no live upstreams while connecting to upstream).


2. upstream

upstream backend {
    server localhost:81;
    server unix:/tmp/php-fpm.sock;
}

location /api {
   proxy_pass http://backend;
}

The first part of this solution works -- requests are first passed to
localhost:81 and handled there without any problems and if this one is down
requests go to the second server in the upstream.
What happens there is another 502 error:
error-log: *1840 recv() failed (104: Connection reset by peer) while reading
response header from upstream, client: ......, server: ......, request: "GET
/api HTTP/1.1", upstream: "http://unix:/tmp/php-fpm.sock:/api"

How to configure fastcgi backend propery to handle this properly?



Is there any way to make this work?
If both are possible, which one is better?



-- 
Denis Arh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100214/e370ab62/attachment.html>


More information about the nginx mailing list