Re[2]: несколько уровней upstream

[Михаил Монашёв]

Здравствуйте, Maxim.

>> >как сделать такое:
>> >первый запрос - всегда на основной апстрим, при таймауте на него же через
>> >другой порт, и там неудача - на резерв. Последнее через backup, а как
>> >первые два сделать? Второму серверу weight=0?
>> можно ли сделать try_files @first @second @third =404?

> Можно, но оно будет делать не то, о чём вы подумали.  Все 
> аргументы try_files, кроме последнего - это файлы, существование 
> которых будет проверяться на диске.

> Если нужно, чтобы в случае ошибок от бекенда обработка уходила в 
> другой location, то следует пользоваться директивой error_page, 
> см. http://nginx.org/r/error_page/ru.  Там, в частности, есть 
> пример такого вида:

>     location / {
>         error_page 404 = @fallback;
>     }

>     location @fallback {
>         proxy_pass http://backend;
>     }

> Таким образом можно обеспечить произвольную многоуровневую 
> обработку запроса.  Чуть более сложный пример есть в описании 
> модуля memcached, 
> http://nginx.org/ru/docs/http/ngx_http_memcached_module.html:

>     location / {
>         set            $memcached_key "$uri?$args";
>         memcached_pass host:11211;
>         error_page     404 502 504 = @fallback;
>     }

>     location @fallback {
>         proxy_pass     http://backend;
>     }

> В случае, если требуется более одного перенаправления, необходимо 
> также разрешить множественные перенаправления с помощью директивы 
> recursive_error_pages, см.
> http://nginx.org/r/recursive_error_pages/ru.

> Ну и не надо забывать, что явно описанная группа серверов сама по 
> себе обеспечивает опрос нужного количества серверов в случае 
> ошибок, см. http://nginx.org/r/proxy_next_upstream/ru.


В данном случае было бы логично ввести некий новый уровень абстракции,
который  описывал бы поведение в случае ошибок. Сейчас с одной стороны
в  упрощённой форме оно есть в апстриме, с другой стороны оно делается
через  именованные локейшны (которые размывают исходную идею с обычным
локейшнами),   увеличивают   размер   конфига   и/или   ухудшают   его
наглядность.

Не знаю, как часто это нужно юзерам nginx-а, если часто, то можно было
бы  подумать  про  группы апстримов, состоящие из апстримов и описаний
поведения переключения с одного апстрима на другой.

-- 
С уважением,
 Михаил                          mailto:postmaster at softsearch.ru