我们先来介绍下nginx支持的几种信号。下面列出的是主进程可以接收的几种信号。
注意:worker进程也可以接收部分信号,但是它和主进程的信号处理机制有些不同,且主进程支持的信号worker进程不一定支持。
graceful stop的行为是:(1)进程不再监听、接受新的请求;(2)进程继续处理正在处理的请求,但处理完成后销毁。
1. 升级
如果想对一个已运行的nginx实例进行版本升级,或者因为重新编译了一个版本而替换旧版本,可以考虑按照以下一系列过程来平稳、安全地升级。当然,如果直接停止服务不会产生多大影响,直接停掉再启动新版本nginx实例更方便简单。
1.将新版本的nginx命令路径替换掉旧的nginx命令。
通常,对于编译安装的nginx来说,采用软链接的方式比较便捷。例如旧版本的安装路径为/usr/local/nginx-1.12.0,为其建立一个软链接/usr/local/nginx,如果有新版本/usr/local/nginx-1.12.1,只需修改软链接/usr/local/nginx的指向目标为/usr/local/nginx-1.12.1即可。这样/usr/local/nginx/sbin/nginx就会随着软链接的指向改变而指向新nginx程序。
2.对旧nginx实例的主进程发送USR2信号。
kill -USR2 `cat /var/run/nginx/nginx.pid`
该信号提示nginx旧的主进程要升级,并执行新的nginx程序。例如步骤1中,旧的nginx主进程为/usr/local/nginx/sbin/nginx,但其指向的是/usr/local/nginx-1.12.0/sbin/nginx,发送该信号后仍将执行/usr/local/nginx/sbin/nginx,但此时因为软链接目标已改变,使得此时启动的nginx已经是/usr/local/nginx-1.12.1/sbin/nginx程序。
此外,发送该信号后将会切换pid文件,旧的pid文件被重命名为nginx.pid.oldbin,记录的是旧的nginx主进程pid值,新的pid文件为nginx.pid,记录的是新启动的nginx的主进程pid值。
[root@xuexi ~]# ls /var/run/nginx* /var/run/nginx.pid /var/run/nginx.pid.oldbin
3.graceful stop旧的主进程号。kill -QUIT `cat /var/run/nginx/nginx.pid.oldbin`
向旧的主进程号发送QUIT信号,该信号将使得主进程以graceful的方式关闭。这将使得旧的主进程、旧的worker进程不再接受任何新请求,但却会把正在处理过程中的请求处理完毕,然后被销毁退出。
4.更稳妥的方式是先让worker进程graceful stop,在新版本的nginx实例运行一小段时间后如果正常工作,再graceful stop旧的主进程。
kill -WINCH `cat /var/run/nginx/nginx.pid.oldbin` # a period of time goes, graceful stop old master nginx kill -QUIT `cat /var/run/nginx/nginx.pid.oldbin`
在发送WINCH信号给旧的主进程后,旧的worker进程将逐渐退出,但旧的主进程却会保留不退出。
如果发现新版本的nginx实例不满意,可以直接向旧主进程号发送HUP信号,这样旧的主进程就会重新读取配置文件并fork新的worker进程,再将新的主进程号杀掉(可以graceful stop),就可以还原为旧版本的nginx实例。
2.降级
上面第4步其实就是最安全的降级方式。即:
kill -HUP `cat /var/run/nginx/nginx.pid.oldbin` kill -QUIT `cat /var/run/nginx/nginx.pid`
但如果旧的主进程号已经被杀掉了,目前只有新版本的nginx实例在运行,那么只需以升级的步骤进行降级即可。即:
kill -USR2 `cat /var/run/nginx/nginx.pid` kill -QUIT `cat /var/run/nginx/nginx.pid.oldbin`
3.一键升级脚本
以下是升级的脚本。
相关推荐:nginx教程
以上就是怎样平稳安全地升级nginx版本的详细内容,
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)