Oracle RAC(Cluster)的重构(整理)（2）

二是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 触发。

 

RAC层Cluster Reconfiguration Steps

The cluster reconfiguration process triggers IMR, and a seven-step process ensures complete reconfiguration.

1. Name service is frozen. The CGS contains an internal database of all the members/instances in the cluster with all their configuration and servicing

details. The name service provides a mechanism to address this configuration data in a structured and synchronized manner.

2. Lock database (IDLM) is frozen. The lock database is frozen to prevent processes from obtaining locks on resources that were mastered by the

departing/dead instance.

3. Determination of membership and validation and IMR.

4. Bitmap rebuild takes place, instance name and uniqueness verification. CGS must synchronize the cluster to be sure that all members get the

reconfiguration event and that they all see the same bitmap.

5. Delete all dead instance entries and republish all names newly configured.

6. Unfreeze and release name service for use.

7. Hand over reconfiguration to GES/GCS.

Now that you know when IMR starts and node evictions take place, let's look at the corresponding messages in the alert log and LMON trace files to get a

better picture. (The logs have been edited for brevity. Note all the lines in boldface define the most important steps in IMR and the handoff to other

recovery steps in CGS.)

 

node1的alert.log(node1 先启动)

Sat Jul 09 16:32:31 CST 2011

starting up 1 shared server(s) ...

Sat Jul 09 16:32:32 CST 2011

lmon registered with NM - instance id 1 (internal mem no 0)

Sat Jul 09 16:32:33 CST 2011

Reconfiguration started (old inc 0, new inc 2)

List of nodes:

 0

 Global Resource Directory frozen

* allocate domain 0, invalid = TRUE

 Communication channels reestablished

 Master broadcasted resource hash value bitmaps

 Non-local Process blocks cleaned out

Sat Jul 09 16:32:34 CST 2011

 LMS 0: 0 GCS shadows cancelled, 0 closed

 Set master node info

 Submitted all remote-enqueue requests

 Dwn-cvts replayed, VALBLKs dubious

 All grantable enqueues granted

 Post SMON to start 1st pass IR

Sat Jul 09 16:32:34 CST 2011

 LMS 0: 0 GCS shadows traversed, 0 replayed

Sat Jul 09 16:32:34 CST 2011

 Submitted all GCS remote-cache requests

 Fix write in gcs resources

Reconfiguration complete

 

Sat Jul 09 16:32:59 CST 2011

Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE)

Completed: ALTER DATABASE   MOUNT

Sat Jul 09 16:33:01 CST 2011

ALTER DATABASE OPEN

This instance was first to open

 

node1的alert.log（node2启动时）

Sat Jul 09 16:41:25 CST 2011

Reconfiguration started (old inc 0, new inc 4)

List of nodes:

 0 1

 Global Resource Directory frozen

* allocate domain 0, invalid = TRUE

 Communication channels reestablished

 * domain 0 valid = 1 according to instance 0

Sat Jul 09 16:41:26 CST 2011

 Master broadcasted resource hash value bitmaps

 Non-local Process blocks cleaned out

Sat Jul 09 16:41:26 CST 2011

 LMS 0: 0 GCS shadows cancelled, 0 closed

 Set master node info

 Submitted all remote-enqueue requests

 Dwn-cvts replayed, VALBLKs dubious

 All grantable enqueues granted

Sat Jul 09 16:41:27 CST 2011

 LMS 0: 0 GCS shadows traversed, 0 replayed

Sat Jul 09 16:41:27 CST 2011

 Submitted all GCS remote-cache requests

 Fix write in gcs resources

Reconfiguration complete

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

转载于:http://blog.itpub.net/758322/viewspace-702234/