NGINX smooth restart

A “smooth upgrade” or “hot update” on the reload of Nginx is actually an “upgrade”/” update “configuration, such as adding a new instance to the upstream, rather than a new version of the Nginx process itself. So this reload should actually be called a smooth reboot. Note that the NGINX architecture is master+worker mode, this smooth restart, restart the worker process, the master does not restart. The basic principles of the restart are as follows: Master listens to system signal. If the master listens to system signal HUP, load the configuration file again (the validity of the configuration file will be checked first; if it is invalid, exit “smooth restart” and keep the same), and create several new worker processes N. These new worker processes will start with the new configuration. Note that the new worker process is still listening on the original port (update20210401). There are 2N+1 processes listening on the original port (update20210401). The child process inherits all the content of the parent process, so the child process also listens to the port, there is no port occupation problem. Also, the child does not actually bind, only the parent does bind, so there is no problem with the port being occupied. The master then signals the old process to stop gracefully (turning off port listening and exiting after processing lingering requests). I still end up with N+1 processes. Detailed process reference:

  • Changing Configuration
  • Nginx smooth restart principle

Smooth restart:

  • It simply sends the HUP signal to the new master, which re-reads the configuration and starts several new worker child processes.
  • Finally, the master sends a signal to the old worker to gracefully stop these worker child processes.

2, NGINX smooth upgrade

NGINX smooth upgrade is the process of upgrading NGINX to a new binary, such as from 1.0 to 2.0, without stopping the external service and without affecting the current request. Nginx does hot upgrades by signaling. The master forks a new child by overwriting the old binary with the new binary and sending USER2 to the master. The new child reads the new configuration and creates its own child. The Address already in use error does not occur because the new master is a child of the old master and shares the ServerSocket of the old master. There are 2*(N+1) processes processing the request. At this time, like the old master process to send WINCH signal, so that the old master process like its original N sub process to send signals, so that the old N sub process ServerSocket stop listening, processing the delay request after exit. There are N+1+1 processes in the system (both the old master and the new master). It then sends the QUIT signal to the old master to QUIT the old process. There are N+1 processes in the system. See the overall process for details:

  • Upgrading Executable on the Fly
  • Nginx vs Envoy vs Mosn smoothing

Hot Upgrade is complicated (update20210401) :

  • Sending the USER2 signal to the old master creates a new master process
  • When the new master process starts the new worker process, it sends WINCH signal to the old master process to kill the old worker process
    • If the new master and worker work properly, send the QUIT signal to the old master process. The old master exits and the upgrade is complete.
    • If the new master or worker is abnormal
      • You can send an HUP signal to the old master to start a batch of worker processes (with the old configuration), and then send a QUIT signal to the new master to QUIT the new master and the new worker.
      • You can also send TERM signal to the new master, so that the new master and worker can exit directly. Then the old master automatically starts the new worker process.

Third, summary

It can be found that the smooth upgrade of NGINX is completely based on the inheritance mechanism of old and new processes, which is compatible. No transfer or transfer of socket file descriptors was performed.

When the Nginx worker process exits and returns to the client, it passes a control instruction for the client to close the connection, which is a feature of the HTTP protocol. Otherwise, old worker processes can never exit if the connection is long.

reference

  • Nginx vs Envoy vs Mosn smoothing

Hard advertising

Welcome to the public account: Double6