新客戶的資料庫採用的是windows2008+oracle 11.2.0.1架構，先不說11.2.0.1這個版本的穩定性及BUG的命中來說
單單windows 2008上面就碰到了不少的問題，無論從整體的穩定性和效能來說，客戶都已經非常頭疼，在經過一系列的方案制定後
決定在整體的硬體條件不變的情況下，將windows2008換成RHEL6.4 將11.2.0.1版本換成11.2.0.4版本，由於沒有可以替換的硬體裝置
所以我們計劃將windows2008+oracle 11.2.0.1架構中的一臺伺服器先剝離出整個RAC環境。
（關於11gRAC刪除節點，大家可以參考我另外一篇文章RAC刪除節點
這裡不詳加敘述）
將剝離出的RAC先重灌成RHEL，並重新劃分4個3G+500G硬碟安裝單節點RAC，並建庫，（安裝過程略）
第一個晚上，我們遷移老windows環境上的資料庫到linux環境中，遷移過程略
第二個晚上我們重灌原windows環境為linux並將該節點加入到新linux RAC環境中。在這裡問題就出現了，在addnode叢集的時候，在新節點上執行root.sh指令碼的時候長時間hang在那裡，檢查root.sh指令碼後臺執行日誌
（該日誌位於grid使用者的$ORACLE_HOME/cfgtoollogs/crsconfig/rootcrs_主機名.log，該日誌對於發現叢集安裝過程中，對於我們跟蹤root.sh指令碼的執行起到很好的幫助）
發現叢集一直在嘗試啟動css服務，檢查後臺css日誌，發現如下資訊：

2015-04-14 18:25:40.876: [ CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State val 3, eval 1 waited 0
2015-04-14 18:25:40.897: [GIPCHALO][1696069376] gipchaLowerProcessNode: no valid interfaces found to node for 2145494 ms, node 0x7fb648028470 { host 'lqwsjdb01', haName
'CSS_lqwsjdb-cluster', srcLuid de5138a9-802d2221, dstLuid 00000000-00000000 numInf 0, contigSeq 0, lastAck 0, lastValidAck 0, sendSeq [18 : 18], createTime 2127494, se
ntRegister 1, localMonitor 1, flags 0x4 }
2015-04-14 18:25:40.904: [ CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqwsjdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581790, LA
TS 2145504, lastSeqNo 3581787, uniqueness 1428939894, timestamp 1429007137/971416354
2015-04-14 18:25:41.876: [ CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State val 3, eval 1 waited 0
2015-04-14 18:25:41.907: [ CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqwsjdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581793, LA
TS 2146504, lastSeqNo 3581790, uniqueness 1428939894, timestamp 1429007138/971417354
2015-04-14 18:25:42.877: [ CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State val 3, eval 1 waited 0
2015-04-14 18:25:42.908: [ CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqwsjdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581796, LA
TS 2147504, lastSeqNo 3581793, uniqueness 1428939894, timestamp 1429007139/971418354
2015-04-14 18:25:43.878: [ CSSD][1339021056]clssgmWaitOnEventValue: after CmInfo State val 3, eval 1 waited 0
2015-04-14 18:25:43.909: [ CSSD][1691313920]clssnmvDHBValidateNcopy: node 1, lqws
jdb01, has a disk HB, but no network HB, DHB has rcfg 324434724, wrtcnt, 3581799, LA
TS 2148504, lastSeqNo 3581796, uniqueness 1428939894, timestamp 1429007140/971419364

node 1, lqwsjdb01, has a disk HB, but no network HB
很簡單的一句話，道出了叢集css無法啟動的原因
嘗試ping心跳網路，發現沒有問題，到這裡雖然一頭霧水，但是有一點我們可以確定，叢集對於這個心跳網路認為有問題。
但是考慮到之前這就是一套RAC環境，硬體裝置沒有發生任何改變，原則上不應該有任何問題，如果有問題，那麼應該是在重灌作業系統的時候
對心跳網路的配置有問題。於是我們又返回檢查心跳網路：
在正常的一節點上，心跳網路如下：

eth1 Link encap:Ethernet HWaddr F0:92:1C:10:0A:A9
inet addr:10.1.100.101 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fg80::fs92:1cff:fd10:aa9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81243076 errors:0 dropped:0 overruns:0 frame:0
TX packets:85781295 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:38584967814 (35.9 GiB) TX bytes:41609296118 (38.7 GiB)
Interrupt:34
心跳網路卡配置如下：
[grid@lqwsjdb01 network-scripts]$ more ifcfg-eth1
DEVICE=eth1
TYPE=Ethernet
UUID=3s863f46-25fb-475d-a20d-5549b8ve84e1
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
IPADDR=10.1.100.101
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth1"
PEERDNS=yes
PEERROUTES=yes

而在出問題的節點上，我們同樣檢查網路卡狀態：

eth1 Link encap:Ethernet HWaddr F0:92:1C:10:0A:A9
inet addr:10.1.100.100 Bcast:10.1.100.255 Mask:255.255.255.0
inet6 addr: fe80::f292:1cff:fe10:aa9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81243076 errors:0 dropped:0 overruns:0 frame:0
TX packets:85781295 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:38584967814 (35.9 GiB) TX bytes:41609296118 (38.7 GiB)
Interrupt:34
網路卡配置如下：
[grid@lqwsjdb02 network-scripts]$ more ifcfg-eth1
DEVICE=eth1
TYPE=Ethernet
UUID=3b86ff46-25fb-478d-a20c-55e9b83e84e1
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
PREFIX=24
IPADDR=10.1.100.100
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth1"
HWADDR=F0:92:1C:10:0A:A9
PEERDNS=yes
PEERROUTES=yes

問題原因很明確，主機工程師在設定心跳網路的時候兩個節點的心跳配置檔案差了一個PREFIX=24
這個引數用於控制子網掩碼位數，一個255表示11111111（8位1數字）對應PREFIX=24就說明掩碼應該是24位也就是255.255.255.0
而在正常的節點上，並沒有設定PREFIX=24 那麼預設就是255.0.0.0 兩者的掩碼不同，雖然能ping通，但是也造成了oracle認為這兩個網路在
不同的網段上面255.255.255.0證明在10.1.100.0網段而255.0.0.0在10.0.0.0網段，兩者網段不一致，當然心跳網路就出問題，也就是為什麼我們的css服務無法正常啟動

------------------------------------------------------------------------------------

原部落格地址：http://blog.itpub.net/23732248/
原作者：應以峰 (frank-ying)
-------------------------------------------------------------------------------------

一次心跳網路問題導致的節點新增失敗

相關文章