騰訊數(shù)據(jù)庫(kù)專家雷海林分享智能運(yùn)維架構(gòu)

　　點(diǎn)擊上方藍(lán)字每天學(xué)習(xí)數(shù)據(jù)庫(kù)

　　2019年5月8日-10日的DTCC2019年中國(guó)數(shù)據(jù)庫(kù)大會(huì)上，騰訊云數(shù)據(jù)庫(kù)專家工程師雷海林首受邀做了主題為《TDSQL智能運(yùn)維平臺(tái)-扁鵲架構(gòu)與實(shí)踐》的技術(shù)分享，以下為大會(huì)現(xiàn)場(chǎng)演講實(shí)錄。

　　雷海林在大會(huì)現(xiàn)場(chǎng)

　　關(guān)注“騰訊云數(shù)據(jù)庫(kù)”官方微信，回復(fù)“智能運(yùn)維”，即可下載本文PPT。

　　一、扁鵲的基本介紹

　　扁鵲系統(tǒng)是TDSQL面向云市場(chǎng)推出的一款針對(duì)數(shù)據(jù)庫(kù)性能/故障等問(wèn)題的自動(dòng)化分析并為用戶提供優(yōu)化/解決方案的產(chǎn)品。

　　1. 扁鵲的需求背景

　　TDSQL作為騰訊針對(duì)金融場(chǎng)景推出的高一致，分布式數(shù)據(jù)庫(kù)集群的解決方案目前已覆蓋了騰訊90%的支付業(yè)務(wù)場(chǎng)景，內(nèi)部有大量團(tuán)隊(duì)使用；同時(shí)作為騰訊金融云的數(shù)據(jù)庫(kù)產(chǎn)品，支持公有云和專有云兩種云解決方案，目前擁有了大量的政府，銀行、保險(xiǎn)、物流、電商等客戶，但隨著客戶和集群規(guī)模的不斷擴(kuò)大，在TDSQL運(yùn)營(yíng)過(guò)程中也帶來(lái)了很大的挑戰(zhàn)。

　　針對(duì)這些問(wèn)題，我們認(rèn)為需要一個(gè)自動(dòng)化的故障/性能問(wèn)題分析系統(tǒng)，減少DBA的重復(fù)勞動(dòng)，沉淀我們的分析經(jīng)驗(yàn)，快速定位問(wèn)題，帶給我們的客戶最快速的響應(yīng)同時(shí)也提升DBA的幸福指數(shù)。

　　之所以將這個(gè)模塊命名為扁鵲，就是希望它能像古代的扁鵲神醫(yī)為人診斷病因一樣也可以為數(shù)據(jù)庫(kù)“對(duì)癥下藥“，治療/修復(fù)/預(yù)判數(shù)據(jù)庫(kù)已知或潛在的風(fēng)險(xiǎn)。

　　2. 扁鵲的作用

　　在開發(fā)扁鵲系統(tǒng)的時(shí)候，隨著DBA的專家知識(shí)庫(kù)不斷向扁鵲輸入，目前我們大部分現(xiàn)網(wǎng)的性能/故障問(wèn)題基本都可以通過(guò)我們扁鵲一鍵分析原因，大大解放了DBA的雙手，極大提高了運(yùn)營(yíng)效率。下圖是我們對(duì)扁鵲在設(shè)計(jì)階段所設(shè)定的基本功能和目標(biāo)，核心點(diǎn)就是希望扁鵲能做到風(fēng)險(xiǎn)事前預(yù)警，事中準(zhǔn)確分析原因并解決問(wèn)題，事后能對(duì)歷史事件進(jìn)行分析，發(fā)現(xiàn)問(wèn)題點(diǎn)。

　　二、系統(tǒng)架構(gòu)

　　扁鵲大體可以分為下圖中的六個(gè)層次結(jié)構(gòu)

　　資源層主要包括DB實(shí)例和宿主機(jī)，提供各種原始的信息

　　采集層會(huì)從資源層采集一些性能指標(biāo)，SQL日志，表結(jié)構(gòu)等必要的診斷信息并輸送到存儲(chǔ)層

　　存儲(chǔ)層負(fù)責(zé)將采集層提供的信息持久化，以供后續(xù)對(duì)歷史數(shù)據(jù)進(jìn)行分析

　　索引層會(huì)從存儲(chǔ)層提取數(shù)據(jù)再次進(jìn)行分類并形成可編程的數(shù)據(jù)結(jié)構(gòu)，也是分析層所需要的診斷單元

　　分析層是扁鵲的核心邏輯，主要負(fù)責(zé)利用索引層的元數(shù)據(jù)信息結(jié)合TDSQL自身沉淀的知識(shí)庫(kù)對(duì)數(shù)據(jù)庫(kù)常見異常如主備切換，主備延遲，等問(wèn)題進(jìn)行根音分析，風(fēng)險(xiǎn)評(píng)估

　　展示層最終會(huì)將分析層的結(jié)果可視化，大體可分為健康報(bào)表和具體的故障/性能/優(yōu)化建議

　　下圖展示了扁鵲更細(xì)化的結(jié)構(gòu)，可以看到扁鵲具備了哪些功能，這些功能需要哪些元數(shù)據(jù)，元數(shù)據(jù)又從哪些層面獲取，各模塊之間如何交互等，如果大家要做類似的功能可以基于這個(gè)做一個(gè)很好的參考。

　　三、智能診斷原理與實(shí)踐

　　我們將客戶經(jīng)常咨詢的DB問(wèn)題大體分為三類，可用性問(wèn)題、性能問(wèn)題、可靠性問(wèn)題。

　　下面我們具體看一下扁鵲是怎樣針對(duì)這三類問(wèn)題進(jìn)行分析并解決的。

　　1. 可用性問(wèn)題

　　可用性問(wèn)題主要是指DB在一段時(shí)間內(nèi)無(wú)法響應(yīng)用戶的請(qǐng)求

　　TDSQL作為金融級(jí)數(shù)據(jù)庫(kù)本身是做了高可用的，當(dāng)主機(jī)出現(xiàn)異常無(wú)法繼續(xù)提供服務(wù)時(shí)會(huì)自動(dòng)選則新主切換。這里我們探測(cè)主是否存活的方法是利用一個(gè)agent模塊定期的連接DB并向TDSQL自建的一個(gè)心跳表中寫入數(shù)據(jù)，這樣無(wú)論是磁盤壞塊，磁盤滿了還是DB重啟導(dǎo)致DB不可用，agent都能準(zhǔn)確的判斷出來(lái)，當(dāng)agent連續(xù)一段時(shí)間寫入心跳失敗或超時(shí)就會(huì)觸發(fā)切換的邏輯，在這期間DB會(huì)處于短暫的秒級(jí)不可用狀態(tài)，從用戶側(cè)可能會(huì)收到DB只讀，連接斷開等異常。對(duì)于這種情況，業(yè)務(wù)往往需要清楚地知道切換的原因是什么，如何避免切換再次發(fā)生。

　　引起切換的原因有很多，這里我們列舉了一些常見因素，如觸發(fā)了內(nèi)核某個(gè)bug導(dǎo)致DB重啟hung住，磁盤故障導(dǎo)致DB無(wú)法寫入。也有可能是由于用戶的一些SQL過(guò)度的占用一些CPU、IO等資源導(dǎo)致的，如大事務(wù)，慢查詢并發(fā)影響到用戶或心跳線程寫入等等。

　　要分析出切換問(wèn)題的原因，我們首先要做的就是保留必要的現(xiàn)場(chǎng)信息，為我們后續(xù)的診斷提供線索。

　　這里我們實(shí)現(xiàn)了針對(duì)top，iotop，iostat等宿主機(jī)資源狀態(tài)信息的秒級(jí)采集以及切換前DB內(nèi)部processlist，innodbstatus等快照信息。我們上面列舉的異常原因基本都可以在這些信息中反映出來(lái)，下面我們?cè)敿?xì)的解釋一下如何利用這些信息分析切換原因，扁鵲針對(duì)這個(gè)問(wèn)題的分析又達(dá)到了怎樣的效果。

　　從我們自身的運(yùn)維經(jīng)驗(yàn)來(lái)看，由DB故障導(dǎo)致的切換并不常見，更多的情況是由于用戶的SQL占用過(guò)多的系統(tǒng)資源引發(fā)的一些異常狀況，主要可以分為慢查詢并發(fā)和大事務(wù)兩類，下面我們逐個(gè)分析兩種行為觸發(fā)切換的原因

　　由慢查詢并發(fā)引起的主備切換

　　TDSQL默認(rèn)采用innodb存儲(chǔ)引擎，在innodb中為了避免同時(shí)在innodb中同時(shí)運(yùn)行的線程過(guò)多帶來(lái)額外的性能開銷，innodb提供了一個(gè)innodb_concurrency的參數(shù)，用于限制同時(shí)在innodb中執(zhí)行的線程數(shù)的最大值，如果客戶執(zhí)行了用大量的并發(fā)連接執(zhí)行慢查詢，這些慢查詢會(huì)不斷地占用innodb的活躍線程，導(dǎo)致用戶很多訪問(wèn)innodb相關(guān)的操作簡(jiǎn)單插入/更新等操作也容易被阻塞，等待innodb處理，同樣也會(huì)引起agent心跳檢測(cè)不斷失敗，從而觸發(fā)主備切換。

　　當(dāng)這種情況發(fā)生時(shí)，我們可以看到innodb status信息中有大量的線程處于等待隊(duì)列，并且有很多慢查詢?cè)趐rocesslist中執(zhí)行和很長(zhǎng)時(shí)間，這樣我們就可以分析事先保存的innodb status信息確認(rèn)這一現(xiàn)象，再結(jié)合processlist中找出TOP 慢SQL就可以知道是哪些慢查詢并發(fā)導(dǎo)致了這個(gè)問(wèn)題。

　　大事務(wù)引發(fā)的主備切換原因

　　TDSQL為了保證主備數(shù)據(jù)的一致性默認(rèn)采用row格式的binlog，如果用戶執(zhí)行了一個(gè)delete大表的操作就可能產(chǎn)生一個(gè)非常大的binlog寫入，由于binlog是順序?qū)懭氲模笫聞?wù)的binlog沒(méi)有完成寫盤之前，后面一些小的寫入操作如TDSQL心跳寫入也會(huì)被阻塞在寫入binlog的階段等待大事務(wù)binlog寫入完成，這個(gè)等待時(shí)間過(guò)程會(huì)導(dǎo)致心跳寫入頻繁出現(xiàn)超時(shí)。從而觸發(fā)切換的邏輯，這種情況下我們會(huì)觀察到innodb status中有大量事務(wù)已經(jīng)完成的在innodb層的prepared，等待寫入binlog，并且在processlist中有大量的心跳寫入被阻塞。

　　目前針對(duì)這種情況TDSQL已經(jīng)做了優(yōu)化，比如默認(rèn)限制binlog一次寫入的大小不超過(guò)1.5G禁止大事務(wù)的產(chǎn)生。

　　扁鵲的自動(dòng)化分析效果

　　結(jié)合上述分析流程，扁鵲會(huì)自動(dòng)化的針對(duì)監(jiān)控，切換前的DB快照等信息分析出切換的原因，并展示詳細(xì)的分析過(guò)程。

　　1).下圖展示了扁鵲分析出由于DB發(fā)生不存活引發(fā)了主備切換

　　2).這一例展示了扁鵲自動(dòng)結(jié)合切換前innodb status的活躍線程已滿和processlist慢查詢過(guò)多兩點(diǎn)判斷出是由于慢查詢并發(fā)觸發(fā)了主備切換，并且扁鵲將processlist的SQL按照SQL指紋聚合起來(lái)，方便用戶快速定位到是哪條SQL導(dǎo)致了這個(gè)問(wèn)題

　　3).這里我們看到扁鵲定位到了由于大事務(wù)引發(fā)的主備切換，并找到了引發(fā)大事務(wù)的具體SQL

　　2. 性能問(wèn)題

　　接下來(lái)我們介紹DB的性能，哪些原因會(huì)導(dǎo)致性能問(wèn)題。

　　性能問(wèn)題，從用戶側(cè)最直觀的感受就是SQL的執(zhí)行時(shí)耗過(guò)長(zhǎng)，導(dǎo)致這個(gè)問(wèn)題的常見原因有

　　網(wǎng)絡(luò)因素，如延遲，丟包等

　　SQL自身執(zhí)行較慢

　　資源飽和

　　鎖等待

　　網(wǎng)絡(luò)問(wèn)題我們暫不在此深究，這里我們主要針對(duì)后三種情況展開分析一下：

　　SQL自身執(zhí)行較慢

　　對(duì)于SQL自身執(zhí)行較慢通常是由于用戶沒(méi)有建立合適的索引，或者由于一些SQL寫法上的原因?qū)е聸](méi)有利用到已有的索引，扁鵲針對(duì)這種SQL會(huì)自動(dòng)的通過(guò)語(yǔ)法解析，SQL訪問(wèn)的表結(jié)構(gòu)，數(shù)據(jù)分布等信息進(jìn)行分析，生成合適的索引優(yōu)化建議反饋給用戶。

　　資源飽和

　　對(duì)于資源飽和引起的慢查詢，如當(dāng)前CPU/IO等資源飆升，扁鵲的會(huì)話分析功能會(huì)自動(dòng)將當(dāng)前會(huì)話按照SQL指紋進(jìn)行聚合，從而快速找到導(dǎo)致消耗資源的TOP SQL再自動(dòng)關(guān)聯(lián)SQL優(yōu)化模塊得出優(yōu)化建議，這樣不論是普通用戶還是DBA都可以快速定位到資源消耗的罪魁禍?zhǔn)淄瑫r(shí)對(duì)優(yōu)化的方案一目了然。

　　鎖等待

　　引起SQL請(qǐng)求時(shí)耗高的另一大常見因素是鎖等待問(wèn)題比如事務(wù)1中一個(gè)會(huì)話更新了一行，但是事務(wù)還沒(méi)有提交，這時(shí)另一個(gè)事務(wù)2的某個(gè)SQL去更新同一行就需要等待事務(wù)1提交完成才能執(zhí)行，這其中等待的時(shí)耗也會(huì)導(dǎo)致整個(gè)請(qǐng)求的時(shí)耗增加。這種情況下用戶的可能會(huì)發(fā)現(xiàn)部分簡(jiǎn)單的操作例如主鍵更新正常情況下都是0ms的，偶爾突然變成了數(shù)十秒，當(dāng)客戶反饋給我們后，發(fā)現(xiàn)SQL執(zhí)行時(shí)耗可能又正常了，下面我們看一下扁鵲如何輔助客戶/DBA分析這類問(wèn)題。

　　在下圖的例子中我們可以看到session1 update t1某一行后一直沒(méi)有提交，該行鎖始終不釋放，導(dǎo)致session2 update同一行的操作出現(xiàn)鎖超時(shí)現(xiàn)象。

　　對(duì)于這種情況只要客戶的session1不提交事務(wù)并且不與DB斷開連接，這個(gè)會(huì)話持有的鎖就會(huì)一直保持。MySQLinformation_schema下有三張表記錄了事務(wù)之間的鎖等待依賴關(guān)系，如下圖中session4不被其他會(huì)話阻塞，但session4持有的鎖阻塞了session1，2，3，這里我們稱session4為持有鎖的領(lǐng)頭會(huì)話。這種情況由于鎖等待現(xiàn)場(chǎng)環(huán)境還在，扁鵲就通過(guò)分析這三張表的信息可以找到持有鎖的領(lǐng)頭會(huì)話并建議用戶kill session4來(lái)解除鎖等待。

　　下圖是扁鵲診斷這種鎖等待的效果圖

　　除了事務(wù)未提交以外，用戶的業(yè)務(wù)邏輯也有可能在執(zhí)行完事務(wù)中所有SQL后沒(méi)有立即提交事務(wù)，導(dǎo)致事務(wù)持有鎖時(shí)間較長(zhǎng)。在下圖中可以看到session1執(zhí)行完update t1后隔了50s才提交事務(wù)，導(dǎo)致session2的update同一行操作的時(shí)耗也在50s以上甚至出現(xiàn)鎖超時(shí)錯(cuò)誤，如果用戶在15點(diǎn)反饋12點(diǎn)某個(gè)時(shí)刻出現(xiàn)了這樣的問(wèn)題，我們?cè)偃ゲ榭磇nformation_schema下的鎖信息內(nèi)容會(huì)發(fā)現(xiàn)已經(jīng)沒(méi)有這樣的鎖等待關(guān)系了，針對(duì)這種情況，我們只能通過(guò)用戶執(zhí)行過(guò)的SQL日志，來(lái)找出session1這個(gè)歷史會(huì)話信息，那么我們面臨的問(wèn)題是

　　從哪里提取SQL日志？

　　如何通過(guò)用戶提供的慢查詢高效的找出session1這個(gè)歷史會(huì)話信息？

　　從哪里提取SQL日志？

　　TDSQL的在用戶和DB的連接之間有一個(gè)proxy層，所有的用戶SQL執(zhí)行都會(huì)先經(jīng)過(guò)proxy，在proxy中實(shí)現(xiàn)了高效的日志模塊，可以將用戶執(zhí)行過(guò)的SQL，執(zhí)行時(shí)耗，客戶端地址等信息脫敏后全量的保存下來(lái)，并且對(duì)性能沒(méi)有任何影響。

　　如何通過(guò)用戶提供的慢查詢高效的找出session1這個(gè)歷史會(huì)話信息？

　　雖然有了用戶全量的歷史SQL信息，但是我們?nèi)匀浑y以直接從日志中找到session1在某一時(shí)刻阻塞session2這種時(shí)間序列“交錯(cuò)”的會(huì)話信息，或者說(shuō)是session1事務(wù)開始結(jié)束時(shí)間覆蓋了某個(gè)時(shí)間點(diǎn)的事務(wù)信息。

　　這里扁鵲實(shí)現(xiàn)了一個(gè)事務(wù)模擬器，可以通過(guò)按客戶端執(zhí)行記錄的IP:PORT分組并結(jié)合語(yǔ)法解析回放用戶執(zhí)行過(guò)的SQL來(lái)提取所有事務(wù)信息，如事務(wù)的開始，結(jié)束時(shí)間，事務(wù)中訪問(wèn)了哪些表，事務(wù)的影響行數(shù)，事務(wù)的總時(shí)耗等等，這樣我們就可以通過(guò)設(shè)定過(guò)濾條件以事務(wù)為單位來(lái)找出某個(gè)事務(wù)具體的執(zhí)行信息。

　　扁鵲診斷案例

　　接下來(lái)我們來(lái)看一個(gè)案例，用戶反饋在22:00:37這個(gè)時(shí)刻update T01_NOR_CUST_INFO這張表出現(xiàn)了鎖超時(shí)。

　　扁鵲通過(guò)設(shè)定22:00:37，T01_NOR_CUST_INFO這兩個(gè)條件就可以自動(dòng)找出事務(wù)執(zhí)行時(shí)間包含22:00:37并且對(duì)T01_NOR_CUST_INFO有過(guò)update/delete/insert/selectfor update等可能產(chǎn)生行鎖的事務(wù)，并自動(dòng)的提示用戶這個(gè)事務(wù)時(shí)耗過(guò)長(zhǎng)，持有的鎖時(shí)間過(guò)長(zhǎng)可能影響其他會(huì)話這一異常信息。有了這個(gè)功能，我們就可以根據(jù)用戶提供的慢查詢出現(xiàn)的時(shí)間點(diǎn)和SQL快速的找出影響的會(huì)話具體信息，用戶就可以根據(jù)扁鵲提供的事務(wù)信息和時(shí)間來(lái)排查業(yè)務(wù)邏輯修復(fù)問(wèn)題了。

　　3. 可靠性問(wèn)題

　　DB的可靠性問(wèn)題主要表現(xiàn)為業(yè)務(wù)目前可能并未感覺(jué)數(shù)據(jù)庫(kù)訪問(wèn)存在異常，但是想為DB做一次體檢來(lái)確定DB是否有潛在的風(fēng)險(xiǎn)或隱患導(dǎo)致未來(lái)某一時(shí)刻DB出現(xiàn)異常的問(wèn)題存在。

　　對(duì)于DB潛在風(fēng)險(xiǎn)的排查，我們針對(duì)性能監(jiān)控，表結(jié)構(gòu)，歷史會(huì)話，慢查詢等信息結(jié)合騰訊云海量數(shù)據(jù)+機(jī)器學(xué)習(xí)的能力系統(tǒng)的評(píng)估DB的健康狀態(tài)，檢測(cè)可能的異常并告知客戶，盡可能將大部分異常在發(fā)生之前就發(fā)出預(yù)警，將風(fēng)險(xiǎn)降到最低。

　　四、總結(jié)

　　以上我們介紹了由TDSQL運(yùn)營(yíng)痛點(diǎn)催生扁鵲的需求背景，以及扁鵲的層次結(jié)構(gòu)，組成元素，還有主備切換，鎖等待分析等關(guān)鍵技術(shù)的診斷原理，實(shí)踐經(jīng)驗(yàn)。擁有扁鵲后在公有云性能類咨詢工單已經(jīng)基本降為0，可以看出扁鵲目前的功能已經(jīng)可以很好的服務(wù)于我們的客戶也提升了我們DBA同學(xué)的生活品質(zhì)，未來(lái)我們也會(huì)繼續(xù)完善扁鵲的診斷、預(yù)測(cè)能力，整合我們DBA多年的運(yùn)營(yíng)經(jīng)驗(yàn)和AI、機(jī)器學(xué)習(xí)等技術(shù)，覆蓋更多的異常場(chǎng)景，爭(zhēng)取做到將所有異常在發(fā)生前就預(yù)測(cè)到，為客戶提供更安心的運(yùn)營(yíng)環(huán)境。

　　關(guān)注“騰訊云數(shù)據(jù)庫(kù)”官方微信，回復(fù)“智能運(yùn)維”，即可下載本文PPT。

　　往期推薦

　　《數(shù)據(jù)庫(kù)大牛李海翔詳解全局讀一致性技術(shù)》

　　《大咖丁奇：索引存儲(chǔ)順序和order by不一致？》

　　免費(fèi)試用

　　包括云數(shù)據(jù)庫(kù)MySQL在內(nèi)的40+款熱門云產(chǎn)品，實(shí)名認(rèn)證的企業(yè)用戶可免費(fèi)試用！1000M內(nèi)存50G數(shù)據(jù)盤的MySQL可免費(fèi)體驗(yàn)30天，點(diǎn)擊左下角“閱讀原文”立即領(lǐng)取~

　　↓↓點(diǎn)“閱讀原文”免費(fèi)試用