How to upgrade smoothly in nginx operation and maintenance

You can replace the old nginx executable with the new one without interrupting service - new requests will not be lost (when upgrading to a new version or adding/removing server modules). (Recommended learning: nginx operation and maintenance)

First, use the new executable program to replace the old one (it is best to make a backup), and then send the USR2 (kill-USR2pid) signal to the main process.

The main process will rename its .pid file to .oldbin (for example: /usr/local/nginx/logs/nginx.pid.oldbin), then execute the new executable program, and start the new main process and new work in sequence process:

PIDPPIDUSER%CPUVSZWCHANCOMMAND

​331261root0.01164pausenginx:masterprocess/usr/local/nginx/sbin/nginx

3313433126nobody0.01368kqreadnginx:workerprocess(nginx)

3313533126nobody0.01380kqreadnginx:workerprocess(nginx)

3313633126nobody0.01368kqreadnginx:workerprocess(nginx)

​3626433126root0.01148pausenginx:masterprocess/usr/local/nginx/sbin/nginx

3626536264nobody0.01364kqreadnginx:workerprocess(nginx)

3626636264nobody0.01364kqreadnginx:workerprocess(nginx)

3626736264nobody0.01364kqreadnginx:workerprocess(nginx)

At this time, two nginx instances will run at the same time and process incoming requests together. To phase out the old instance, you must send the WINCH signal to the old master process, and then its worker processes will begin to gracefully shut down:

PIDPPIDUSER%CPUVSZWCHANCOMMAND

​331261root0.01164pausenginx:masterprocess/usr/local/nginx/sbin/nginx

3313533126nobody0.01380kqreadnginx:workerprocessisshuttingdown(nginx)

​3626433126root0.01148pausenginx:masterprocess/usr/local/nginx/sbin/nginx

3626536264nobody0.01364kqreadnginx:workerprocess(nginx)

3626636264nobody0.01364kqreadnginx:workerprocess(nginx)

3626736264nobody0.01364kqreadnginx:workerprocess(nginx)

After a period of time, the old worker process processes all connected requests and then exits, and only the new worker process handles the incoming requests:

PIDPPIDUSER%CPUVSZWCHANCOMMAND

​331261root0.01164pausenginx:masterprocess/usr/local/nginx/sbin/nginx

​3626433126root0.01148pausenginx:masterprocess/usr/local/nginx/sbin/nginx

3626536264nobody0.01364kqreadnginx:workerprocess(nginx)

3626636264nobody0.01364kqreadnginx:workerprocess(nginx)

3626736264nobody0.01364kqreadnginx:workerprocess(nginx)

At this time, because the old server has not yet closed the socket it is listening on, you can still restore the old server by following the following steps:

Send HUP signal to the old master process - it will start its worker process without reloading the configuration file

Send the QUIT signal to the new main process, requiring it to calmly shut down its working process

Send TERM signal to the new main process to force it to exit

If the new worker process cannot exit for some reason, send it a KILL signal

After the new main process exits, the old main process will remove the .oldbin prefix and restore it to its .pid file. In this way, everything will be restored to what it was before the upgrade.

If the upgrade attempt is successful and you also want to keep the new server, send a QUIT signal to the old main process to exit and leave only the new server running:

PIDPPIDUSER%CPUVSZWCHANCOMMAND

​362641root0.01148pausenginx:masterprocess/usr/local/nginx/sbin/nginx

3626536264nobody0.01364kqreadnginx:workerprocess(nginx)

3626636264nobody0.01364kqreadnginx:workerprocess(nginx)

3626736264nobody0.01364kqreadnginx:workerprocess(nginx)

The above is the detailed content of How to upgrade smoothly in nginx operation and maintenance. For more information, please follow other related articles on the PHP Chinese website!