【RAC】11gR2 新特性： Rebootless Restart

眾所周知，當叢集出現問題時，例如某個節點丟失網路心跳，或者不能夠訪問表決盤，或者節點出現了嚴重的效能問題等，CRS會選擇將某個節點的OS 重啟，以便保證叢集的一致性。當然，大部分的重啟都是由CRS的核心程式ocssd.bin發起的。 但是，如果CRS 只是節點上的應用之一或者私網和儲存的問題只是短時間的出現，那麼重啟節點的行為就會導致節點上所有的應用全部停止，這在很多系統上並不是我們希望看到的。

所以從版本11.2.0.2 開始，oracle新特性rebootless restart被介紹。當出現以下情況的時候，叢集件（GI）會重新啟動叢集管理軟體，而不是將節點重啟。
1.當某個節點連續丟失網路心跳超過misscount時。
2.當某個節點不能訪問大多數表決盤（VF）時。
3.當member kill 被升級成為node kill的時候。
在之前的版本，以上情況，叢集管理軟體（CRS）會直接重啟節點。

之後，我們透過幾個例子瞭解上面提到的幾種情況。
1.當某個節點連續丟失網路心跳超過misscount的情況
2010-08-13 17:00:26.213: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 50% heartbeat fatal, removal in 14.540 seconds
……
2010-08-13 17:00:33.227: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 75% heartbeat fatal, removal in 7.470 seconds
……
2010-08-13 17:00:38.236: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 90% heartbeat fatal, removal in 2.460 seconds, seedhbimpd 1 ?本地節點report 遠端節點丟失本地心跳
……
2010-08-13 17:00:40.707: [    CSSD][4052061088](:CSSNM00008: )clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 1 nodes with leader 2, <nodename>, is smaller than cohort of 1 nodes led by node 1, <nodename>, based on map type 2 ? 為了避免split-brain ，本地節點重新啟動GI。
2010-08-13 17:00:40.707: [    CSSD][4052061088]###################################
2010-08-13 17:00:40.707: [    CSSD][4052061088]clssscExit: CSSD aborting from thread clssnmRcfgMgrThread 
2010-08-13 17:00:40.707: [    CSSD][4052061088]###################################
2.當某個節點不能訪問大多數表決盤（VF）的情況
2010-08-13 18:31:23.782: [    CSSD][150477728]clssnmvDiskOpen: Opening /dev/sdb8
2010-08-13 18:31:23.782: [   SKGFD][150477728]Handle 0xf43fc6c8 from lib :UFS:: for disk :/dev/sdb8:

2010-08-13 18:31:23.782: [    CLSF][150477728]Opened hdl:0xf4365708 for dev:/dev/sdb8:
2010-08-13 18:31:23.787: [   SKGFD][150477728]ERROR: -9(Error 27072, OS Error (Linux Error: 5: Input/output error ? 訪問表決盤出錯。
Additional information: 4
Additional information: 720913
Additional information: -1)
)
2010-08-13 18:31:23.787: [    CSSD][150477728](:CSSNM00060: )clssnmvReadBlocks: read failed at offset 17 of /dev/sdb8
……
2010-08-13 18:34:38.206: [    CSSD][4110736288](:CSSNM00018: )clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1 ?在經過long disk timeout時間之後，GI被重新啟動。
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################
2010-08-13 18:34:38.206: [    CSSD][4110736288]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread 
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################

3.member kill 被升級成為node kill的情況。
2013-01-14 23:49:52.093: [    CSSD][45]clssgmmkLocalKillThread: Time up. Timeout 30500 Start time 130388522 End time 130419022 Current time 130419087 ?member kill 超時發生
2013-01-14 23:49:52.093: [    CSSD][45]clssgmmkLocalKillResults: Replying to kill request from remote node 1 kill id 1 Success map 0x00000000 Fail map 0x00000000
……
2013-01-14 23:49:52.235: [    CSSD][31](:CSSNM00005: )clssnmvDiskKillCheck: Aborting, evicted by node <nodename>, number 1, sync 239654498, stamp 130416886 ?該節點被驅逐出叢集，也就是重啟GI
2013-01-14 23:49:52.235: [    CSSD][31]###################################
2013-01-14 23:49:52.235: [    CSSD][31]clssscExit: CSSD aborting from thread clssnmvKillBlockThread
2013-01-14 23:49:52.235: [    CSSD][31]###################################
2013-01-14 23:49:52.235: [    CSSD][31](:CSSSC00012: )clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally

從上面的輸出，我們能看到三種情況中ocssd.bin程式都能夠正常地工作，當出現問題時，能過做出正確的決定。所以，rebootless restart能夠保證由ocssd.bin主動發起的重啟。但是，如果是由於ocssd.bin 出現問題（例如：掛起），或者作業系統效能引起的重啟，rebootless restart是無法起作用的，因為，對於這種情況ocssd.bin已經不能正常工作，節點重啟仍然不可避免。具體關於如何診斷節點重啟的問題，請參考之前的文章 “11gR2 如何診斷節點重啟問題”。

GI 在重啟叢集之前，首先要對叢集進行graceful shutdown, 基本的步驟如下。
1．停止本地節點的所有心跳（網路心跳，磁碟心跳和本地心跳）。
2．通知cssd agent，ocssd.bin即將停止
3．停止所有註冊到css的具有i/o能力的程式，例如 lmon。
4．cssd通知crsd 停止所有資源，如果crsd不能成功的停止所有的資源，節點重啟仍然會發生。
5．Cssd等待所有的具有i/o能力的程式退出，如果這些程式在short i/o timeout時間內不能不能全部推遲，節點重啟仍然會發生。
6．通知cssd agent 所有的有i/o能力的程式全部退出。
7．Ohasd 重新啟動叢集。
8．本地節點通知其他節點進行叢集重配置。

綜上所述，對於11.2.0.2 及以上版本的叢集，如果您發現了節點重啟，那麼，ocssd.bin 掛???或者作業系統效能的問題應該是首先檢查的內容。當然，如果rebootless restart的gracefull shutdown 不能在指定的時間內完成，節點重啟仍然會發生，這需要檢視ocssd.log進行診斷。

如果您希望對這篇文章進行進一步的討論，請在以下的連結回覆。

https://communities.oracle.com/portal/server.pt/community/view_discussion_topic/216?threadid=536867&Portlet=Create%20Discussion&PrevPage=Communities-CreateDiscussion