Restarting upstream servers

[Aníbal Rojas]

Please let us know how it works.

On Fri, May 23, 2008 at 5:49 PM, Joe Van Dyk <joe at pinkpucker.net> wrote:
> That makes perfect sense, thanks!
>
> On Thu, May 22, 2008 at 4:29 AM, Aníbal Rojas <anibalrojas at gmail.com> wrote:
>> I understand you want to prevent the first set of failed request
>> against the restarting upstreams.
>>
>> Ugly but it should work:
>>
>> Modify Nginx configuration, remove the upstream for the first server, signal it.
>> Restart upstream servers in the first server.
>> Modify Nginx configuration, add the restarted upstreams and remove the
>> the ones from the second, signal it.
>> Restart upstream servers in the second server.
>>
>> Nginx reloads configuration very quickly.
>>
>> All this can be easily automated.
>>
>> --
>> Aníbal Rojas
>> http://hasmanydevelopers.com
>> http://rubycorner.com
>> http://anibal.rojas.com
>>
>> On Thu, May 22, 2008 at 9:28 PM, Joe Van Dyk <joe at pinkpucker.net> wrote:
>>> Hi,
>>>
>>> I'm using a bunch of upstream servers and using nginx as a proxy for
>>> them.  The upstreams run on two different machines.
>>>
>>> When I restart the upstreams on one server, I get a bunch of errors like these:
>>>
>>> 2008/05/21 18:02:39 [error] 4658#0: *36236 sendfilev() failed (134:
>>> Transport endpoint is not connected) while sending request to
>>> upstream, client: 209.191.207.182, server: domain.com, URL:
>>> "/feed/products?t=1211418157562", upstream:
>>> "http://10.12.32.192:3021/feed/products?t=1211418157562", host:
>>> "domain.com"
>>>
>>> 2008/05/21 18:02:40 [error] 4645#0: *66641 connect() failed (146:
>>> Connection refused) while connecting to upstream, client:
>>> 136.182.158.129, server: domain.com, URL:
>>> "/uploaded_files/0025/1630/Springboard_midget_size.jpg?1208317017",
>>> upstream: "http://10.12.32.84:3021/uploaded_files/0025/1630/Springboard_midget_size.jpg?1208317017",
>>> host: "static2.domain.com", referrer:
>>> "http://domain.com/puzzles/2110-5-21-2008"
>>>
>>>
>>> Any way to avoid those?  Ideally, since not all the upstreams are
>>> down, when the request to the upstream fails due to connection
>>> problems, I'd like to try the request on a different upstream, so the
>>> user doesn't see anything wrong.
>>>
>>> Joe
>>>
>>>
>>
>>
>
>



-- 
Aníbal