不要让你成为下一个炉石传说事件的主角

1. 感触

在数据库行业,可能一半的故障,都是人为失误造成。前一阵子闹得沸沸扬扬的炉石传说事件,就是维护人员误删数据库造成,其实现实中这种事情真是太多了,昨晚又碰到一例。

2. 故障情况

有位维护人员在安装一套11gRAC数据库出现问题,想要删除软件重新安装,删除过程采用了手工删除安装过程中产生的一些系统文件,内容如下:


在两个节点执行完上面的这些步骤后,突然发现,登错主机了,把已上线的生产库上的这些内容给删除了。不过还是很幸运,没再继续删下去,否则恢复恢复就比较麻烦了。
检查集群状态,CRS已经故障了

$ crsctl status res -t -init
CRS-4639: Could not contact Oracle High Availability Services
CRS-4000: Command Status failed, or completed with errors.
$ crsctl check crs
CRS-4639: Could not contact Oracle High Availability Services

但实际上,grid上的进程还在

$ ps -ef | grep grid
root     21771 17100  0 21:53 pts/3    00:00:00 su - grid
grid     21772 21771  0 21:53 pts/3    00:00:00 -bash
grid     22936 32530  0 21:55 ?        00:00:00 sleep 60
grid     23015 32230  0 21:56 ?        00:00:00 sleep 30
grid     23098 21772  5 21:56 pts/3    00:00:00 ps -ef
grid     23099 21772  0 21:56 pts/3    00:00:00 grep grid
grid     25868     1  0 May06 ?        00:00:00 /oracle/product/11.2.0/grid/opmn/bin/ons -d
grid     25869 25868  0 May06 ?        00:02:27 /oracle/product/11.2.0/grid/opmn/bin/ons -d
grid     25995     1  0 May06 ?        00:00:43 /oracle/product/11.2.0/grid/bin/tnslsnr LISTENER -inherit
grid     26049     1  0 May06 ?        00:00:46 /oracle/product/11.2.0/grid/bin/tnslsnr LISTENER_SCAN1 -inherit
root     27952     1  0 May06 ?        02:44:30 /oracle/product/11.2.0/grid/bin/ohasd.bin reboot
root     28000     1  0 May06 ?        02:15:19 /oracle/product/11.2.0/grid/bin/orarootagent.bin
grid     28091     1  0 May06 ?        00:45:07 /oracle/product/11.2.0/grid/bin/oraagent.bin
grid     28102     1  0 May06 ?        00:01:35 /oracle/product/11.2.0/grid/bin/mdnsd.bin
grid     28118     1  0 May06 ?        00:14:57 /oracle/product/11.2.0/grid/bin/gpnpd.bin
grid     28129     1  0 May06 ?        02:13:48 /oracle/product/11.2.0/grid/bin/gipcd.bin
root     28155     1  0 May06 ?        00:32:21 /oracle/product/11.2.0/grid/bin/cssdmonitor
root     28169     1  0 May06 ?        00:35:28 /oracle/product/11.2.0/grid/bin/cssdagent
grid     28180     1  0 May06 ?        03:39:57 /oracle/product/11.2.0/grid/bin/ocssd.bin 
root     29067     1  1 May06 ?        07:11:40 /oracle/product/11.2.0/grid/bin/octssd.bin reboot
grid     29092     1  1 May06 ?        07:09:53 /oracle/product/11.2.0/grid/bin/evmd.bin
grid     29365 29092  0 May06 ?        00:00:00 /oracle/product/11.2.0/grid/bin/evmlogger.bin -o /oracle/product/11.2.0/grid/evm/log/evmlogger.info -l /oracle/product/11.2.0/grid/evm/log/evmlogger.log
root     31981     1  1 May06 ?        05:18:43 /oracle/product/11.2.0/grid/jdk/jre/bin/java -Xms128m -Xmx512m oracle.rat.tfa.TFAMain /oracle/product/11.2.0/grid/tfa/dsjaqscdb02/tfa_home
grid     32154     1  0 21:04 ?        00:00:00 /oracle/product/11.2.0/grid/bin/tnslsnr LISTENER_SCAN1 -inherit
grid     32230     1  0 May06 ?        01:00:54 /bin/sh ./OSWatcher.sh 30 48 NONE /oracle/grid/tfa/repository/suptools/dsjaqscdb02/oswbb/grid/archive
grid     32530 32230  0 May06 ?        00:05:03 /bin/sh ./OSWatcherFM.sh 48 /oracle/grid/tfa/repository/suptools/dsjaqscdb02/oswbb/grid/archive

两个节点的数据库进程也在

$ ps -ef | grep smon
oracle    1689     1  0 May06 ?        00:01:57 ora_smon_dsjaqsc2
oracle   27016 26965  0 22:05 pts/7    00:00:00 grep smon

数据库还可以连,但是无法访问Grid,一些维护操作也是出现故障了。

$ sqlplus "/ as sysdba"

SQL*Plus: Release 11.2.0.4.0 Production on Fri May 26 22:03:22 2017

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options

SQL> 
SQL> shutdown immediate
ORA-29702: error occurred in Cluster Group Service operation
ORA-29701: unable to connect to Cluster Synchronization Service
ORA-29701: unable to connect to Cluster Synchronization Service

业务主用节点1,本来想着到节点2尝试一下恢复的,没想到停节点2的库时,出现故障,节点1的实例也一起宕了,那好吧,只能今晚恢复起来了。

3. 故障分析与处理

从上面的删除操作来看,主要删除了/etc/下的一些oracle配置,/etc/init.d/下的Oracle自启动文件,还有就是/tmp目录下的.oracle目录。
/tmp/.oracle目录里面存了一些Oracle的socket文件,重启时可以自动生成,可以不用管。
/etc/init.d里的ohasd和init.ohasd,可以从GRID的安装目录中复制过去,如下:

# cp /oracle/product/11.2.0/grid/crs/init/init.ohasd /etc/init.d/
# chmod u+x /etc/init.d/init.ohasd
# chmod g+x /etc/init.d/init.ohasd
# chmod o+x /etc/init.d/init.ohasd
# cp /oracle/product/11.2.0/grid/crs/init/ohasd /etc/init.d/
# chmod u+x /etc/init.d/ohasd                         
# chmod g+x /etc/init.d/ohasd                         
# chmod o+x /etc/init.d/ohasd                         

下面就是处理/etc/中的oracle配置文件,主要是:/etc/oraInst.loc、/etc/oratab和/etc/oracle目录
/etc/oraInst.loc恢复

# /oracle/oraInventory/orainstRoot.sh 
Changing permissions of /oracle/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.

Changing groupname of /oracle/oraInventory to oinstall.
The execution of the script is complete.
# ls -l /etc/oraInst.loc 
-rw-r--r-- 1 root root 55 May 26 21:26 /etc/oraInst.loc
# cat /etc/oraInst.loc 
inventory_loc=/oracle/oraInventory
inst_group=oinstall

/etc/oratab没太大用处,暂时未恢复,恢复也简单
主要就是/etc/oracle目录的恢复,到一个好的11gRAC库上观察一下这个目录的内容

$ tree 
.
├── lastgasp
│   ├── cssagent_itsmdb01.lgl
│   └── cssmonit_itsmdb01.lgl
├── ocr.loc
├── ocr.loc.orig
├── olr.loc
├── olr.loc.orig
├── oprocd
│   ├── check
│   ├── fatal
│   └── stop
├── scls_scr
│   └── itsmdb01
│       ├── grid
│       │   └── cssfatal
│       └── root
│           ├── crsstart
│           ├── ohasdrun
│           └── ohasdstr
└── setasmgid

整个目录结构还算简单,就直接打了个tar包,到故障节点解包

# tar cvf oracle.tar oracle

在问题节点上

# tar xvf oracle.tar

然后将 lastgasp目录下的文件、scls_scr目录下的目录文件,直接改个名字。
另外两个文件比较重要,需要改一下内容 :ocr.loc、olr.loc,可以看一下内容

# cat ocr.loc
ocrconfig_loc=/ocrvote/itsmdb/ocr1
ocrmirrorconfig_loc=/ocrvote/itsmdb/ocr2
ocrconfig_loc3=/ocrvote/itsmdb/ocr3
local_only=FALSE
# cat olr.loc
olrconfig_loc=/oracle/product/11.2.0/grid/cdata/itsmdb01.olr
crs_home=/oracle/product/11.2.0/grid

将这两个文件中的路径修改正确,下面就是重启GRID和DB了,将当前的grid中的所有进程全部杀了,然后重启grid,就可以正常启动grid了。
在启动时还发现以前的VIP和SCANIP都在网卡上,VIP不清理,CRS的VIP资源可以直接启动,但是SCAN IP的资源会出现问题,处理如下:

$ srvctl stop scan
# ip addr del xxx.xxx.12.147 dev eth2:1
Warning: Executing wildcard deletion to stay compatible with old scripts.
         Explicitly specify the prefix length (xxx.xxx.12.147/32) to avoid this warning.
         This special behaviour is likely to disappear in further releases,
         fix your scripts!
$ srvctl start scan

处理完SCAN,整个GRID和DB就恢复完成了。

4. 提醒

最后还是得提配各位做维护的同仁,操作一定要小心,特别是rm操作,时刻警惕,你是在要操作的机器上吗?不要让误操作毁了一生,成为删库跑的主角

关于紫砂壶

感悟技术人生
此条目发表在故障处理分类目录,贴了标签。将固定链接加入收藏夹。

1 则回应给 不要让你成为下一个炉石传说事件的主角

  1. 匿名说:

    谢谢分享!

评论已关闭。