騰訊資料庫專家雷海林分享智慧運維架構

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、機器學習等技術，覆蓋更多的異常場景，爭取做到將所有異常在發生前就預測到，為客戶提供更安心的運營環境。