I’m using Nginx as a reverse proxy and loadbalancer with 2 backends.
Sometimes I need to turn off one of the apps server. And I need to do it
gracefully, that when I comment one server in Nginx config, Nginx master
process starts to send new requests to new server, but old requests and
sessions stay in old server. I tried to use down, but it loses sessions.
Then tried use kill -HUP, but Nginx immediately loads new config and
closes old sessions and redirects them to new server. Thanks for help.
On Mon, Oct 07, 2013 at 10:08:48AM +0200, Aivaras La wrote:
Hi all!
I’m using Nginx as a reverse proxy and loadbalancer with 2 backends.
Sometimes I need to turn off one of the apps server. And I need to do it
gracefully, that when I comment one server in Nginx config, Nginx master
process starts to send new requests to new server, but old requests and
sessions stay in old server. I tried to use down, but it loses sessions.
Then tried use kill -HUP, but Nginx immediately loads new config and
closes old sessions and redirects them to new server. Thanks for help.
On kill -HUP nginx does a gracefull shutdown of old worker
processes. That is, all requests being handled by old worker
processes are continue to work till they are complete. No
requests are lost and/or unexpectedly terminated. Details on
reconfiguration process can be found here:
On Mon, Oct 07, 2013 at 10:08:48AM +0200, Aivaras La wrote:
Hi all!
I’m using Nginx as a reverse proxy and loadbalancer with 2 backends.
Sometimes I need to turn off one of the apps server. And I need to do it
gracefully, that when I comment one server in Nginx config, Nginx master
process starts to send new requests to new server, but old requests and
sessions stay in old server. I tried to use down, but it loses sessions.
Then tried use kill -HUP, but Nginx immediately loads new config and
closes old sessions and redirects them to new server. Thanks for help.
On kill -HUP nginx does a gracefull shutdown of old worker
processes. That is, all requests being handled by old worker
processes are continue to work till they are complete. No
requests are lost and/or unexpectedly terminated. Details on
reconfiguration process can be found here:
I’ll try to explain my example:
In my config I have upstream with 1 backend, then I change that 1
backend server IP address ( I put something I don’t need (just for
example) like local news page). Then I try to access Nginx (with old
config) which starts to load my big page. When page is loading I did HUP
signal and then my page wasn’t completed. New workers spawned and old
workers quitted at the same second. Nobody was waiting. Is there a
possibility that old workers wait much longer? Or somehow to change
backend servers with serving old sessions? Thanks for help!
On Tue, Oct 08, 2013 at 10:33:38AM +0200, Aivaras La wrote:
process starts to send new requests to new server, but old requests and Controlling nginx
I’ll try to explain my example:
In my config I have upstream with 1 backend, then I change that 1
backend server IP address ( I put something I don’t need (just for
example) like local news page). Then I try to access Nginx (with old
config) which starts to load my big page. When page is loading I did HUP
signal and then my page wasn’t completed. New workers spawned and old
workers quitted at the same second. Nobody was waiting. Is there a
possibility that old workers wait much longer? Or somehow to change
backend servers with serving old sessions? Thanks for help!
From your description of the problem I tend to think that by
“loading a big page” you mean a page with many external resources
(like images, etc.), and your new nginx configuration isn’t able
to handle requests to these resources.
This is not going to work. As you probably heard before, HTTP is
a stateless protocol. This means that in terms of HTTP there is
no such a thing as a “session”, or “page loading”. The only thing
HTTP knows about is a request. That is, nginx guarantees that requests are handled correctly according to a configuration it
has. But nginx doesn’t know that your browser didn’t loaded some
of the external resources it needs yet, and your new configuration
can’t handle requests to these resources.
Correct approach to your problem is to use a configuration that
can handle requests all the time, instead of breaking it at some
point.