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

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

雷海林在大會現(xiàn)場

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

1. 扁鵲的需求背景

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

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

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

2. 扁鵲的作用

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

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

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

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

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

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

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

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

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

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

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

1. 可用性問題

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

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

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

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

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

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

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

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

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

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

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

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

扁鵲的自動化分析效果

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

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

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

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

2. 性能問題

接下來我們介紹DB的性能，哪些原因會導(dǎo)致性能問題。

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

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

2. SQL自身執(zhí)行較慢

3. 資源飽和

4.  鎖等待

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

SQL自身執(zhí)行較慢

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

資源飽和

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

鎖等待

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

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

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

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

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

1. 從哪里提取SQL日志？

2. 如何通過用戶提供的慢查詢高效的找出session1這個歷史會話信息？

從哪里提取SQL日志？

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

如何通過用戶提供的慢查詢高效的找出session1這個歷史會話信息？

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

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

扁鵲診斷案例

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

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

3. 可靠性問題

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

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

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