环境配置
服务器配置:
数据库配置:
1.问题描述
问题发生过程描述:
神龙Oracle rac由于空间问题希望扩容根目录,扩容失败,导致相关的asm磁盘组多路径映射出现问题导致集群挂起,经过确认是由于该规格的神龙服务器不支持在线扩容,因此重新恢复到原始状态以后,rac集群只有节点2可以正常启动,节点1无法启动;
2.问题分析
由于存储相关内容丢失,联系阿里存储同学恢复到原来神龙主机状态后,asm相关的映射连接也恢复了回来;
但是整个映射的dm顺序两个节点不同,故而怀疑是否是存储顺序挂载顺序错乱导致?
但是经过对比虽然dm顺序不同,但是实际的对应划分磁盘的uuid是一致的;
所以排除了是由于顺序错乱问题导致集群启动异常;
尝试去启动节点1集群,启动以后自动就关闭了集群服务,再次查看集群服务无法查看如下图报错;
查看集群状态发现除了磁盘组相关的asm服务外,监听,vip等相关的节点1服务相应也都启动了起来,所以从这里判断还是和磁盘组有关系。
但是我们来查看节点1的asm的alert日志发现并未有新的asm日志写入到alert log当中,从现象看好像asm磁盘组在节点1上直接被集群没有再识别到,换句话说集群的启动并未把asm服务纳入到启动序列里;
Ps:排查日志是2020-10-20
检查相关的crs的alert日志发现报错无法识别asm,无法读取相应的磁盘,ocr磁盘组不可访问;
进而查看相关的trc文件日志内容如下报错:
报错的主要内容就是相关的olr文件,磁盘组等读取没有权限;
less /u01/app/grid_base/diag/crs/ora12c1/crs/trace/crsd_oraagent_oracle.trc
less /u01/app/grid_base/diag/crs/ora12c1/crs/trace/ocrcheck_73764.trc
因此就对比了两侧的磁盘组相关的文件权限情况发现两端完全一致,grid用户测试磁盘的读写也可以进行;
所以考虑重新reload一下asm磁盘组在试试看能否解决;
所以执行了reload操作;
再次启动节点1集群发现启动后crs服务还是无法通信,但是ocr心跳盘可以看到了,并且和节点2对比相应的id都是一致的;
问题排查到这里感觉已经没有可以排查的方向了;
既然这里ocr已经启动正常,那么就可以尝试去启动asm实例和数据库实例看看;
果然asm实例可以正常启动成功,磁盘组正常挂载,数据库实例也可以正常启动;
但是奇怪的是,虽然这些实例及磁盘组可以正常启动,但是查看集群状态节点1依然不可看,节点2看到的是依然磁盘组是offline,rac1的db实例也未正常启动;
但是到了这里希望已经很大了,既然手动可以拉起所有的服务,那么就可以再次尝试重启集群看看能不能将所有的服务拉起来;
因此重新关闭节点1集群并重启,果然集群被正常拉了起来;
查看集群状态已经完全恢复正常
3.问题解决
重新做磁盘组映射的reload,手动尝试启动asm及db实例,重启集群;
ps:其中对于内部实现原理和运行机制还有些模糊,各位看官请多指教;