Restarting upstream servers
anibalrojas at gmail.com
Fri May 23 17:00:10 MSD 2008
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
>> On Thu, May 22, 2008 at 9:28 PM, Joe Van Dyk <joe at pinkpucker.net> wrote:
>>> 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: 18.104.22.168, server: domain.com, URL:
>>> "/feed/products?t=1211418157562", upstream:
>>> "http://10.12.32.192:3021/feed/products?t=1211418157562", host:
>>> 2008/05/21 18:02:40 [error] 4645#0: *66641 connect() failed (146:
>>> Connection refused) while connecting to upstream, client:
>>> 22.214.171.124, server: domain.com, URL:
>>> upstream: "http://10.12.32.84:3021/uploaded_files/0025/1630/Springboard_midget_size.jpg?1208317017",
>>> host: "static2.domain.com", referrer:
>>> 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.
More information about the nginx