Shulou(Shulou.com)06/02 Report--

This article mainly explains the "Nginx hot upgrade process", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn the "Nginx hot upgrade process"!

Hot upgrade proc

The first step is to replace the old Nginx with the new Nginx file (binary file). The reason for replacing only the binary file is because in most scenarios, our newly compiled nginx file specifies the corresponding configuration options, such as where is the directory of the configuration file? Where is the directory of log? Must be consistent with the old Nginx, otherwise there is no way to reuse nginx.conf files, if we only replace binary files, please pay attention to backup, in addition, in the new version of Linux, will require when overwriting a file in use with cp-f can be replaced.

Then we send USR2 signals like the old master process, when we notice that we have no way to use nginx-s signal directly through the Nginx command line, because Nginx does not support such a signal so far.

After sending the USR2 signal, the existing master process does the following things: change the pid file name with the suffix .oldbin. Why? This is to make way for the new master process, although master, worker processes can accept signals, but for ease of management, usually do not send signals directly to the worker process, so we rely on the master process, he must save his pid, in order to use the file name pid.bin for the new master, so change the old pid file to pid.oldbin.

Next, start the new master process with the new binaries, so at this point, there will be two master processes and the old worker process, and then the new master process will automatically start the new worker process, so at this point we will find two master processes and multiple worker processes.

Next we are going to send QUIT signals to the old master process. How can we find the old master process? We can see the process number of the master process according to ps, or find the process number of the old master process through the .oldbin file and send a QUIT signal to the process number, then the old master process will gracefully shut down the old worker process, so our hot upgrade ends.

But the old master process has been saved, which is to facilitate us to roll back, that is, found that there is a problem with the new Nginx process, this time because the old master process is still there, you can send HUP signal to the old master process, equivalent to the implementation of a reload, will start the new worker process, and then send QUIT signal to the new master process, that is, the new worker process is required to exit gracefully, and the rollback is realized.

Next, take a look at the specific flow chart of updating Nginx binaries without downtime:

Update Nginx binaries without downtime

At first, the old master process started four green worker processes. When we updated the binary of Nginx, we sent a SIGUSR2 signal to the old master process. At this time, the old master process will rename its pid file. At this time, it can be considered a yellow process.

So how does a new master process start when it is started? He starts a new child process, that is, the new master process is a child of the old master process, but the child process is started using the new binary load, in which the new and old Nginx coexist, but the old master starts to close the listening port, and all the old yellow worker processes begin to exit gracefully, and after completion, there will be a scenario in which only the new master process exists.

When you exit the old master process, you cannot roll back. If you want to roll back, you need to go through the hot upgrade process again, using the backed up old Nginx file as the new hot upgrade file (therefore, it is recommended to back up the old Nginx file).

When a parent process exits and one or more of its child processes are still running, these child processes will be orphaned. The orphan process will be adopted by the init process (process number 1), and the init process will collect the status of them. So when the old master process exits, the new master process does not exit.

Thank you for your reading, the above is the content of "Nginx hot upgrade process", after the study of this article, I believe you have a deeper understanding of the process of Nginx hot upgrade, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.