資訊專欄INFORMATION COLUMN
點(diǎn)擊上方“IT那活兒”公眾號，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！?。?/strong>
故障現(xiàn)象
故障分析
2.1 20點(diǎn)28分左右，收到節(jié)點(diǎn)3大量sql積壓短信告警,積壓SQL主要為：9yy1zhgjvfbpj.
節(jié)點(diǎn)3：
2.2 登陸環(huán)境核查數(shù)據(jù)庫實(shí)例狀態(tài)及實(shí)例啟動(dòng)時(shí)間，20點(diǎn)36分確認(rèn)數(shù)據(jù)庫實(shí)例狀態(tài)正常，且實(shí)例沒有重啟。當(dāng)即對異常等待事件的sql進(jìn)行查殺，但是由于應(yīng)用還在不停的發(fā)起連接，在20點(diǎn)45分時(shí)節(jié)點(diǎn)3發(fā)生重啟。
2.3 查看主機(jī)日志，并確認(rèn)無異常報(bào)錯(cuò)信息。
節(jié)點(diǎn)3主機(jī)日志：
2.4 通過檢查數(shù)據(jù)庫運(yùn)行狀況時(shí)發(fā)現(xiàn)節(jié)點(diǎn)3上有大量sql積壓的等待事件。
enq:us-contention，rowcache local行緩存鎖；
enq: IV - contention隊(duì)列等待之詢問IV。
附：
enq:us-contention
rowcache local
enq:IV - contention
物化視圖（mview）有兩部分：
1）保存數(shù)據(jù)的表；
2）摘要對象。
當(dāng)提交mview基表上的DML時(shí)，summary對象將失效。這是必要的，因?yàn)閙view可能需要用于查詢重寫。失效采用IV排隊(duì)，直到summary對象在所有節(jié)點(diǎn)上失效為止。如果存在大量摘要無效，則會導(dǎo)致此排隊(duì)上的爭用。
2.5 通過核查節(jié)點(diǎn)3上sql積壓等待事件對應(yīng)的會話信息，定位到積壓sql對應(yīng)的sql_id，查到其sql文本就是一個(gè)insert語句。
節(jié)點(diǎn)3：
2.6 故障時(shí)間段節(jié)點(diǎn)3redo變化分析。
故障時(shí)間段每秒產(chǎn)生的redo量相比正常時(shí)間段增長了約180%。
故障時(shí)間段每秒產(chǎn)生redo量：
正常時(shí)間段每秒產(chǎn)生redo量：
2.7 查看會話變化情況發(fā)現(xiàn)從20點(diǎn)15分開始數(shù)據(jù)庫會話開始突增。
2.8 通過分析故障時(shí)間段哪些SQL占用了資源，發(fā)現(xiàn)其中sql_id為9yy1zhgjvfbpj的語句占用了數(shù)據(jù)庫48.24%的DBTIME。并最終于20:45分CPU資源耗盡導(dǎo)致實(shí)例重啟。
9yy1zhgjvfbpj語句執(zhí)行頻次突增截圖如下所示，11月2日故障時(shí)間段該sql執(zhí)行頻次上下浮動(dòng)較大，而本次故障時(shí)間段該sql每分鐘的執(zhí)行頻次持續(xù)保持在四千+，最高峰甚至達(dá)到1萬+.
結(jié)論：sql_id為9yy1zhgjvfbpj的語句因高并發(fā)且頻次突增，引發(fā)數(shù)據(jù)庫序列及undo爭用，消耗了大量的數(shù)據(jù)庫資源，數(shù)據(jù)庫主機(jī)最終CPU資源耗盡導(dǎo)致實(shí)例重啟。
建議一：應(yīng)用連接降低并發(fā)，并查詢到該SQL是單次commit，建議修改成批量提交。
建議二：先將高并發(fā)insert寫入內(nèi)存庫，然后在批量同步至核心庫。
文章首發(fā)于2021年2月6日
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/129221.html
摘要：哨兵是社區(qū)版本推出的原生高可用解決方案，部署架構(gòu)主要包括兩部分集群和數(shù)據(jù)集群，其中集群是由若干節(jié)點(diǎn)組成的分布式集群。自研推薦推薦自研的高可用解決方案，主要體現(xiàn)在配置中心故障探測和的處理機(jī)制上，通常需要根據(jù)企業(yè)業(yè)務(wù)的實(shí)際線上環(huán)境來定制化。 最近很多朋友向我咨詢關(guān)于高可用的方案的優(yōu)缺點(diǎn)以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業(yè)內(nèi)訓(xùn)的時(shí)候也詳細(xì)講過，這里我再整理發(fā)出來...
摘要：哨兵是社區(qū)版本推出的原生高可用解決方案，部署架構(gòu)主要包括兩部分集群和數(shù)據(jù)集群，其中集群是由若干節(jié)點(diǎn)組成的分布式集群。自研推薦推薦自研的高可用解決方案，主要體現(xiàn)在配置中心故障探測和的處理機(jī)制上，通常需要根據(jù)企業(yè)業(yè)務(wù)的實(shí)際線上環(huán)境來定制化。 最近很多朋友向我咨詢關(guān)于高可用的方案的優(yōu)缺點(diǎn)以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業(yè)內(nèi)訓(xùn)的時(shí)候也詳細(xì)講過，這里我再整理發(fā)出來...
此文已由作者王盼授權(quán)網(wǎng)易云社區(qū)發(fā)布。 歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營經(jīng)驗(yàn)~ 現(xiàn)狀計(jì)算節(jié)點(diǎn)發(fā)生磁盤損壞等數(shù)據(jù)無法恢復(fù)的異常時(shí)，節(jié)點(diǎn)上的云主機(jī)系統(tǒng)盤無法恢復(fù)，導(dǎo)致云主機(jī)只能被清理重建 計(jì)算節(jié)點(diǎn)宕機(jī)但磁盤數(shù)據(jù)可用時(shí)，重啟即可恢復(fù)所有云主機(jī)的運(yùn)行 計(jì)算節(jié)點(diǎn)多次宕機(jī)（或一段時(shí)間內(nèi)頻繁宕機(jī)），則需要遷移所有云主機(jī)或者直接清理重建，云硬盤需要遷移到其他cinder-volume存儲服務(wù)節(jié)點(diǎn) 一般來...
摘要：原文鏈接解決了什么問題使用模型來克服傳統(tǒng)面向?qū)ο缶幊棠Ｐ偷木窒扌?，并?yīng)對高并發(fā)分布式系統(tǒng)所帶來的挑戰(zhàn)。在某些情況，這個(gè)問題可能會變得更糟糕，工作線程發(fā)生了錯(cuò)誤但是其自身卻無法恢復(fù)。 這段時(shí)間由于忙畢業(yè)前前后后的事情，拖更了很久，表示非常抱歉，回歸后的第一篇文章主要是看到了Akka最新文檔中寫的What problems does the actor model solve?,閱讀完后覺...
摘要：祈使式的腳本很難長期地對系統(tǒng)狀態(tài)進(jìn)行自動(dòng)維護(hù)。這些事件包括的創(chuàng)建消亡的更新例如標(biāo)簽副本數(shù)量等。每當(dāng)上述事件發(fā)生，這個(gè)事件所牽扯到的具體的對象就會被放入這個(gè)工作隊(duì)列中。 本期文章來自才云科技（Caicloud）CEO 張鑫的技術(shù)原創(chuàng)。導(dǎo)言：Kubernetes 是一個(gè)龐大的軟件系統(tǒng)，欲從源碼層精通 Kubernetes 的進(jìn)階學(xué)習(xí)者往往會經(jīng)歷 Kubernetes：從入門到放棄 的挫敗...
摘要：負(fù)載均衡器又分為四層和七層負(fù)載均衡器，顧名思義，四層的工作在協(xié)議棧上，通過修改請求報(bào)文的源目的地址和源目的端口來轉(zhuǎn)發(fā)，比如，一個(gè)主機(jī)對應(yīng)一個(gè)域名，適用于每秒超過一萬的業(yè)務(wù)。每一次變更都是一次發(fā)布，每一次發(fā)布都是一個(gè)獨(dú)立的鏡像啟動(dòng) showImg(https://segmentfault.com/img/bVbvtgW?w=1080&h=720); 以一個(gè)經(jīng)典問題拋磚引玉，當(dāng)用戶在瀏覽器...
閱讀 1359·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1908·2023-01-11 13:20
閱讀 4166·2023-01-11 13:20
閱讀 2759·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3673·2023-01-11 13:20
