記一次RAC數據節點2自動重啓故障解決

        最近生產上出了不少「奇怪」的問題，好比下面要分享的一個故障，一套11.2.0.4 兩節點RAC數據庫，2節點的集羣組件會不定日期的重啓，但重啓的時間段比較固定，都是凌晨4:50左右。並且幾分鐘就會恢復。廢話很少說，直接上整個問題的處理思路及過程。

        2節點上的集羣重啓，首先會去看集羣的alert日誌。看到故障時間點出錯以下圖的報錯：

        日誌中提示的很明顯，節點之間的心跳網絡丟失，致使節點2被驅逐出集羣。那網絡心跳丟失爲何只是集羣件重啓呢，這是因爲從11.2.0.2開始，引入了新特性rebootless restart，對於丟失網絡心跳致使的從新配置，只會發生GI重啓。

        那問題很明顯了，集羣網絡心跳丟失，致使2節點的GI重啓。那就來看是否是兩臺機器的私網網卡是否是出現了故障。

        先查看osw對私網的監控日誌，發現有丟包

        那由以上信息可以肯定是因爲私網網卡故障致使的嗎？

        想到之前看高斌老師的書《RAC核心技術詳解》有介紹過相似的現象，找來書一看，現象簡直是如出一轍，他那個案例中確實是因爲私網網卡有故障致使的。但咱們的故障也是嗎？

        找來網絡工程師來確認網卡的狀況。才知道，因爲私網網卡用的是ib卡，連的是ib交換機，不屬於咱們本身的維護範圍。因而找到數據中心來協助檢查，獲得的回覆是沒發現私網網卡有問題。

        那麼問題來了，私網網卡沒有問題，那會是什麼緣由致使網絡心跳丟失的呢。

        又想到有zabbix監控，能夠看當時私網網卡的流量狀況，看是否是有流量爲0的狀況，若是流量爲0，應該說明網卡出了問題，來看看監控圖

        從監控圖上看出問題時間私網網絡流量沒有降低，反到比平時要高出不少倍，最高峯達到440.64Mbps。

        從網絡工程師那瞭解到私網網卡是千兆的，也就是流量用了網卡的50%左右。也沒有達到網卡的瓶頸，那是什麼緣由致使網絡心跳丟失，又是什麼緣由致使問題時段比平時高出不少呢。

        正遇上一位數據分析的同事反映有一個job天天4點到5點執行，執行時間很是不穩定，有時3分鐘左右執行完成有時就須要70分鐘執行完。從ash看執行時間長時，主要是在等待gc的等待事件。gc是集羣等待事件，說明SQL訪問的相關表在其餘節點有併發。從awr和他給出的sql語句中定位到主要是發生在1張大表中。

        該表是從其餘庫經過ogg同步到本庫的，該表天天凌晨0-2點都會執行跑批操做，幾乎全表更新。查詢同步該表的ogg進程是鏈接到的是2節點，而他們的應用是鏈接到了1節點。立馬跟前面節點重啓前私網流量高關聯起來了，因爲0-2點該表在2節點經過ogg同步更新，而到了4點多，job中的sql在1節點執行，致使私網流量過大。

        彷佛問題明確了，因而採起措施，把ogg及job都鏈接到同一個節點，防止他們出現跨節點的數據塊交換。調整完後回家睡覺。

        次日早上起來，沒有收到數據庫4-5點dbtime高的短信告警，也沒有反映節點重啓，覺得問題解決了。來到公司發現dbtime只是降低到了告警值下一點，比以前沒有降低不少。再查看私網網絡流量，也沒有明顯降低，只是4-5點的那個job執行時間比較穩定了，穩定在了3分鐘左右。

        問題仍是沒有解決，但數據庫2節點也沒有再重啓，就這樣放了幾天。

        幾天後的晚上，值夜班，凌晨4：50被告警電話吵醒，數據庫2節點又自動重啓了。現象仍是同樣，重啓也很快。查看私網流量仍是很高，甚至達到了600Mbps。重啓後登陸節點2，發現上面跑了不少pxxx的進程，有100多個。因爲節點2不按期重啓，業務已經都鏈接1節點了，2節點應該不會有會話纔對。從進程類型來看應該是並行會話的子進程，沒有應用在跑，那並行進程又是從哪來的呢，難道是從1節點？想到前幾天與同事討論的跨節點並行，因而查看數據庫的parallel_force_local配置。

        果真設置的值爲false，便可以跨節點執行，參數詳細說明見下圖：

        想到這裏如獲至寶，因而把參數設置爲false

        alter system set parallel_force_local=true scope=both sid='*';

        該參數設置完後，觀察了幾天，私網網絡流量降到了以的同時段的1/10。

        從監控來看私網流量已經降低了不少，觀察了幾天，比較穩定。節點2也沒有再自動重啓。

        

        最後的猜測，多是因爲私網網絡過高致使私網網卡有擁堵，從而形成網絡心跳丟失。