故障處理之數據庫節(jié)點實例異常重啟

IT那活兒發(fā)布于2023-01-11 13:20 / 2939人閱讀

點擊上方藍字關注我們

大家好！最近遇到一起數據庫節(jié)點實例異常重啟故障，隨筆記記。

故障現象：

數據庫節(jié)點3因大量高并發(fā)insert語句導致sql積壓，從而短時間內消耗大量主機資源，對數據庫性能產生了很大影響，嚴重影響數據庫的正常運行，導致節(jié)點3數據庫發(fā)生重啟。

故障分析過程：

1、20點28分左右，收到節(jié)點3大量sql積壓短信告警,積壓SQL主要為：9yy1zhgjvfbpj。

節(jié)點3：

2、登陸環(huán)境核查數據庫實例狀態(tài)及實例啟動時間，20點36分確認數據庫實例狀態(tài)正常，且實例沒有重啟。當即對異常等待事件的sql進行查殺，但是由于應用還在不停的發(fā)起連接，在20點45分時節(jié)點3發(fā)生重啟。

3、查看主機日志，并確認無異常報錯信息。

節(jié)點3主機日志：

4、通過檢查數據庫運行狀況時發(fā)現節(jié)點3上有大量sql積壓的等待事件

對應等待事件主要為：enq:us-contention，rowcache local行緩存鎖,enq: IV - contention隊列等待之詢問IV。

附：

enq:us-contention：

這個等待事件有許多脫機撤消段，并且工作負載在短時間內開始聯機許多撤消段。當使用具有自動調整的撤銷保留期的系統(tǒng)管理撤銷時，這可能會導致在DC_ROLLBACK_SEGMENTS上出現高“閂鎖：行緩存對象”爭用，同時出現高“enq:US-爭用”等待。

rowcache local：

該是一個共享池相關的等待事件。是由于對于字典緩沖的訪問造成的。每一個行緩沖隊列鎖都對應一個特定的數據字典對象，這被叫做隊列鎖類型，并可以在V$ROWCACHE視圖中找到。在AWR中需要查看DictionaryCache Stats部分用以確定問題。

enq:IV - contention：

物化視圖（mview）有兩部分：（1）保存數據的表，和（2）摘要對象。當提交mview基表上的DML時，summary對象將失效。這是必要的，因為mview可能需要用于查詢重寫。失效采用IV排隊，直到summary對象在所有節(jié)點上失效為止。如果存在大量摘要無效，則會導致此排隊上的爭用。

5、通過核查節(jié)點3上sql積壓等待事件對應的會話信息，定位到積壓sql對應的sql_id，查到其sql文本就是一個insert語句。

節(jié)點3：

6、故障時間段節(jié)點3redo變化分析。

故障時間段每秒產生的redo量相比正常時間段增長了約180%。

故障時間段每秒產生redo量：

正常時間段每秒產生redo量：

7、查看會話變化情況發(fā)現從20點15分開始數據庫會話開始突增。

8、通過分析故障時間段哪些SQL占用了資源，發(fā)現其中sql_id為9yy1zhgjvfbpj的語句占用了數據庫48.24%的DBTIME。并最終于20:45分CPU資源耗盡導致實例重啟。

9yy1zhgjvfbpj語句執(zhí)行頻次突增截圖如下所示，11月2日故障時間段該sql執(zhí)行頻次上下浮動較大，而本次故障時間段該sql每分鐘的執(zhí)行頻次持續(xù)保持在四千+，最高峰甚至達到1萬+

結論：sql_id為9yy1zhgjvfbpj的語句因高并發(fā)且頻次突增，引發(fā)數據庫序列及undo爭用，消耗了大量的數據庫資源，數據庫主機最終CPU資源耗盡導致實例重啟。

建議如下：

建議一：應用連接降低并發(fā)，并查詢到該SQL是單次commit，建議修改成批量提交。

建議二：先將高并發(fā)insert寫入內存庫，然后在批量同步至核心庫。

END

GPU云服務器云服務器數據之星國外節(jié)點服務器故障重啟日志故障處理異常處理異常

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://systransis.cn/yun/130007.html

【獨家】終生受用的Redis高可用技術解決方案大全

摘要：哨兵是社區(qū)版本推出的原生高可用解決方案，部署架構主要包括兩部分集群和數據集群，其中集群是由若干節(jié)點組成的分布式集群。自研推薦推薦自研的高可用解決方案，主要體現在配置中心故障探測和的處理機制上，通常需要根據企業(yè)業(yè)務的實際線上環(huán)境來定制化。最近很多朋友向我咨詢關于高可用的方案的優(yōu)缺點以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業(yè)內訓的時候也詳細講過，這里我再整理發(fā)出來...

cc17 2019-08-16 12:42 評論0 收藏0
【獨家】終生受用的Redis高可用技術解決方案大全

摘要：哨兵是社區(qū)版本推出的原生高可用解決方案，部署架構主要包括兩部分集群和數據集群，其中集群是由若干節(jié)點組成的分布式集群。自研推薦推薦自研的高可用解決方案，主要體現在配置中心故障探測和的處理機制上，通常需要根據企業(yè)業(yè)務的實際線上環(huán)境來定制化。最近很多朋友向我咨詢關于高可用的方案的優(yōu)缺點以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業(yè)內訓的時候也詳細講過，這里我再整理發(fā)出來...

helloworldcoding 2019-06-24 18:06 評論0 收藏0
云計算節(jié)點故障自動化運維服務設計

此文已由作者王盼授權網易云社區(qū)發(fā)布。歡迎訪問網易云社區(qū)，了解更多網易技術產品運營經驗~ 現狀計算節(jié)點發(fā)生磁盤損壞等數據無法恢復的異常時，節(jié)點上的云主機系統(tǒng)盤無法恢復，導致云主機只能被清理重建計算節(jié)點宕機但磁盤數據可用時，重啟即可恢復所有云主機的運行計算節(jié)點多次宕機（或一段時間內頻繁宕機），則需要遷移所有云主機或者直接清理重建，云硬盤需要遷移到其他cinder-volume存儲服務節(jié)點一般來...

seanHai 2019-06-28 10:59 評論0 收藏0
Akka系列（六）：Actor解決了什么問題？

摘要：原文鏈接解決了什么問題使用模型來克服傳統(tǒng)面向對象編程模型的局限性，并應對高并發(fā)分布式系統(tǒng)所帶來的挑戰(zhàn)。在某些情況，這個問題可能會變得更糟糕，工作線程發(fā)生了錯誤但是其自身卻無法恢復。這段時間由于忙畢業(yè)前前后后的事情，拖更了很久，表示非常抱歉，回歸后的第一篇文章主要是看到了Akka最新文檔中寫的What problems does the actor model solve?,閱讀完后覺...

Carson 2019-08-15 10:45 評論0 收藏0
從 Pods 和 Nodes 的出生入死詳解 Kubernetes 的控制邏輯

摘要：祈使式的腳本很難長期地對系統(tǒng)狀態(tài)進行自動維護。這些事件包括的創(chuàng)建消亡的更新例如標簽副本數量等。每當上述事件發(fā)生，這個事件所牽扯到的具體的對象就會被放入這個工作隊列中。本期文章來自才云科技（Caicloud）CEO 張鑫的技術原創(chuàng)。導言：Kubernetes 是一個龐大的軟件系統(tǒng)，欲從源碼層精通 Kubernetes 的進階學習者往往會經歷 Kubernetes：從入門到放棄的挫敗...

yhaolpz 2019-07-01 16:35 評論0 收藏0
程序員都應該了解的運維知識經驗

摘要：負載均衡器又分為四層和七層負載均衡器，顧名思義，四層的工作在協(xié)議棧上，通過修改請求報文的源目的地址和源目的端口來轉發(fā)，比如，一個主機對應一個域名，適用于每秒超過一萬的業(yè)務。每一次變更都是一次發(fā)布，每一次發(fā)布都是一個獨立的鏡像啟動 showImg(https://segmentfault.com/img/bVbvtgW?w=1080&h=720); 以一個經典問題拋磚引玉，當用戶在瀏覽器...

reclay 2019-08-16 18:41 評論0 收藏0