騰訊數據庫專家雷海林分享智能運維架構

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

雷海林在大會現場

扁鵲系統是TDSQL面向云市場推出的一款針對數據庫性能/故障等問題的自動化分析并為用戶提供優化/解決方案的產品。

1. 扁鵲的需求背景

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

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

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

2. 扁鵲的作用

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

扁鵲大體可以分為下圖中的六個層次結構

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

2. 采集層會從資源層采集一些性能指標，SQL日志，表結構等必要的診斷信息并輸送到存儲層

3. 存儲層負責將采集層提供的信息持久化，以供后續對歷史數據進行分析

4. 索引層會從存儲層提取數據再次進行分類并形成可編程的數據結構，也是分析層所需要的診斷單元

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

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

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

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

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

1. 可用性問題

可用性問題主要是指DB在一段時間內無法響應用戶的請求

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

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

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

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

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

由慢查詢并發引起的主備切換

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

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

大事務引發的主備切換原因

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

目前針對這種情況TDSQL已經做了優化，比如默認限制binlog一次寫入的大小不超過1.5G禁止大事務的產生。

扁鵲的自動化分析效果

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

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

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

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

2. 性能問題

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

性能問題，從用戶側最直觀的感受就是SQL的執行時耗過長，導致這個問題的常見原因有

1. 網絡因素，如延遲，丟包等

2. SQL自身執行較慢

3. 資源飽和

4.  鎖等待

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

SQL自身執行較慢

對于SQL自身執行較慢通常是由于用戶沒有建立合適的索引，或者由于一些SQL寫法上的原因導致沒有利用到已有的索引，扁鵲針對這種SQL會自動的通過語法解析，SQL訪問的表結構，數據分布等信息進行分析，生成合適的索引優化建議反饋給用戶。

資源飽和

對于資源飽和引起的慢查詢，如當前CPU/IO等資源飆升，扁鵲的會話分析功能會自動將當前會話按照SQL指紋進行聚合，從而快速找到導致消耗資源的TOP SQL再自動關聯SQL優化模塊得出優化建議，這樣不論是普通用戶還是DBA都可以快速定位到資源消耗的罪魁禍首同時對優化的方案一目了然。

鎖等待

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

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

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

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

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

1. 從哪里提取SQL日志？

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

從哪里提取SQL日志？

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

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

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

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

扁鵲診斷案例

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

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

3. 可靠性問題

DB的可靠性問題主要表現為業務目前可能并未感覺數據庫訪問存在異常，但是想為DB做一次體檢來確定DB是否有潛在的風險或隱患導致未來某一時刻DB出現異常的問題存在。

對于DB潛在風險的排查，我們針對性能監控，表結構，歷史會話，慢查詢等信息結合騰訊云海量數據+機器學習的能力系統的評估DB的健康狀態，檢測可能的異常并告知客戶，盡可能將大部分異常在發生之前就發出預警，將風險降到最低。

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