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/，如需轉載，請註明出處，否則將追究法律責任。