Nginx版本平滑迁移方案

1. 最可靠方案：make install后，先-s stop再重启，100%确保版本切换
2. 特殊情况：当发现nginx.pid.oldbin文件时，才考虑使用USR2信号无损升级
3. 避坑重点：make install只是替换文件，必须重启才能加载新版本

查看内存中的nginx版本 （直接sbin目录下./nginx -v 无法保证绝对准确 ）：
$(readlink/proc/$(cat /usr/local/nginx/logs/nginx.pid 2>/dev/null || pgrep -f “nginx: master” | head -1)/exe) -v 2>&1

升级过程：./configure ****** ,只是做了依赖库以及安装路径配置 、不影响现运行的nginx

其次就是：make也不影响 ，make仅编译 、还有make install 仅会替换nginx中的nginx ，如果和旧版路径不一样 、完全不影响

---

📌 标准升级流程（推荐所有用户）

1. 安全停止旧版本

make install 后，会生成新的nginx文件  、这个时候./nginx -v显示是新版，但内存中是旧版、所以需要stop 然后重启

# 强制停止Nginx（会中断连接）
sudo /usr/local/nginx/sbin/nginx -s stop

# 确认进程已退出
ps aux | grep nginx | grep -v grep

2. 启动新版本

sudo /usr/local/nginx/sbin/nginx

# 验证新版本
/usr/local/nginx/sbin/nginx -v

3. 双重验证

# 检查内存中实际运行的版本
$(readlink /proc/$(cat /usr/local/nginx/logs/nginx.pid)/exe) -v

# 检查网络响应版本
curl -sI http://localhost | grep Server

---

⚠️ 特殊情况处理

当出现nginx.pid.oldbin时

# 1. 使用USR2信号启动新进程
sudo kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)

# 2. 等待5秒（观察error.log是否出现新worker）
tail -f /usr/local/nginx/logs/error.log

# 3. 优雅关闭旧进程
sudo kill -QUIT $(cat /usr/local/nginx/logs/nginx.pid.oldbin)

---

🔍 关键问题解答

Q：为什么不能直接make install就完成升级？

A：因为Linux运行的是内存中的进程，磁盘文件替换不影响已运行的程序

Q：哪些版本会产生nginx.pid.oldbin？

A：Nginx 1.11.6+ 且编译时未禁用--with-pid-path选项的版本

Q：如何确认是否需要USR2方案？

# 检查PID目录是否有写权限
test -w /usr/local/nginx/logs && echo "可用USR2方案" || echo "需stop-restart"

---

💀 必须避免的三大错误

误用-s reload

sudo nginx -s reload  # 只重载配置，不切换版本！

不验证真实版本

nginx -v  # 只显示磁盘文件版本，非运行版本！

直接kill进程

sudo pkill nginx  # 会导致请求中断！

---

🛡️ 回滚方案

# 1. 恢复旧版二进制
sudo cp /usr/local/nginx/sbin/nginx.old /usr/local/nginx/sbin/nginx

# 2. 重启服务
sudo /usr/local/nginx/sbin/nginx -s stop
sudo /usr/local/nginx/sbin/nginx

---

📊 操作对比表

操作方式	版本切换	连接中断	复杂度	推荐场景
stop + restart	✅ 是	❌ 是	⭐	所有常规升级
USR2信号	✅ 是	✅ 否	⭐⭐⭐	出现.pid.oldbin时

---

✅ 最佳实践总结

1. 常规升级：直接stop+restart最可靠
2. 特殊场景：发现nginx.pid.oldbin时才用USR2方案
3. 必须验证：用/proc/$PID/exe确认内存中的真实版本

记住：make install只是开始，重启才是切换的关键！