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

2013-07-09 Пенетрантность Maxim Dounin
Hello! On Tue, Jul 09, 2013 at 12:10:14PM +0400, Андрей Урядов wrote: Сделал так, как советовали: после старта бэкенд говорит фронтенду, что надо перечитать конфигурацию. Но в логах почему-то даже после перечитывания появляются ошибки: (110: Connection timed out) while connecting to

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

2013-06-17 Пенетрантность Андрей Урядов
Да 17 июня 2013 г., 17:53 пользователь Maxim Dounin mdou...@mdounin.ruнаписал: Hello! On Mon, Jun 17, 2013 at 04:09:19PM +0400, Андрей Урядов wrote: Всем привет. Столкнулся с интересным поведением директивы max_fails в upstream. Версия nginx 1.2.6. Опишу ситуацию. 1. Nginx

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

2013-06-17 Пенетрантность Андрей Урядов
Если продолжают происходить ошибки - значит, он как-то странно восстановился. Возможно, у него в процессе поменялся ip-адрес? Это бы объяснило, почему после рестарта nginx его увидел. Дело в том, что эти 2 сервера - aws-инстансы. Внешний ip-адрес у них постоянный, а вот внутренний - может

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

2013-06-17 Пенетрантность Андрей Урядов
Понятно, спасибо. Видимо, самым дешевым вариантом будет прописывание в cron перечитывания конфигурации каждый час + ручное перечитывание каждый раз после сбоя. Тогда, даже если забыть руками перечитать конфигурацию, через час она перечитается. Я так понимаю, это дешевая операция? 17 июня 2013

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

2013-06-17 Пенетрантность Maxim Dounin
Hello! On Mon, Jun 17, 2013 at 06:32:29PM +0400, Андрей Урядов wrote: Понятно, спасибо. Видимо, самым дешевым вариантом будет прописывание в cron перечитывания конфигурации каждый час + ручное перечитывание каждый раз после сбоя. Тогда, даже если забыть руками перечитать конфигурацию, через