Re: upstream max_fails и упавшие сервера

Андрей Урядов anuryadov at gmail.com
Tue Jul 9 08:10:14 UTC 2013


Сделал так, как советовали: после старта бэкенд говорит фронтенду, что надо
перечитать конфигурацию. Но в логах почему-то даже после перечитывания
появляются ошибки: (110: Connection timed out) while connecting to
upstream, причем указан ip бэкенда не из списка текущих - видимо, старый
остался. Причем, такое повторяется через несколько минут после
перечитывания конфигурации. Хотя, эти ошибки явно одиночные - проявляются
только для нескольких клиентов, у остальных все нормально работает. Это
результаты какого-то кэширования? Потому что запрос от клиента на nginx
пришел явно после того, как конфигурация уже была перечитана.


17 июня 2013 г., 18:46 пользователь Maxim Dounin <mdounin at mdounin.ru>написал:

> Hello!
>
> On Mon, Jun 17, 2013 at 06:32:29PM +0400, Андрей Урядов wrote:
>
> > Понятно, спасибо.
> > Видимо, самым дешевым вариантом будет прописывание в cron перечитывания
> > конфигурации каждый час + ручное перечитывание каждый раз после сбоя.
> > Тогда, даже если забыть руками перечитать конфигурацию, через час она
> > перечитается. Я так понимаю, это дешевая операция?
>
> Это зависит от структуры нагрузки.  Если есть длинные запросы - то
> старые рабочие процессы могут долго не завершаться.  В общем
> случае - я бы скорее смотрел в сторону init-скриптов на бекендах,
> уведомляющих фронтенд, что ему надо перечитать конфигурацию.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130709/24946383/attachment.html>


Подробная информация о списке рассылки nginx-ru