2023年3月17日 周五
突然发现cow站点服务器nginx报 504 Gateway Time-out ，同时请求页面向服务器发送请求后长时间等待中。同时站点的两个独立应用，分别在两个域名下都无法正常访问。
1.登入主机
nginx -t
发现nginx正常
nginx -s reload
重启nginx后，错误仍然存在，结合error code基本确定和nginx无关。查看监控发现也没用高负载，或者硬件、网络上的特殊情况。
2.重启实例后，发现服务器能够响应chat.milkmilk.tech，但是wordpress报数据库连接出错:
Error establishing a database connection wodpree
3.发现，重启后mysql没有正常启动：
这时通过
service mysql start
无法启动，提示没有命令。
这里service命令本质是：调用/etc/init.d目录下的脚本文件，所以参数就是脚本文件名，只要去目录看一眼就行。应该是：
service mysqld start
4.此时，在看到mysql常用的data路径下没找到data，于是准备重装db，执行：
yum install mariadb
5.继续尝试systemctl命令启动，还是失败，查看错误日志发现缺少大量表，然后查看my.ini。
关于systemctl命令：《Systemd 入门教程：命令篇》
这时才发现，my.conf被覆盖为全新的config，更加无法正常启动db。
6.于是，还是继续找mysql data的路径从wp_config中，看到数据库名：
find / -name db_name
最后，找到了data目录，发现数据都正常还在。
修改完my.conf后，通过mysql安装目录/bin下的，二进制文件启动mysql
sudo /www/server/mysql/bin/mysqld_safe &
正常启动mysql
总结：
重启后服务应该就正常了，只是因为mysql没有设置服务开机自启动，启动一下就好。
systemctl enable mysqld.service
但是由于缺少对systemctl和service命令以及mysql安装目录的了解导致绕了一圈。
2023年3月20日 周一
再次出现同样问题，开始解决：
1.find / -name access.log
发现nginx等日志目录在XXX路径下，排查后看两个域名的error log发现跟本地9000端口有关
2023/03/20 19:18:09 [error] 1908#0: *7250 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 203.205.141.110, server: milkmilk.tech, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "milkmilk.tech"
2023/03/20 18:54:35 [error] 1907#0: *7242 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 94.102.51.9, server: wordpress.local, request: "GET / HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "yes.bet"
2.查看9000端口使用情况
[lighthouse@VM-0-10-centos ~]$ sudo lsof -i:9000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
php-fpm 1670 root 7u IPv4 17207 0t0 TCP VM-0-10-centos:cslistener (LISTEN)
php-fpm 2499 nobody 5u IPv4 17207 0t0 TCP VM-0-10-centos:cslistener (LISTEN)
php-fpm 2587 nobody 5u IPv4 17207 0t0 TCP VM-0-10-centos:cslistener (LISTEN)
php-fpm 2590 nobody 5u IPv4 17207 0t0 TCP VM-0-10-centos:cslistener (LISTEN)
3.看来是php-fpm组件异常，符合504的报错逻辑，同时两个后端都是php服务，询问chatgpt报错日志。
这些错误消息表明，上游服务器（在本例中是运行在本地主机上端口9000的FastCGI服务器）没有在超时期限内响应。这可能是由于各种原因引起的，例如网络拥塞、服务器负载过重或配置错误。要解决此问题，您可能需要调整超时设置、优化服务器资源或排除任何网络或软件问题。
4.查看7天内日志没发现负载过高的情况
总结：
重启后服务恢复，没什么排查头绪。等待后续，如果有问题再继续优化吧～