Restarting upstream servers
Joe Van Dyk
joe at pinkpucker.net
Fri May 23 02:19:38 MSD 2008
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
>>
>>
>
>
More information about the nginx
mailing list