基于veritas存储管理的集群安装故障处理

来到新公司已经有一个月了，由于中心工作模式的要求，我还是在熟悉环境，基本每天事情不多，当时正好年底保障春运，我就每天上去看看其他DBA都在干啥，正好熟悉下系统。每天的日子过得相对比较轻松。前几天听说要到北京外的数据中心安装一套集群，说让我去，可是近一直没有消息，后来领导安排了一个工程师去了，我姑且称为小王。我当时还是感激领导的安排，因为是周末，我家俩娃需要照顾，所以领导工作还是比较有艺术，遇到这样的经理也是自己的幸运。但是周一一到公司，领导就急急匆匆的过来说“林工，麻烦你去趟吧，周末那个库死活没装起来，说遇到了bug,小王回来会跟你有个交接”，说完，领导匆匆忙其他去了，我就坐着想遇到个bug打补丁不可以吗，再说两天时间bug问题无法解决？在等待小王回来这一个小时，我一直怀疑很可能还有其他原因，小王也是做了几年的DBA了，近刚考了OCM，技术能力还是有的，如果仅仅是bug不会无法解决。

不到中午，小王急匆匆赶来，看得出，小王连续两天的工作看起来很疲惫，无论如何也得认可对方的两天的工作量，想必他也备受安装失败的煎熬。“林工，我查了下，这是个bug”bulabulabula后面大致说了啥我记不得，只有bug这个词印象深刻，“好吧，我先过去看看，后续我们保持联系” ，做DBA的务必跟前期工作的同志保持密切联系，因为环境他们比你熟悉，多问问会少走很多弯路。

下午公司安排车辆，由项目经理带队出发了，路上因为XX原因饶了远，我们到达中心基地已经下午4：30了， 我迅速了解下环境，这是个三节点集群，操作系统是Linux7.6之前是Oracle Linux但是由于硬件支持问题，临时改装了RedHat Linux，问题出在集群的root脚本一直报错。

因为怀疑是补丁，那就先打上补丁，为了防止之前安装的影响，我完全删除了之前的安装文件，重新检查各种配置项，后续安装集群软件时先在个节点把补丁打上，这样就省去了在三个节点后续打补丁的耗时操作（这里感谢之前银行工作的同事提醒）。但是执行root.sh脚本步骤依然报错，显然这不是补丁可以解释的了。

从日志看是无法访问到下面的磁盘文件，经过询问我们的存储都是经过第三方厂家Veritas实现的，此时是否有了新的目标，于是我开始协调Veritas工程师跟我们一起排查，经过确认确实是Veritas有问题，识别底层磁盘故障，经过一个小时Veriatas工程师眼花缭乱的操作，说是可以了，识别磁盘正常，于是我开始继续跑我们的脚本，但是故障依然如故。好像问题还是卡在中间某个地方，通过看日志我发现一个问题，就是有一个文件软链连接软链，也就是根本没有一个实例文件。

节点1

ls -lrt /grid/12.2/lib/libskgxn2.so

/grid/12.2/lib/libskgxn2.so -> /etc/ORCLcluster/lib/libskgxn2.so

而 /etc/ORCLcluster/lib/libskgxn2.so本身又是一个软链。没有一个实际的RAC接口文件

节点2 类似，感觉好像人为作了软链操作（后咨询之前DBA说看到其他库都是软链，做了软链接，具体操作没必要追究了）

从目前分析，安装第三方存储软件时，Oracle会检测目录/etc/ORCLcluster/lib/libskgxn2.so是否有文件libskgxn2.so，如果有就在目录/grid/12.2/lib/生成一个软连接，而个节点确是在/etc/ORCLcluster/lib/libskgxn2.so依然是一个软连接文件，这是两个软链，所以根本没有实体文件，因为第三个节点没有动过，比较原始，于是检查第三个节点配置信息

节点3：

$ls -lrt /etc/ORCLcluster/lib/libsk*

/etc/ORCLcluster/lib/libskgxn2.so     <<<<<< 实体接口文件

$ls -lrt /grid/12.2/lib/libskgxn2.so

/grid/12.2/lib/libskgxn2.so -> /etc/ORCLcluster/lib/libskgxn2.so <<<<<< 软链

至此感觉是找到问题所在，/etc/ORCLcluster/lib/libskgxn2.so直接拷贝到节点1的/grid/12.2/lib/目录下，修改属组权限。

然后重新跑集群初始化脚本，问题解决！

补充：期间同时遇到七七八八的小问题，比如由于Veritas的限制 我的grid，Oracle用户的组号竟然强行绑定不能修改，集群节点不能识别等等，但核心问题还是在这里。整个问题的分析处理过程，确实也是对自己的一次磨练，第三方存储的知识算是通过案例恶补了一次。