前言

眾所周知巍实，數(shù)據(jù)庫是一個(gè)互聯(lián)網(wǎng)企業(yè)的核心滓技，每個(gè)公司都恨不得像守護(hù)剛出生的嬰兒一樣守護(hù)著它。但就算是7*24小時(shí)監(jiān)控著棚潦，數(shù)據(jù)庫也可能會(huì)出現(xiàn)天災(zāi)令漂，更不要提一些人禍了。今天就跟大家總結(jié)一下我們公司數(shù)據(jù)庫遇到的一些問題丸边。

存儲(chǔ) info 級(jí)日志坑

某一天叠必，監(jiān)控?cái)?shù)據(jù)顯示交易量忽高忽低，沒有規(guī)律妹窖，重災(zāi)區(qū)是設(shè)置交易超時(shí)時(shí)間的某產(chǎn)品纬朝，交易出現(xiàn)大量失敗，客戶投訴嚴(yán)重骄呼。大家聚焦問題共苛，執(zhí)行代碼回滾方案仍無法解決，同時(shí)觀察數(shù)據(jù)庫現(xiàn)象為事務(wù)突然停滯數(shù)秒蜓萄，然后又恢復(fù)正常隅茎，無時(shí)間規(guī)律以此反復(fù)。DBA 排查存儲(chǔ)日志也未見異常 error嫉沽，同時(shí)協(xié)調(diào) IBM 分析這些日志辟犀，最終反饋有個(gè) info 級(jí)日志無規(guī)律報(bào)某塊 disk miss，建議更換硬盤試試绸硕，結(jié)果更換后交易恢復(fù)正常堂竟，此故障被 IBM 收集入案例庫。

總結(jié)：日常巡檢不要放過任何細(xì)節(jié)臣咖，info 級(jí)別日志也可能是 error 級(jí)別跃捣，也可能是致命的。

BUG 類高并發(fā)短小事務(wù)坑

某年考試集中報(bào)名夺蛇，應(yīng)用頻繁出現(xiàn)繁忙疚漆，線程報(bào)警，導(dǎo)致交易時(shí)斷時(shí)續(xù)。查看數(shù)據(jù)庫端負(fù)載稍微偏高娶聘，事務(wù)量是平常的 4 倍多闻镶，分析事務(wù)量與交易量并不成正比，進(jìn)一步排查發(fā)現(xiàn)執(zhí)行頻率最高的 SQL 達(dá)到每秒 2000 次以上丸升。通過一個(gè)簡(jiǎn)單的銀行字典查詢铆农，開發(fā)人員定位問題為此考試接口為定制代碼，有多次重復(fù)查詢 BUG狡耻。緊急修復(fù)后交易正常墩剖。

總結(jié)：優(yōu)化核心交易事務(wù)，精簡(jiǎn)代碼夷狰，嚴(yán)格控制代碼質(zhì)量岭皂。

悲催的各種用盡坑

DBA 發(fā)現(xiàn)由于最初的設(shè)計(jì)原因，交易流水表 ID 使用的是 INT 類型的 sequence沼头，這使得交易流水表 ID很快就會(huì)用盡并導(dǎo)致交易停止爷绘。于是排查類似的可能用盡的坑，發(fā)現(xiàn)數(shù)據(jù)庫日志 SN 居然也能用盡进倍，只有升級(jí)版本后才能解決此問題土至，再一看當(dāng)前 SN 號(hào)一身冷汗，此時(shí)推算核心交易庫將在半年后用盡 SN 進(jìn)入只讀模式猾昆，后果不堪設(shè)想陶因。繼續(xù)探坑又有新發(fā)現(xiàn)，LINUX 平臺(tái) ETX3 文件系統(tǒng)單文件最大只支持 2T毡庆，而線上已經(jīng)有存到 1.5T坑赡。

總結(jié)：坑也是無窮無盡的，想不掉下去么抗，那就積極主動(dòng)探坑吧毅否。

半死不活的硬件故障坑

某日短信通知系統(tǒng)中斷，電話應(yīng)急處理過程中 NOC 反饋未發(fā)現(xiàn)任何數(shù)據(jù)庫服務(wù)器有可用性報(bào)警蝇刀，但開發(fā)反饋應(yīng)用無法連接數(shù)據(jù)庫螟加，于是 DBA 嘗試登錄此服務(wù)器發(fā)現(xiàn)能 ping 通，但 ssh 無法連接吞琐。立刻登陸遠(yuǎn)控卡發(fā)現(xiàn) RAID 卡報(bào)錯(cuò)導(dǎo)致系統(tǒng) hang捆探，執(zhí)行數(shù)據(jù)庫切換方案后，業(yè)務(wù)恢復(fù)正常站粟。

總結(jié)：系統(tǒng) hang 會(huì)導(dǎo)致 Agent 報(bào)警黍图，數(shù)據(jù)無法推送到服務(wù)端。報(bào)警策略一定要配置采集數(shù)據(jù)超時(shí)時(shí)間奴烙，避免不能及時(shí)發(fā)現(xiàn)故障助被。

交易事務(wù)中亂七八糟的其他調(diào)用坑

核心交易數(shù)據(jù)庫事務(wù)應(yīng)該是最簡(jiǎn)潔并且效率最高的 SQL剖张，如果調(diào)用其它資源響應(yīng)時(shí)間慢或無響應(yīng)，會(huì)直接影響主線交易揩环。此類操作應(yīng)做異步處理搔弄，此坑已經(jīng)埋了很多人。

總結(jié)：核心交易事務(wù)代碼必須嚴(yán)格審查丰滑，重視不夠必進(jìn)坑顾犹。

數(shù)據(jù)庫不可用導(dǎo)致應(yīng)用無法啟動(dòng)的坑

線上有一些非核心數(shù)據(jù)庫，如歸檔庫褒墨，只對(duì)外提供歷史數(shù)據(jù)的查詢炫刷，為節(jié)約硬件成本，此庫可用性標(biāo)準(zhǔn) 999郁妈。偶然一次代碼上線過程中柬唯，應(yīng)用啟動(dòng)后 hang 住了，日志無任何輸出圃庭，問題無從查起。而此時(shí)某臺(tái)歷史庫正在維護(hù)失晴，由此推斷是否和數(shù)據(jù)庫有關(guān)剧腻，查代碼后發(fā)現(xiàn)果然如此，代碼對(duì)于數(shù)據(jù)庫異常未做任何處理涂屁，無 try catch书在。此問題如果在上線階段發(fā)生，其后果將是災(zāi)難性的拆又。

總結(jié)：日志輸出一定要遵循軟件設(shè)計(jì)原則儒旬，系統(tǒng)日志的缺失對(duì)于緊急問題定位是災(zāi)難性的。

缺乏溝通的坑

某天晚上接到系統(tǒng)人員通知帖族，數(shù)據(jù)庫不可用栈源，交易中斷。接到通知后竖般， DBA 檢查數(shù)據(jù)庫狀態(tài)甚垦，發(fā)現(xiàn)數(shù)據(jù)庫表空間處于不可用狀態(tài)。通過檢查數(shù)據(jù)文件和詢問系統(tǒng)人員做過什么涣雕，得知系統(tǒng)人員維護(hù)系統(tǒng)艰亮，修改了數(shù)據(jù)文件的權(quán)限，導(dǎo)致數(shù)據(jù)庫不可用挣郭。后修改數(shù)據(jù)文件權(quán)限迄埃，并前滾數(shù)據(jù)庫，故障恢復(fù)兑障。

總結(jié)：數(shù)據(jù)庫設(shè)備任何變更侄非，都要和 DBA 進(jìn)行溝通確認(rèn)蕉汪，不起眼的失誤會(huì)導(dǎo)致災(zāi)難的發(fā)生。

總結(jié)

通過以上例子可以發(fā)現(xiàn)彩库，一個(gè)小小的操作肤无，都可能導(dǎo)致數(shù)據(jù)庫崩潰，造成不可挽回的損失骇钦。希望大家一定要遵守各種規(guī)范宛渐，三思而后行，凡事多想一步眯搭。你的一小步窥翩，穩(wěn)定一大步。讓我們的運(yùn)維人員有一個(gè)完美的夜生活鳞仙！