隨著企業數字化轉型進入深水區，資料庫系統越來越複雜，運維團隊維護的資料庫規模越來越大，傳統工具化的運維已無法滿足當前運維的要求，資料庫運維逐漸向智慧化發展。
如何更好地感知和預測資料庫故障，進而進行智慧診斷、自適應恢復，是我們一直探索的內容。接下來本篇將分享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當前支援毛刺、持續增長、漂移、週期性等場景的檢測演算法，可以幫助運維人員迅速定位問題，減輕運維人員的工作量，助其鎖定問題的根因。
- 趨勢預測
在日常系統運維及故障處置實踐中，負載的變化往往也蘊含著當前系統的亞健康及故障的影響反饋，基於傳統的元件指標監控和告警，在故障異常發現的及時性上具有挑戰。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拖慢整個資料庫。
今天我分享的內容主要到這裡，謝謝大家！