oracle var/tmp,/var/tmp/.oracle权限导致RAC节点被T出集群

/var/tmp/.oracle权限导致RAC节点被T出集群

@(Oracle)

1. 项目背景

项目组假期回来上班发现无法使用系统，自己排查后发现没有启动监听，在联系我排查后发现是RAC环境，在一节点上可以发现集群没有启动。

[grid@oradb1 ~]$ crsctl check cluster

CRS-4535: Cannot communicate with Cluster Ready Services

CRS-4530: Communications failure contacting Cluster Synchronization Services daemon

CRS-4534: Cannot communicate with Event Manager

将这情况反馈给项目组后，客户协调了集群安装人员来进行处理，我就停下让对方人员处理。

晚点的时候，项目经理联系我：第三方服务商人员无法搞定或者根本没有排查，请求我来解决。

TIM图片20171011161935.png

2. 恢复系统

确认好是RAC环境，如果是一节点无法启动，那对我这个数据库服务是没有影响的，还有二节点可以提供服务。

检查二节点和三节点的情况，发现安装人员没有对这两个节点配置环境变量，导致所有命令都需要用绝对路径，有些文件路径也没法知道，需要和一节点进行匹配，很烦。

[grid@oradb2 ~]$ cat ~/.bash_profile

# .bash_profile

# Get the aliases and functions

if [ -f ~/.bashrc ]; then

. ~/.bashrc

fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH

查看二节点和三节点的集群情况，发现是在正常运行的，那系统为什么无法使用呢？

检查应用的配置，发现TNS配置的只有节点1的IP，根本没用到RAC的负载均衡功能。

和项目人员沟通后，配置了节点二、节点三的IP地址，系统恢复。

3. 修复节点一

在处理节点一故障时，分析问题的原因就需要抽丝剥茧，难免会走错方向。

检查一节点的日志文件，比较重要的就是ohasd.log和alertoradb1.log。

3.1 弯路一：存储

检查alertoradb1.log日志，发现在10月1日时节点一就已经被T出集群。

[/g01/grid/app/11.2.0/grid/bin/oraagent.bin(9168)]CRS-5011:Check of resource "ORCL" failed: details at "(:CLSN00007:)" in "/g01/grid/app/11.2.0/grid/log/oradb1/agent/crsd/oraagent_oracle/oraagent_oracle.log"

2017-10-01 12:06:32.773:

[cssd(8096)]CRS-1649:An I/O error occured for voting file: /dev/asm-diskc; details at (:CSSNM00060:) in /g01/grid/app/11.2.0/grid/log/oradb1/cssd/ocssd.log.

2017-10-01 12:06:32.773:

[cssd(8096)]CRS-1649:An I/O error occured for voting file: /dev/asm-diskc; details at (:CSSNM00059:) in /g01/grid/app/11.2.0/grid/log/oradb1/cssd/ocssd.log.

2017-10-01 12:06:36.773:

[cssd(8096)]CRS-1649:An I/O error occured for voting file: /dev/asm-diskc; details at (:CSSNM00060:) in /g01/grid/app/11.2.0/grid/log/oradb1/cssd/ocssd.log.

2017-10-01 12:06:44.773:

[cssd(8096)]CRS-1649:An I/O error occured for voting file: /dev/asm-diskc; details at (:CSSNM00060:) in /g01/grid/app/11.2.0/grid/log/oradb1/cssd/ocssd.log.

根据日志的信息，表决盘/dev/asm-diskc出现IO错误。

检查ASM的权限、用户在一节点上都是正确的，在测试磁盘也能正常使用。

dd if=/dev/asm-diskc of=/opt/ count=1 bs=512

初步判断，存储应该没有问题，继续分析。

但是在分析中，发现了一个安装的问题，只有一块ASM磁盘组+DATADG，也就是说，OCR文件、数据文件、控制文件等等文件都放在一个磁盘组里。

3.2 弯路二：网络故障

检查oraagent_grid.log日志查看具体详细信息，可以看到如下报错：

[ clsdmc][2973124352]Fail to connect (ADDRESS=(PROTOCOL=ipc)(KEY=oradb1DBG_MDNSD)) with status 9

2017-10-10 15:15:38.481: [ora.mdnsd][2973124352]{0:0:605} [start] Error = error 9 encountered when connecting to MDNSD

2017-10-10 15:15:39.481: [ora.mdnsd][2973124352]{0:0:605} [start] without returnbuf

2017-10-10 15:15:39.647: [ COMMCRS][2979428096]clsc_connect: (0x7f5f94065760) no listener at (ADDRESS=(PROTOCOL=ipc)(KEY=oradb1DBG_MDNSD))

看到Fail to connect (ADDRESS=(PROTOCOL=ipc) 经验主义告诉我可能是和网络有关的问题，检查网络相关

网卡信息没有问题

IP也没有变更

私网IP也能ping通

...

看来，应该也不是网络问题，继续分析。

3.3 正确路线：/var/tmp/.oracle

正在陷入困惑时，发现报错信息提到MDNSD守护进程Error = error 9 encountered when connecting to MDNSD

可以查看下MDNSD的日志信息，分析，为什么连不上MDNSD？

查看日志$ORACLE_HOME/log/oradb1/mdnsd/mdnsd.log

看到有明显的报错信息：

2017-10-09 10:22:53.400: [ default][4201023232]mdnsd START pid=7996

2017-10-09 10:22:53.408: [ COMMCRS][4192470784]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=oradb1DBG_MDNSD))

2017-10-09 10:22:53.408: [ clsdmt][4194572032]Fail to listen to (ADDRESS=(PROTOCOL=ipc)(KEY=oradb1DBG_MDNSD))

2017-10-09 10:22:53.408: [ clsdmt][4194572032]Terminating process

2017-10-09 10:22:53.408: [ MDNS][4194572032] clsdm requested mdnsd exit

2017-10-09 10:22:53.409: [ MDNS][4194572032] mdnsd exit

2017-10-09 10:24:58.452: [ default][3607267072]

文档中介绍：

Network Socket File Location, Ownership and Permission

Network socket files can be located in /tmp/.oracle, /var/tmp/.oracle or /usr/tmp/.oracle

When socket file has unexpected ownership or permission, usually daemon log file (i.e. evmd.log) will have the following:

2011-06-18 14:07:28.545: [ COMMCRS][772]clsclisten: Permission denied for (ADDRESS=(PROTOCOL=ipc)(KEY=racnode1DBG_EVMD))

2011-06-18 14:07:28.545: [ clsdmt][515]Fail to listen to (ADDRESS=(PROTOCOL=ipc)(KEY=lena042DBG_EVMD))

2011-06-18 14:07:28.545: [ clsdmt][515]Terminating process

2011-06-18 14:07:28.559: [ default][515] EVMD exiting on stop request from clsdms_thdmai

可以看见，文档介绍如果/tmp/.oracle、/var/tmp/.oracle或/usr/tmp/.oracle权限出现问题，就会遇到相应的错误。

检查节点一对应文件的权限信息：

oradb1.png

可见节点一 /var/tmp/.oracle下文件权限信息是oracle:oinstall

对比节点二(节点二正常，可以加入进集群)对应文件的权限信息：

oradb2.png

可见节点一 /var/tmp/.oracle下文件权限信息是oracle:oinstall

至此，问题原因找到，只要修改对应的文件夹权限信息即可

3.4 解决

删除此目录下所有文件

rm -rf /var/tmp/.oracle

重启集群

这步我选择了更偷懒的方法，直接重启服务器，让RAC自己去开机加入集群的特性自己完成。

root@oradb1 bin]# ./crsctl start cluster -all

CRS-4690: Oracle Clusterware is already running on 'oradb1'

CRS-4690: Oracle Clusterware is already running on 'oradb2'

CRS-4690: Oracle Clusterware is already running on 'oradb3'

至此，我们将节点一成功恢复，完成了第三方服务商也棘手的问题。

4. 知识点

下图是集群启动时会做的检查，任一点出现问题都会导致集群无法启动：

Clusterware Startup Sequence.png

/var/tmp/.oracle目录下文件在安装完RAC生成，之后每次启动集群进行检查：

如果这些文件存在，进行验证

如果不存在，重新生成。

5. 总结

这套RAC安装的时候就有一些问题，二、三节点没环境变量，磁盘组只有一块等等...

至于为什么/var/tmp/.oracle文件权限信息会变，和项目组沟通10月1日那天切换过存储控制器,集群相关的存储、网络、主机做变更的时候一定要先关闭集群。

对于这个问题的解决，一定要对Cluster 的启动顺序有一定了解，还要对MDNSD这些守护进程关键字足够敏感。