大话ORACLE RAC 笔记之RAC与Clusterware

    RAC与Clusterware的交互

    Clusterware要决定集群组成 、成员身份、成员状态，Clusterware并不关心上一层应用到底是数据库或是WEB应用。它 只负责收集集群节点状态 完整视图，并向上层提供这个视图。而RAC要依赖于Clusterware，它需要 从Clusterware获得这个视图，根据这个视图调整自己。但是RAC也不完成 依赖于Clusterware，很多时候RAC是两腿走路：先看Clusterware能不能解决问题， 如果不能，RAC自己 进行IMR (instance membership recover)

   Clusterware层

    所有节点的Clusterware组成一个集群，并构成一 个集群成员列表（Cluster membership list）第个节点会分配一个成员ID（Node Id）这些Clusterware 之间互相通信 以了解彼此的状态， 并从中选出一个节点作为Master Node,Master Node负责管理集群状态的 变迁。当有节点加入或离开集群时，集群的状态会发生变迁 ，最终达到一个新的稳定状态。每个集群的稳定状态用一个数值表示，这个数值叫做Cluster Incarnation Number。达到新稳定状态时，这个数值会改变。

    RAC 中的各个实例也构成了 一个实例成员列表 (Instance membership list) ， 每个实例也使用Clusterware 层的node id作为身份标 识，这个ID在集群生命周期内是不会变的。RAC Instance在启动时会把LMON、DBWR等需要操作共享存储的进程 作为一个组注册 到Clusterware中，并从Clusterware获得node id作为组ID。

    RAC集 群与节点集群是两个层次的集群，两个集群都 有脑裂、IO隔离等问题。这两个集群都有各自的故障检测机制。如果在RAC这一层检测到节点故障，RAC集群会做如下工作

    （1）暂停对外服务

    （2）RAC通知Clusterware， 并等待Clusterware完成集群重构 ，达到新的稳态。

    （3）Clusterware完成重构后，会通知上层的RAC集群，RAC集群收到这个信息后开始自己的重构。

    RAC层

    RAC的集群状态是通过LMON进程提供的，这个进程提供了CGS（Cluster Group Service)和NM（Node Management)两个服务。最 底层的是NM服务，它是RAC集群和Clusterware集群的通信通道，通过它把本节点的资源(Cluster Resource)状态登记到本地的Clusterware，然后由后者提供给其它节点的Clusterware，NM还要从Clusterware获得其它节点的资源状态。

    1、NM组

    第个RAC 实例都有许多进程在工作，比如DBWR,LGWR,LMON等 ，其中任何一个进程出现故障，这个节点的其它活动进程都应受到限制， 否则有可能破坏共享磁盘上的数据。因此，RAC实例的所有进程都是作为一个组(NM GROUP)注册到Clusterware中的，其中的LMON作为组里的Primary Member注册并获得Member ID，而其它进程作为这个组的Slave Member并以相同的Member ID注册到Clusterware。

    整个集群的节点成员信息是通过一个位图Bitmap来维护的。每个节点对应一个位bit，0代表节点DOWN，1代表UP，整个有一个有效／无效标志位。这个位图在整个集群作为一个全局资源被永久记录 ，当有新的节点加入集群时，该节点需要读入这个位图，找到自己对应的位bit，把值从0设为1，并且把位图的无效标识设为1 ，这时虽然位图的内容是正确的 ，但状态是无效的 ，其它 节点会定时读入这个位图，一 旦发现这个位图的状态是无效 ，就会触发集群的重构。达到新的稳定状态后，再把位图状态 置为有效。当集群重构完成后，NM会把这个事件传递给CGS层，CGS负责同步所有节点间的重构。正常实例的启动、关闭过程中，Clusterware、NM都 会获得通知。但如果是 实例异常关闭，Clusterware,NM就会不知道，这时就需 要CGS提供的IMR功能进行感知。然后进行重构。

    IMR是由CGS提供的重构机制，用于确认实例之间的 连通性、快速地排除故障节点以减少到数据的损害。这个过程中，每个实例都要作出投票 ，投票的内容就是它所认为的整个集群现在状态，然后由一个实例根据这些投票，重新规划出一个新的集群(最大的sub group) 并把这个投票结果(voting result)记录到控制文件，其它节点读取这个结果，确认自己是否属于集群，如果不属于，就要自动退出。如果属于，则参与执行重构过程。投票过程中，所有的成员节点都尝试获得控制文件中的一个字段(CFVRR,Control File Vote Result Record)进行更新，但只会有一个成员获得，这个成员会记录其它成员的投票内容。

  比如 一个3节点的RAC，如果实例3的LMON异常，这时CFVRR记录如下：

  seq#     inst#    bitmap

    2           0           110

    2           1           110

    2           2           001

这时 实例3无法获得其它两个节点的状态，最终重构的结果就是实例1、2组成新的集群，节点3被赶出集群。

    如果IMR发现出现split-brain，即集群中出现两个group,这时IMR先会通知CM，然后等待CM解决这个脑裂 ，等待时间是＿IMR＿SPLITBRAIN＿RES＿WAIT， 缺省600 毫秒 。超时后IMR自己执行节点排除 。 在CGS完成节点的重构之后，GCS、GES才进行数据层面的重构，也就是Crash Recover。

    2、重构触发类型

    （1）有节点加入或离开集群而触发重构 ，由NM触发。

    （2）Network Heartbeat异常：因为LMON或者GCS、GES通信异常 ，由IMR触发。

    （3）Controlfile Heartbeat异常：第个实例的CKPT进程 每3 分钟都会更新控件文件的一个数据块 ，叫做Checkpoint Progress Record ，并且是每个实例对应一个 ，因此不会出现 争夺现象。由IMR 触发。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9683969/viewspace-676453/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9683969/viewspace-676453/