暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

浅谈Oracle RAC(3)--GI的启动

1686

编者按:

本文作者系肖遥(花名),现任甲骨文技术支持工程师 ,目前专注于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.ohasd
    h1: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 Services
      After=network-online.target remote-fs.target autofs.service
      Wants=network-online.target remote-fs.target


      [Service]
      ExecStart=/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
      ExecStop=/etc/init.d/init.ohasd stop >/dev/null 2>&1 </dev/null
      TimeoutStopSec=60min
      Type=simple
      Restart=always


      # Do not kill any processes except init.ohasd after ExecStop, unless the
      # stop command times out.
      KillMode=process
      SendSIGKILL=yes


      # Allow continuous restarts
      StartLimitBurst=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 grep
        root 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 ]
            then
            case `$CAT $AUTOSTARTFILE` in
            enable*)
            $LOGINFO "Oracle HA daemon is enabled for autostart."
            my_crsctl start has -nowait
            ;;
            disable*)
            $LOGINFO "Oracle HA daemon is disabled for autostart."
            ;;
            *)
            ...省略
            ;;
            esac
            else

            在脚本里我们可以看到,S96ohasd 会去读取配置文件ohasdstr 的内容。如果配置文件中被设定成了 enable 的值,那么才会用 crsctl start has -nowait 命令去启动 GI。

            这个配置文件隐藏的如此隐秘,肯定不会支持客户手动去更改它了。实际上我们可以通过以下命令去更改这个配置文件,以此去设定该节点的GI是否会随着OS的启动而自动启动。

              [root@node1 ~]# crsctl disable crs
              CRS-4621: Oracle High Availability Services autostart is disabled.
              [root@node1 ~]# cat etc/oracle/scls_scr/node1/root/ohasdstr
              disable


              [root@node1 ~]# crsctl enable crs
              CRS-4622: Oracle High Availability Services autostart is enabled.
              [root@node1 ~]# cat etc/oracle/scls_scr/node1/root/ohasdstr
              enable

              实际上,调查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 cluster
                CRS-4537: Cluster Ready Services is online
                CRS-4529: Cluster Synchronization Services is online
                CRS-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.asm
                  1 ONLINE ONLINE node1 STABLE
                  ora.cluster_interconnect.haip
                  1 ONLINE ONLINE node1 STABLE
                  ora.crf
                  1 ONLINE ONLINE node1 STABLE
                  ora.crsd
                  1 ONLINE ONLINE node1 STABLE
                  ora.cssd
                  1 ONLINE ONLINE node1 STABLE
                  ora.cssdmonitor
                  1 ONLINE ONLINE node1 STABLE
                  ora.ctssd
                  1 ONLINE ONLINE node1 OBSERVER,STABLE
                  ora.diskmon
                  1 OFFLINE OFFLINE STABLE
                  ora.drivers.acfs
                  1 ONLINE ONLINE node1 STABLE
                  ora.evmd
                  1 ONLINE ONLINE node1 STABLE
                  ora.gipcd
                  1 ONLINE ONLINE node1 STABLE
                  ora.gpnpd
                  1 ONLINE ONLINE node1 STABLE
                  ora.mdnsd
                  1 ONLINE ONLINE node1 STABLE
                  ora.storage
                  1 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数据库简史

                    数据库的“黑匣子”--故障诊断日志基础

                    通过寄存服务来“理解”Oracle数据库基本体系结构和动作流程

                    Oracle优化器架构变化和特定行为


                    浅谈RAC系列:

                    浅谈Oracle RAC (1)--概要

                    浅谈Oracle RAC (2)--集群管理软件GI基本架构

                    文章转载自Oracle数据库技术,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

                    评论