軟件架構自學筆記-- 轉載「騰訊數據庫專家雷海林分享智能運維架構」

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

雷海林在大會現場

1、扁鵲的基本介紹

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

1. 扁鵲的需求背景

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

針對這些問題，咱們認爲須要一個自動化的故障 / 性能問題分析系統，減小 DBA 的重複勞動，沉澱咱們的分析經驗，快速定位問題，帶給咱們的客戶最快速的響應同時也提高 DBA 的幸福指數。

之因此將這個模塊命名爲扁鵲，就是但願它能像古代的扁鵲神醫爲人診斷病因同樣也能夠爲數據庫「對症下藥「，治療 / 修復 / 預判數據庫已知或潛在的風險。

2. 扁鵲的做用

在開發扁鵲系統的時候，隨着 DBA 的專家知識庫不斷向扁鵲輸入，目前咱們大部分現網的性能 / 故障問題基本均可以經過咱們扁鵲一鍵分析緣由，大大解放了 DBA 的雙手，極大提升了運營效率。下圖是咱們對扁鵲在設計階段所設定的基本功能和目標，核心點就是但願扁鵲能作到風險事前預警，事中準確分析緣由並解決問題，過後能對歷史事件進行分析，發現問題點。

2、系統架構

扁鵲大致能夠分爲下圖中的六個層次結構

1. 資源層主要包括 DB 實例和宿主機提供各類原始的信息
2. 採集層會從資源層採集一些性能指標，SQL 日誌，表結構等必要的診斷信息並輸送到存儲層
3. 存儲層負責將採集層提供的信息持久化，以供後續對歷史數據進行分析
4. 索引層會從存儲層提取數據再次進行分類並造成可編程的數據結構，也是分析層所須要的診斷單元
5. 分析層是扁鵲的核心邏輯，主要負責利用索引層的元數據信息結合 TDSQL 自身沉澱的知識庫對數據庫常見異常如主備切換，主備延遲，等問題進行根音分析，風險評估
6. 展現層最終會將分析層的結果可視化，大致可分爲健康報表和具體的故障 / 性能 / 優化建議

下圖展現了扁鵲更細化的結構，能夠看到扁鵲具有了哪些功能，這些功能須要哪些元數據，元數據又從哪些層面獲取，各模塊之間如何交互等，若是你們要作相似的功能能夠基於這個作一個很好的參考。

3、智能診斷原理與實踐

咱們將客戶常常諮詢的 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 的健康狀態，檢測可能的異常並告知客戶，儘量將大部分異常在發生以前就發出預警，將風險降到最低。

4、總結

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

本文轉載自騰訊雲數據庫

原文連接：

https://cloud.tencent.com/developer/article/1429232