编者按：
本文作者系肖遥（花名），原甲骨文技术支持工程师 ，专注于Oracle RAC领域。个人主页:
https://blog.csdn.net/weixin_50510978，经其本人授权发布。
【免责声明】本号文章仅代表个人观点，与任何公司无关。
编辑|SQL和数据库技术(ID:SQLplusDB)
浅谈RAC系列：
浅谈Oracle RAC (1)--概要
浅谈Oracle RAC (2)--集群管理软件GI基本架构
浅谈Oracle RAC(3)--GI的启动
浅谈Oracle RAC(4)– OHAS组件
浅谈Oracle RAC(5)– CSS组件
浅谈Oracle RAC(6) 之实战：节点reboot问题的调查方法
我们之前的几期重点介绍了RAC集群软件里面的两个重要组件----OHASD和CSSD。那么这篇我们打算介绍一下RAC集群软件中剩下的最后一个特别重要的组件----CRSD。
1.CRSD主要功能
CRSD的主要功能是管理集群中的应用程序，以便实现应用程序的高可用性。另外，CRSD还负责管理OCR。关于OCR的概念，在下文中会详细介绍。
我们看一下上面的这张简化版的GI软件的架构图。我们可以看到CRSD组件主要管理Database，ASM，监听，服务等等应用程序。而各个应用程序又根据所属user不同而被CRSD下面的不同Agent所管理。
另外在上图中没有画出来，CRSD下面还有另一个也很重要的Agent叫scriptagent。这个Agent主要管理CVU资源或者用户自定义的资源。
2.Agent的基本动作
那么Agent是对各个应用程序都有哪些操作呢？
◇ START
正如字面上理解的这样，Agent会对应用程序做启动的动作。当应用程序无预警宕机时，Agent会尝试自动启动该程序。另外使用srvctl start 命令可以手动启动相应的应用程序。
◇ STOP
STOP则是停止应用程序，与START类似，这里不做赘述。
◇ CHECK
Agent会定期对各资源进行状态检查。具体检查间隔时间由各应用程序的属性设定值有关，我们在下文中会介绍一些常见资源属性。
◇ CLEAN
ClEAN操作一般是Agent通过CHECK发现应用程序出现异常状态后需要重启或者Failover之前发生的动作。一般包含更新该资源在GI集群各进程中的信息，以及更新OCR里面的信息。
◇ ABORT
当Agent尝试去CHECK某应用程序时，如果该应用程序因夯等原因使得Agent无法与其进行通信，超过一定之间后，Agent会强制中止该应用程序。
3.资源属性
上文说到Agent会根据资源属性设定值来决定对该资源CHECK的时间间隔。那么资源都有哪些属性资源呢？我们在下面介绍几个比较常见的属性。而且必须强调的是，在解决Oracle集群问题时，对这些属性的理解至关重要。
◇ ACL
这个属性是该资源所属权限的设定，如果该属性的权限设定有误，会造成Agent对资源的管理失败。
我们拿下面的例子做个介绍。
代码语言：javascript复制ACL=owner:root:rwx,pgrp:root:r-x,other::r–,group:oinstall:r-x,user:grid:r-x这个权限设定说明，该应用程序属于root用户，oinstall组里的用户对该资源有读和执行权限，grid用户对该资源有读和执行权限。
◇ AUTO_START
这个属性是定义该应用程序是否随着GI的启动而启动。这个属性有三个设定值分别是always, never和restore。
・always是说，该资源总是随着GI的启动而启动。
・never是说，该资源不会随着GI的启动而启动，用户需要手动启动该资源。
・restore则是表明，该资源是否随着GI启动取决于GI停止前该应用程序是否是运行状态。如果是运行状态，则该资源随着GI启动而启动，如果是停止状态，则不会随着GI启动而启动。
◇ CHECK_INTERVAL
该属性就是用来定义Agent对其CHECK的时间间隔。
◇ RESTART_ATTEMPTS
该属性定义了，当某程序出现故障而OFFLINE时，Agent尝试重启该程序的次数。
除此之外还有很多有用属性，例如HOSTING_MEMBERS，PLACEMENT，ACTIVE_PLACEMENT等与自定义资源所在节点配置有关的设定，以后有时间再展开介绍。
4.资源依赖关系
资源的依赖关系由START_DEPENDENCIES和STOP_DEPENDENCIES来决定。
最常见的依赖关系类型是hard，weak，pullup。
在START_DEPENDENCIES中，hard定义强依赖关系，意味着要启动这个资源的话，hard中的资源一定已经被启动。相反，weak中定义的资源则不会影响依赖资源启动成功与否。而pullup中定义的资源则意味着在依赖资源启动时会强行将pullup中的依赖资源自动启动。
而STOP_DEPENDENCIES中则往往是强依赖关系具有实际意义，也就是说hard中指定的被依赖资源一旦停止，则该依赖资源也随之停止。
我们举个例子说明一下：
代码语言：javascript复制START_DEPENDENCIES=hard(ora.DATA.dg,ora.FRA.dg) weak(…)
pullup(ora.DATA.dg,ora.FRA.dg)weak依赖关系往往不构成主要关注项，此处省去。
我们来看一下上面的启动依赖关系中，hard被设定成了DATA和FRA两个磁盘组。也就意味着，该资源如果想要启动成功，则必须保证DATA和FRA两个磁盘组启动成功。同时我们看到pullup里面也将两个磁盘组设定进去，则意味着，要想启动该资源，不需要提前手动将DATA和FRA启动，而是随着该资源启动，这两个磁盘组会被自动拉起。
5.查看资源属性和依赖关系
我们查看某资源的属性和依赖关系时可以使用以下命令。
代码语言：javascript复制crsctl status resource <资源名> -f [-init]-init这个option是用来查看ohasd管辖的资源的属性和依赖关系的。
6.更改资源属性的命令
说到这里可能有的小伙伴就想到了，既然这些属性可以设定，那怎么设定这些属性呢。其实甲骨文官方并不support客户随意对任何以ora.开头的资源属性做任何修改，除非得到甲骨文官方建议。ora.开头的资源是甲骨文的应用程序，原则性上，default的设定已经是最佳实践设定。即便如此，在这里也跟大家透露一下更改ora.资源的命令。
代码语言：javascript复制crsctl modify res <资源名> -attr “属性名=属性值” -unsupported对于那些自定义的资源，修改属性则不需要指定-unsupported。
说到这里，小伙伴又会问了，这些属性设定值到底被存在了哪里了呢？CRSD的Agent又是如何利用这些属性对资源进行管理的呢？
5.OCR
这里可以很明确的告诉大家，CRSD所管理的资源的信息都是存储在叫做OCR的文件中。这个文件就相当于一个注册表。CRSD会将资源信息记录到CRSD中，当对应用程序进行操作的时候，CRSD会将程序运行状态与OCR中保存的该资源的信息进行比对。比如在OCR中保存的该资源的TARGET状态是ONLINE，而实际确认到的该资源状态是OFFLINE状态，那么CRSD则会通知Agent对该资源进行重启操作。
通常情况下我们不需要去查看OCR中的信息。如果感兴趣的小伙伴则可以通过以下命令将OCR从磁盘组中dump到本地查看。
代码语言：javascript复制./ocrdump <路径>由此可见，OCR对于集群来说是非常重要的信息，一旦丢失或损坏，该集群将全损，所以对于OCR的保护要特别重视。
Oracle对OCR提供了自动备份和手动备份的机制，当OCR损坏时我们是可以通过从备份的OCR中restore回正常状态的。关于OCR的维护我想有必要找个专题去详细的介绍一下。
关于CRSD的内容真的是太多想要介绍的，但是毕竟我们这个是浅谈系列，所以我还是控制一下自己，点到为止，主旨还是介绍为主，而不是深入研究。我想以后有机会我们去针对某个特定话题做更多研究更有意义。否则这里就写成了天书，没人看得懂了。
我们最后关于CRSD再介绍一个概念PE。
6.Policy Engine
这个概念其实在外界对RAC的认知中是基本上没有人知道的组件。CRSD在所有节点上都存在，是一个分布式的集群组件，各节点上的CRSD对一些共享资源进行管理时，需要一种协调机制来保证各节点CRSD是按照特定顺序执行的。所以CRSD引入了主-从模式，集群中对某资源的操作会先发送给PE主节点，再由PE主节点发送给执行操作的Agent。集群中必须存在一个PE主节点，同时会选择若干PE主节点的预备节点。当PE主节点停止后，会从预备节点中选择一个节点作为PE主节点。
当PE主节点停止时，会因为预备节点接替，congfig过程中，新的PE主节点有时会对应用程序发出二次启动或者failover等操作，这些都属于正常动作，客户不必纠结于此。
Oracle官方并不认为PE是一个客户需要去操作或者重点关注的组件，所以官方没有提供查看PE主节点的命令。不过我们可以通过CRSD的日志文件查看。
代码语言：javascript复制PE MASTER NAME: <节点名>谈到这里想强调一个观念，Oracle RAC 没有主节点的概念。因为国内的有一些DBA经常跟我争论Oracle RAC有主节点。
首先我们在谈到主节点时，那么一定会存在从节点。在传统分布式数据库中一般的架构是：一主一从，一主多从，多主多从等。
主代表着读写全能，从则代表着只读不写。而RAC的核心技术是内存融合技术，各个节点都可以进行读写操作，所以RAC没有主节点的概念。RAC中是以资源(数据块)为单位创建master信息的，而这些master所在的节点则是通过hash算法均等的分布到各个节点内存中，所以RAC中没有主节点的概念。
如果非要找到所谓的主节点，则更靠谱的也只是CRSD的PE主节点，然而CRSD只是集群软件层面的一个组件，它还决定不了哪个节点是主节点。Oracle RAC的架构跟传统分布式数据库有本质区别，这一点各位小伙伴还是不要搞混啊。
