编者按:
本文作者系肖遥(花名),现任甲骨文技术支持工程师 ,目前专注于Oracle RAC领域。个人主页:
https://blog.csdn.net/weixin_50510978,经其本人授权发布。
【免责声明】本公众号文章仅代表个人观点,与任何公司无关。

之前我们提到过OHAS组件是集群启动的根守护进程。GI的启动必须首先启动 OHAS 组件。
但是并不是OHASD在没有前提条件的情况下一个命令就能启动的。GI的启动有两种途径,一种是伴随着OS的启动而自动启动GI,另外一种途径则是用crsctl start crs命令手动启动GI。但是不管哪一种途径启动GI,前提都需要有init.ohasd进程。
1.init.ohasd
init.ohasd是一个GI初始化脚本。在Linux环境中,它的路径是/etc/init.d/init.ohasd。这是一个shell脚本,会随着OS的启动而被拉起。在Linux5的时代,这个脚本是被定义在/etc/inittab中。
[root@node1 ~]#cat etc/inittab|grep init.ohasdh1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
而在Linux7里,随着OS的功能变更,init.ohasd则被systemd 以服务的形式启动。
[root@node1 ~]# cat etc/systemd/system/oracle-ohasd.service# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved.## Oracle OHASD startup[Unit]Description=Oracle High Availability ServicesAfter=network-online.target remote-fs.target autofs.serviceWants=network-online.target remote-fs.target[Service]ExecStart=/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/nullExecStop=/etc/init.d/init.ohasd stop >/dev/null 2>&1 </dev/nullTimeoutStopSec=60minType=simpleRestart=always# Do not kill any processes except init.ohasd after ExecStop, unless the# stop command times out.KillMode=processSendSIGKILL=yes# Allow continuous restartsStartLimitBurst=0[Install]WantedBy=multi-user.target graphical.target
如果我们查看init.ohasd的代码就会发现,其主体部分是一个 while (true)无限循环。也就意味着init.ohasd 进程是个常驻OS的进程。即便集群被手动关闭,init.ohasd run进程应该是一直存在于OS中的。
[root@node1 ~]# ps -ef|grep init.ohasd|grep -v greproot 4321 1 0 Mar17 ? 00:00:02 bin/sh etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
如果集群无法启动时,同学们应该要先去检查一下init.ohasd进程是不是存在。
2.S96ohasd
另外伴随着OS启动,GI也会自动启动。这实际上是由脚本S96ohasd实现的。这个脚本需要OS的 runlevel 3 或者 5的时候才会随着OS的启动而调用这个脚本。所以在Linux7中,这个脚本存在于etc/rc.d/rc3.d和etc/rc.d/rc5.d中。
[root@node1 ~]# locate S96ohasd/etc/rc.d/rc3.d/S96ohasd/etc/rc.d/rc5.d/S96ohasd
这就意味着,如果OS的runlevel不是3或者5的话,GI是不会随着OS的启动而自动启动的,因为S96ohasd脚本本身就不会被OS调用。
你以为这样GI就会被启动了吗?并不是。下面我们看一下S96ohasd的脚本内容。
AUTOSTARTFILE=$SCRBASE/$MY_HOST/$HAS_USER/ohasdstr...省略if [ -r $AUTOSTARTFILE ]thencase `$CAT $AUTOSTARTFILE` inenable*)$LOGINFO "Oracle HA daemon is enabled for autostart."my_crsctl start has -nowait;;disable*)$LOGINFO "Oracle HA daemon is disabled for autostart.";;*)...省略;;esacelse
在脚本里我们可以看到,S96ohasd 会去读取配置文件ohasdstr 的内容。如果配置文件中被设定成了 enable 的值,那么才会用 crsctl start has -nowait 命令去启动 GI。
这个配置文件隐藏的如此隐秘,肯定不会支持客户手动去更改它了。实际上我们可以通过以下命令去更改这个配置文件,以此去设定该节点的GI是否会随着OS的启动而自动启动。
[root@node1 ~]# crsctl disable crsCRS-4621: Oracle High Availability Services autostart is disabled.[root@node1 ~]# cat etc/oracle/scls_scr/node1/root/ohasdstrdisable[root@node1 ~]# crsctl enable crsCRS-4622: Oracle High Availability Services autostart is enabled.[root@node1 ~]# cat etc/oracle/scls_scr/node1/root/ohasdstrenable
实际上,调查GI无法启动的问题,查看OS日志是非常必要的。因为init.ohasd也好,s96ohasd也好,他们的很多信息都是打印到了OS日志中。
3.crsctl start crs
我们从上面的脚本里可以看到,伴随着OS启动自动启动GI的调用命令是 crsctl start has -nowait。但实际上如果这不是一个Oracle Restart的环境的话,我们通常使用的启动命令则是crsctl start crs。执行的用户必须是root用户。为了能够确认到启动过程,我们通常会在后面加-wait。这部分内容在前面的博客里提到过。
实际上OHASD守护进程是在这个阶段才被启动的。
4.如何确认GI正常启动
好了,我们上面介绍完GI的自动启动和手动启动的基本知识。如何去查看GI是否正常启动完成呢。
我们通常可以使用下面的命令。
[root@node1 ~]# crsctl check clusterCRS-4537: Cluster Ready Services is onlineCRS-4529: Cluster Synchronization Services is onlineCRS-4533: Event Manager is online
通过这个命令,我们可以确认到CRSD,CSSD 和 EMD是否正常启动而处于online的状态。
但是这个命令只能确认GI的大框架是否正常启动,而无法确认被GI管理的资源是否正常启动完成。所以我们通常需要使用 crsctl stat res -t 和crsctl stat res -t -init命令来确认各个资源是否都处于online的状态。
crsctl stat res -t可以确认到CRSD管理的资源状态,crsctl stat res -t -init则可以确认到OHASD管理的资源的状态。
下面我们以crsctl stat res -t -init的输出例子来讲解一下如何查看结果。
[root@node1 ~]# crsctl stat res -t -init--------------------------------------------------------------------------------Name Target State Server State details--------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.asm1 ONLINE ONLINE node1 STABLEora.cluster_interconnect.haip1 ONLINE ONLINE node1 STABLEora.crf1 ONLINE ONLINE node1 STABLEora.crsd1 ONLINE ONLINE node1 STABLEora.cssd1 ONLINE ONLINE node1 STABLEora.cssdmonitor1 ONLINE ONLINE node1 STABLEora.ctssd1 ONLINE ONLINE node1 OBSERVER,STABLEora.diskmon1 OFFLINE OFFLINE STABLEora.drivers.acfs1 ONLINE ONLINE node1 STABLEora.evmd1 ONLINE ONLINE node1 STABLEora.gipcd1 ONLINE ONLINE node1 STABLEora.gpnpd1 ONLINE ONLINE node1 STABLEora.mdnsd1 ONLINE ONLINE node1 STABLEora.storage1 ONLINE ONLINE node1 STABLE--------------------------------------------------------------------------------
从上面的输出结果中我们看到了以下列名。
Name 资源名Target 资源的期待状态State 资源的实际的状态Server 资源所在的节点State details 资源的实际状态的详细
这里面Target显示的信息其实是GI记录的资源该有的状态。这个信息是记录在OCR中的(OCR是记录集群所有重要信息的文件,位于共享磁盘上,被所有节点访问)。
如果Target是ONLINE,而State是OFFLINE的话,代表该资源启动失败。如果Target是OFFLINE,则代表该资源不会被自动启动。如果用户想启动该资源,则需要执行相关的资源启动命令。
今天我们简单的讲了一下crsctl start crs之前的GI的启动逻辑,这部分内容其实对于绝大多数同学来讲是不太去关注的。但是一旦在处理集群无法启动的问题时,这部分内容就显得尤为必要了。
其实GI启动的知识远比上面的内容要多的多,比如OHASD的启动需要读取OLR的信息,CSSD的启动需要读取OCR的信息等等。但是我想这些内容对于一般的同学而言先不用深入的了解,这部分内容属于更专业更深层次的知识,等我们有时间的时候可以写专题研究。浅谈 Oracle RAC 系列还是本着带大家初步了解 Oracle RAC 的初衷来跟大家分享。
后续文章更加精彩,欢迎关注本公众号或访问【阅读原文】。
——End——
专注于技术不限于技术!
用碎片化的时间,一点一滴地提高数据库技术和个人能力。
欢迎关注!
数据库基础系列(从基础了解数据库):
通过寄存服务来“理解”Oracle数据库基本体系结构和动作流程
浅谈RAC系列:




