周六公司云主机迁移，部分云业务迁移到了新的平台，迁移采用的是数据硬盘迁移，不涉及IP地址的更换，我这边负责的平台所有测试服务器全部重启了，服务也全都停了，周一来了就开始恢复，服务架构是Spring Cloud。过程中遇到了一些问题，全部是配置文件依赖服务器中配置文件的相关服务，脚本提供配置或者配置在应用本身或者远程服务的未受影响。相关处理过程记录一下。
1.启动基础服务，相关配置直接写在启动脚本中，一共是五个服务，eurekaServer、config、gateway、gen、auth，启动过程中auth服务失败了，其它四个都成功了没问题，打开启动日志，查看是druid连接池报错，获取数据源失败了，应该是oracle服务也停了，所以失败，然后想到auth依赖redis，所以顺手先把redis启动了，连接到redis服务器，没什么特殊配置，直接redis-server /etc/redis.conf命令启动成功，然后nginx命令直接启动了nginx也启动成功没什么问题。
2.启动备件业务程序，直接启动，部分配置也是写在启动脚本中，没什么问题，直接启动成功，尝试访问了一下测试环境地址，报auth相关的错，auth服务请求失败
3.启动oracle。root用户，lsnrctl status查看oracle监听状态，确认监听没有启动，lsnrctl start启动所有监听器，没什么问题。
然后执行命令：sqlplus / as sysdba，oracle返回错误ORA-01031: insufficient privileges，权限不足，应该是当前登录用户权限的问题
image.png
执行su oracle切换到oracle用户，再次执行sqlplus / as sysdba，直接报command not found，找不到命令，由于对Linux研究不多，这里卡了好久，原因是su切换用户不改变当前环境变量，应该用su - oracle，切换用户后并且切换到用户的变量，再次执行sqlplus / as sysdba，连接成功，然后执行startup启动oracle，又报错了，报错信息为ORA-32004，ORA-16032，ORA-07286。
ORA-16032: parameter LOG_ARCHIVE_DEST_1 destination string cannot be translated ORA-07286: sksagdi: cannot obtain device information. Linux Error: 2: No such file or directory
image.png
查看提示是Linux找不到档案或者目录，联想到可能是服务器通过数据硬盘迁移造成了服务的某些配置路径发生了变化。查看网上相关问题的处理，发现这三个错误都是同时出现，基本可以确定就是同一个问题，查看ORA-16032的报错信息：parameter LOG_ARCHIVE_DEST_1 destination string cannot be translated，继续查资料，是oracle归档路径的问题，命令archive log list查看归档信息，显示not logged on，应该看下oracle的spfile文件，spfile文件存放的也是数据库实例启动时的参数设置值，cd ORACLE_HOME目录，cd dbs，执行strings spfile*.ora|grep dest_1，列出以下信息： *.log_archive_dest-1='location=/data/oracle/product/11.2.0/archive/arch' 然后尝试进入这个目录 cd /data/oracle/product/11.2.0/archive/arch，提示：没有那个文件或目录，/data/oracle/product/11.2.0下没有/archive/arch目录，然后尝试在/data/oracle/product/11.2.0下新建了目录/archive/arch，chown/chgrp修改文件夹到用户oracle/1001下，然后再重新执行以下命令：
sqlplus / as sysdba
SQL> startup
oracle启动成功
image.png
4.oracle启动成功后再次执行启动基础服务的脚本，auth服务也正常启动，然后打开浏览器输入测试环境访问地址，还是报auth服务相同的错误，提示错误为http://test-ip/zhuapi/ius/xxxxxxx，仔细一看，多了个zhuapi，以前好像没见过啊，这个是请求到网关的链接，网关识别此来转发到对应的微服务，正常应该是配置我们应用前端代码的config.js中，应该不是nginx反向代理的问题，所以直接去前端代码中全局搜zhuapi，什么都没搜到，看了config.js也是正常的，然后又将目光转到nginx配置，查看了nginx配置也没找到这个zhuapi。然后浏览器F12，点到控制台Sources下，直接查看浏览器加载的前端文件，应用的前端业务代码都做了混淆，config.js只有简单的几个配置，没混淆，可以直接看，果然，前端加载的config.js中有个zhuapi，这个配置完全没印象，还不知道缓存了多久，应该是很早以前的，真的是很奇怪。所以现在问题找到，是nginx的问题，页面加载的一直是nginx中缓存的静态文件，然后绕过nginx直接请求网关地址，应用显示正常，所以基本确定就是nginx的问题了。
nginx启动成功，也能请求到服务的页面，但是访问异常，所以首先想到去看nginx的配置文件，whereis nginx，列出几个目录，找到nginx位置在/usr/local/nginx，还有个/etc/nginx，先不管，cd /usr/local/nginx/conf， vi nginx.conf，打开后看到就一行配置，监听了8099端口，并且在其目录中找到了对应的错误的缓存静态文件，直接删除，再次访问，nginx报错找不到页面，很奇怪，这个配置也没监听80，原先nginx上的配置肯定不可能是这样的，否则无法正常转发请求，回头再去看/etc/nginx，/etc/nginx/这个目录下也有个nginx.conf的配置，打开发现这个才是转发应用服务的nginx配置，但是很奇怪，服务器装了两个nginx，默认启动的不是对应我们服务的，这两个nginx应该分别是yum安装与源码包安装的。然后查看当前nginx的pid，kill掉，停掉nginx，替换nginx配置文件为服务对应的配置，指定配置文件重启，然后浏览器强制刷新访问，服务恢复正常。
网友评论