在第14屆中國資料庫技術大會（DTCC2023）上，華為雲資料庫運維研發總監李東詳細解讀了GaussDB運維繫統自動駕駛探索和實踐。 ...

本文分享自華為雲社區《DTCC 2023專家解讀 | GaussDB技術解讀系列之運維自動駕駛探索》，作者：GaussDB 資料庫。

近日，在第14屆中國資料庫技術大會（DTCC2023）的GaussDB“五高兩易”核心技術，給世界一個更優選擇專場，華為雲資料庫運維研發總監李東詳細解讀了GaussDB運維繫統自動駕駛探索和實踐。

以下為演講實錄：

大家好，我是來自華為雲GaussDB資料庫的李東。隨著企業數字化轉型進入深水區，資料庫系統越來越複雜，運維團隊維護的資料庫規模越來越大，傳統工具化的運維已無法滿足當前運維的要求，資料庫運維逐漸向智能化發展。

如何更好地感知和預測資料庫故障，進而進行智能診斷、自適應恢復，是我們一直探索的內容。接下來我將分享GaussDB在運維自動化駕駛上的探索和實踐，分別從雲資料庫運維挑戰，GaussDB運維體系架構，以及我們如何進行快速感知和快速診斷4個方向進行分享。

一、雲資料庫運維面臨哪些挑戰？

隨著企業將資料庫搬遷上雲，雲上資料庫運維面臨的挑戰更加複雜。資料庫可能會部署在裸金屬、虛擬機、容器等多樣化的基礎設施上，而不同的基礎設施面對的故障場景也是多樣化的。

如果我們遇到一個性能抖動的亞健康問題，通常解決思路是從應用資料庫、操作系統、計算、存儲、網路等多層次全面分析，每一層都可能發生故障，不同層次發生故障可能引發相同的亞健康現象。比如說一個慢SQL，可能是磁碟故障導致的，也有可能是網路抖動引起的，但是表現上對於客戶而言都是一個慢SQL。

如果運維能力不足，我們很難在短時間內去定位和解決亞健康問題，因為它在處理過程中一般有三個挑戰：

第一，無法準確預測和監控亞健康問題。這裡主要涉及到多和少的問題，“少”就是在每一層上缺少對亞健康問題的監控，比如說磁碟故障了，可以很容易感知到；如果磁碟出現了壞塊或者慢盤的情況，我們就沒有辦法快速監控。“多”體現在我們在每一層都做了監控和告警，但告警之間是沒有關聯性的，很難從這些告警中識別真正發生問題的點在哪裡，所以很難精確發現當前的亞健康問題。

第二，發現亞健康問題之後沒有辦法進行快速診斷。對於資料庫內部發生的問題，往往依賴DBA經驗進行診斷和決策，對運維的能力要求比較高，效率也無法保證。

第三，恢復能力不足。我們當前診斷到發生問題的根源之後需要去恢復，但恢復能力不足，比如限流、扛過載的有效能力不足，涉及資料庫參數調優、爛SQL優化等需要很深的資料庫能力和經驗的積累。

二、GaussDB整體運維架構

GaussDB是如何處理這些問題的？下麵我們看一下GaussDB整體運維的架構。

GaussDB統一運維平臺分為5個部分：

第一部分是實例運維，主要負責GaussDB集群生命周期的管理，比如創建、變更以及進行備份恢復和參數調整。

第二部分是容災管理，主要提供流式容災、同城容災、兩地三中心能力。

第三部分是智能運維，是GaussDB運維體系中最關鍵的部分，通過AI4DB的能力打造自治運維繫統，它分為四層：

第一層是數據採集層，負責採集各層的監控數據以及上層下發的操作指令。

第二層是數據計算層，負責將採集到的數據進行緩存、持久化以及數據加工，包括時序資料庫、演算法模型庫、故障規則庫等。

第三層是自治服務層，包括SQL診斷調優、安全、資料庫運維等能力。

第四層是全景監控，包括告警監控、全量SQL等能力。

GaussDB通過構建一體化的智能運維中心，打造了全鏈路、端到端的自動駕駛體驗。

三、GaussDB故障快速感知

資料庫全景監控大盤，實時感知系統運行狀態

下麵我們看一下GaussDB全景監控大盤，通過全景監控可以看出我們所維護的資料庫集群哪些是正常的，哪些是異常的，哪些是存在亞健康情況的。比如查看告警統計模塊，通過分析可以看出整個集群當前的告警情況，如果有緊急告警和重要告警，可以優先處理。也可以看到資源使用的風險，通過資源使用預測能力預警即將會發生哪些資源瓶頸，比如說磁碟空間不足、 CPU不足，方便我們及時處理和恢復。智能診斷這塊，通過技術分析當前資料庫有哪些性能瓶頸，同時也支持自定義監控大盤，選取用戶重點業務資料庫，自定義重點監控指標，對重點業務進行自定義維度的保障監控。

全景大盤首先要依賴全鏈路、全方位的監控。資料庫的可觀測能力對於資料庫的運維十分重要，GaussDB全鏈路監控具備從硬體、OS、DB等分層監控，構建從採集、發送、展示、分析到巡檢等全鏈路能力，並且打通了硬體到操作系統，到資料庫整個監控鏈的通道。比如說硬體出現故障問題，如果在雲上，硬體故障屬於不同部門維護，資料庫部門只能看到資料庫集群，如何感知到硬體發生亞健康或者操作系統存在問題，這個時候就得聯合硬體部門，打通硬體到操作系統、資料庫的通知機制，如果在這層發生了亞健康問題，可以把故障信息向上通知相關的運維部門解決。

全量SQL數據採集分析

接下來看一下全量SQL採集的能力。相較於傳統全量SQL採集方式，即通過流量抓取或者日誌方式獲取全量SQL，GaussDB通過輕量化的方式構建了全量SQL的洞察。採集進程與資料庫建立記憶體緩衝區通道，直接從記憶體通道里把SQL信息進行採集並轉存到外部設備中，這個過程不需要發生任何磁碟IO操作，對性能影響極低。

傳統的採集場景我們可能需要開啟全量SQL，對業務的影響在30%左右，一般情況下，用戶是不敢開啟的，而GaussDB的全量SQL，可以把風險降到最低。GaussDB提供的全量SQL方案具備以下4個特點：

低風險。GaussDB通過記憶體方式把日誌信息全部讀取完再轉存到第三方，對資料庫性能損耗不超過5%。
低成本。GaussDB不將全量SQL數據轉存到本地IO，而是直接轉存到第三方，比如說雲上的OBS，並支持全量SQL的壓縮，成本比較低。
高擴展。GaussDB全量SQL會預設採集部分信息，如果這些信息不滿足當前的訴求，可以進行擴展。
高安全。當需要將全量SQL轉存到第三方設備上時，GaussDB在轉存過程中進行了預設的數據脫敏，確保數據安全的。

通過全鏈路監控，GaussDB支持快速自動巡檢。通過對可用性、可靠性、性能、資源使用趨勢進行巡檢，並輸出巡檢報告，可以查看當前存在的問題，並且給出一些相應建議。因此，通過上述全鏈路以及自動巡檢的能力，GaussDB可以做到快速感知。

四、GaussDB智能診斷

下麵我們看一下GaussDB在故障診斷方面有哪些能力？

SQL自診斷

我們基於離線+線上的方式進行SQL診斷，首先收集可能存在慢SQL的場景，包括SQL文本、SQL執行時間以及掃描行數、返回行數，並收集跟資料庫、操作系統或者是資源相關的關鍵指標，通過業務SQL信息和關鍵指標的信息，進行一個離線的訓練，最終得到一個慢SQL特征庫。

這個特征庫有什麼用呢？當我們在生產環境中遇到慢SQL問題，可以基於特征庫和KNN演算法進行線上推理，就診斷出SQL產生的原因，然後針對根因給出一些優化建議。

SQL全鏈路分析

之前有客戶反饋，平時我們的SQL執行非常快，能在一秒內返回，但是最近經常為什麼偶現執行超時了呢。我們業務人員通過查看每一層狀況，從從客戶端、資料庫CN、DN、操作系統等串列分析，發現這個偶現的問題可能是發生在某個分片上，這樣的診斷效率非常低。

GaussDB提供的SQL全鏈路監控分析能力則很好地解決了這個問題。它包括全鏈路追蹤和聚合分析兩方面，通過業務SQL關鍵字或客戶端traceID等條件查詢到資料庫SQLID，並追蹤該SQL在資料庫集群中的解析過程和執行耗時，以及每條SQL在集群中的轉發、聚合情況，進而追蹤到問題發生的源頭。

多維指標關聯分析

資料庫運維過程中需要對大量指標進行監控，當其中某個或多個關鍵指標發生異常時，運維人員需要快速準確的定位到異常根因，以便決定下一步的操作。但是當指標數量很多的時候，篩選信息的工作量也會很龐大，因此我們需要一個高效的工具去解決這個問題。我們知道某些資料庫指標之間是存在強關聯性，通過有方向性的關聯性演算法，在異常發生時將同一時間段的指標進行比對，根據相關性的強弱將異常時間段內與關鍵指標相關的指標篩選出來，當前支持毛刺、持續增長、漂移、周期性等場景的檢測演算法，可以幫助運維人員迅速定位問題以及減輕運維人員的工作量，有助於我們鎖定問題的根因。

趨勢預測

在日常系統運維及故障處置實踐中，負載的變化往往也蘊含著當前系統的亞健康及故障的影響反饋，基於傳統的組件指標監控和告警在故障異常發現的及時性上具有挑戰。GaussDB通過建立對實例級關鍵指標的監控，基於歷史數據和時序預測、異常檢測等關鍵演算法，對黃金KPI進行指標預測，發現異常信息，進而提醒用戶採取措施，避免異常情況造成嚴重後果。

索引推薦

應用開發者在對SQL進行優化的過程中，索引優化是關鍵的優化內容，由於對性能分析、優化手段多方面複雜分析及實踐門檻，對SQL優化帶來了挑戰。

索引推薦的核心方法是基於原生的詞法和語法解析，對查詢語句中的字句和謂詞進行分析和處理，再結合欄位選擇度、聚合條件、多表join關係等輸出最優的索引建議。GaussDB 提供索引推薦功能，給出索引推薦列表，以及每一個索引的正向和負向SQL的收益，識別當前資料庫存在的冗餘索引、無用索引，優化資料庫查詢速度。GaussDB還提供了優化器評估能力，優化器評估能力提供了一個虛擬索引的能力，不需要真實創建索引，通過虛擬索引評估索引推薦的結果是不是合適。通過持續對索引配置進行優化，可以解決用戶的負載漂移情況，及時發現索引不優、冗餘索引，以便避免故障發生。

SQL會話查殺

應用開發的複雜邏輯可能導致人工難以發現的邏輯問題，出現異常SQL，需要有對應手段幫助運維人員快速對異常會話進行查殺限制。GaussDB應用平臺提供了一個會話管理的能力，實時會話頁面支持會話統計、活躍會話、會話鎖分析、會話查殺等功能，幫助運維和管理人員快速掌握實例的會話信息，管理實例會話，並高效定位資料庫會話連接相關人工難以發現的邏輯問題。

SQL限流和自治限流

我們可以想象一個場景，在資料庫正常運行過程中，某一個應用上線了一個新功能，這個新功能引入了一個超級爛SQL，導致資料庫逐漸的從正常對外服務狀態轉為資源使用逐漸升高，大量的SQL因為獲取不到線程、CPU等資源而執行的速度變慢，最終導致業務異常。在遇到異常SQL(如不優索引)、SQL併發上升等場景下，對整個資料庫的可服務性影響比較大，這時我們就可以通過對SQL精準化限流的方式進行抑制，保證業務能夠正常運行。

GaussDB提供的SQL限流提供了以下能力：

全局快慢車道。所謂全局快慢車道，就是定義兩個資源池，一個是正常資源池，我們稱為快車道，快車道提供大量的資源，正常業務在快車道運行，如果出現交通事故，這裡的交通事故就是指異常的SQL業務。當出現交通事故時，我們可以通過頁面一鍵將異常SQL放到慢車道中，慢車道限制了對資源的使用，這樣交通事故處理完了，快車道可以繼續保持高速運行。

單類SQL精準管控。對單類SQL，從執行時間、IO使用等角度進行精準管控，管控這類SQL的資源占用。起到緊急限流的作用。

記憶體熔斷。提供記憶體上下限配置，記憶體使用超過最大記憶體上限後禁止新連接接入並kill當前會話，待記憶體恢復到記憶體下限後停止kill會話並允許新連接接入。

SQL自治限流。提供按照一定的SQL規則，或者CPU、記憶體等資源使用規則，來進行SQL的自治限流能力，避免對應類別的SQL拖慢整個資料庫。

我們GaussDB運維中心還有很多其他的能力，會在10月份進行全新發佈，屆時大家可以體驗，一起給我們提意見。

今天我分享的內容主要到這裡，謝謝大家！