/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
将这情况反馈给项目组后，客户协调了集群安装人员来进行处理，我就停下让对方人员处理。
晚点的时候，项目经理联系我：第三方服务商人员无法搞定或者根本没有排查，请求我来解决。
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]
可以看到明显提示是Permission denied，看来是有某些文件的权限不对。
去Metalink查看相关资料，在Troubleshoot Grid Infrastructure Startup Issues (文档 ID 1050908.1) 找到了问题解决。
文档中介绍：
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权限出现问题，就会遇到相应的错误。
检查节点一对应文件的权限信息：
可见节点一 /var/tmp/.oracle下文件权限信息是oracle:oinstall
对比节点二（节点二正常，可以加入进集群）对应文件的权限信息：
可见节点一 /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. 知识点
下图是集群启动时会做的检查，任一点出现问题都会导致集群无法启动：
/var/tmp/.oracle目录下文件在安装完RAC生成，之后每次启动集群进行检查：
- 如果这些文件存在，进行验证
- 如果不存在，重新生成。
5. 总结
- 这套RAC安装的时候就有一些问题，二、三节点没环境变量，磁盘组只有一块等等...
- 至于为什么/var/tmp/.oracle文件权限信息会变，和项目组沟通10月1日那天
切换过存储控制器,集群相关的存储、网络、主机做变更的时候一定要先关闭集群。 - 对于这个问题的解决，一定要对
Cluster的启动顺序有一定了解，还要对MDNSD这些守护进程关键字足够敏感。
