8月24日阿里雲資料庫技術峰會上，阿里雲高階DBA專家玄慚帶來面對超大規模的資料庫叢集，尤其是在每年像雙11這樣重大促銷活動中，阿里雲是如何進行運維和優化的。本文主要介紹了天象和CloudDBA兩個產品，包括他們的起源、基於系統畫像倉庫的應用、產品化等，最後對RDS產品的可診斷性建設和可運維性建設作了補充。

   隨著雲資料庫時代的到來，它的運維體系不僅僅包括保持資料庫叢集的穩定，同時我們還要關注使用者體驗。在業務上，體量大，使用者各類，例如有公有云小客戶，也有企業大客戶，每類客戶的需求都各式不一，眾口難調。在系統上，為了實現故障切換和資源對使用者透明，系統設計中包括了眾多元件，例如RDS的資料訪問鏈路從DNS-SLB-Proxy-DB節點，也有管理控制鏈路從前端控制檯-OPEN API-後端元件-DB節點，這樣給問題的排查帶來了巨大的困難，出現了一個問題你不知道是出現在那個環節。在服務上，每個使用者都要求一樣高的SLA，服務的不好可能就會引發公關危機。所以在雲資料庫時代我們面臨著下面三個挑戰：
 

一. 例項數呈指數級別增長，後端運維壓力急劇上升。

二. 使用者端不在我們的管理範圍內，無法配合排查，巨大的成本。

三. 除了RDS自身穩定，還需要確保使用者資料庫本身的穩定。

   面對這樣的挑戰該如何突破，冰凍三尺非一日之寒，RDS在過去5年的發展歷程中，在系統的可運維以及可診斷中我們是怎樣做的？

天象

一. 自證清白的救贖

起源

   在2012年RDS剛剛成立之初，我們當時面臨這一個非常嚴重的使用者問題：閃斷。當時很多遊戲使用者反饋遊戲突然掉線了，應用的報錯日誌中顯示應用和資料庫的連線斷開或者超時。面對這樣的問題，很多時候是DB節點發生了主備切換，OOM或者crash，這樣的情形是比較好排查的，但是對於DB上層的鏈路，比如proxy出現了抖動，上層SLB做了網路變更，甚至再上層的網路交換機出現了down機或者丟包，這個時候的網路閃斷問題就非常難以排查了。出現這樣的一個問題對於排查者來說是一個夢魘，因為他要去找很多的人去排查各個元件的負責人排查一下有沒有問題，結果問了一圈都說沒有問題，耗費大量的時間，客戶也在哪裡焦急的等待著回覆。問題的根源每個元件的監控沒有辦法全鏈路統一起來。面對這樣的問題，如何能夠快速，簡單的去發現問題出現在哪個環節？
 

   我們需要了解使用者的服務質量，我們要做鏈路的視覺化，全量秒級的可視化出鏈路各環節的延遲、丟包等資料。有了這樣的目標，接著我們就開始將客戶端到SLB，proxy，再到DB節點，所有的請求通過TCPRT全鏈路資料採集儲存下來。TCPRT全鏈路系統對使用者所有節點上的網路包進行實時分析並繪製出網路拓撲, 可以追溯到每段鏈路上每條使用者連結任意每秒的延遲、丟包率、流量、異常等指標。通過視覺化使用者的真實鏈路拓撲, 我們可以在排查問題時, 很容易追溯發生問題的源頭以及問題原因。整個系統目前每秒記錄上百萬條連線快照, 每天處理近百TB資料，遠超傳統監控系統的問題域，幫助我們視覺化。上圖中兩臺伺服器的鏈路出現紅色，最後反饋給使用者進行排查，最終定位這兩臺伺服器壓力很大，原始情況下我們不知道問題出現在哪個節點，有了很直觀的拓撲簇後，我們就可以快速定位問題。
 

   有了TCPRT的全鏈路資料之後，使用者向雲廠商提出問題，這時候我們要做自證清白，我們把使用者例項所涉及到的元件，比如前端的proxy到後端的主機再到MySQL例項等等所有關鍵的核心鏈路指標，我們都會去做一次體檢，這時候我們就可以快速去診斷問題到底出在DB節點還是主機上，有了這樣的平臺後，我們就可以快速地把我們運維能力規模化提升。

   圖為某使用者鏈路RT反饋前端較慢，從監控資料可以看到RT增加了，再看後端DB監控對應的時間點，發現數據庫CPU上去了，我們再去查後端使用者的監控資料進行對比排查，這樣就很方便的得出問題的節點在DB這一層，進而在深入排查使用者資料庫的資源，慢SQL以及其他內部診斷資料。有時候使用者可能會說我的應用訪問資料庫慢了，他最直觀的感覺是資料庫出問題了，實際也有可能是應用到資料庫中間鏈路出現了問題，這時，我們就可以通過鏈路資料最直觀的看資料庫端到使用者中間的RT是多少，這有利於瞭解使用者的服務質量。

二. 規模化運維能力提升

   隨著叢集規模的變大，機器數量越來越多，傳統靠人的運維的模式已經不在持續，以前是被動接受使用者投訴，現在變為主動發現問題，比如後端主機出現抖動(磁碟，記憶體，網絡卡故障)，這時我們會快速的發現主機抖動原因，最終嘗試自動解決問題，發現Top問題，並指導解決。

   目前已經可以做自動化閉環牽引，當發現主機如果硬體出現問題，它的服務質量就會出現波動，我們就要自動化下線掉。如果我們發現某臺主機有個例項出現爭搶，我們把這個例項進行隔離，我們由被動變成閉環自動遷移處理，這是我們運維能力的提升。

   另外比如在雙11大促活動的時候，我們為叢集預備了2-3倍容量資源供使用者彈性升級使用。為了使新上線的機器得到資源最大化利用，以保障系統的穩定，需要將老機器上的例項離散到新機器上。同時雙11活動完後我們需要把這一批擴容的主機下線，將其補充到其他業務叢集進行售賣，以實現資源利用率最大化。針對上面的兩個應用場景，RDS啟動了移山專案。移山離散策略著力於對主機以及例項最近的效能資料進行計算，得出需要遷移離散的例項列表。移山收容策略則對叢集和主機的效能資料進行計算，進而得出需要收容的主機例項列表。

基於系統畫像倉庫的應用

三. 智慧化推薦和故障預判
在雙11大促銷之前，彈性升級是商家在備戰過程比不可少的一個環節，但是每年還是有很多使用者不知道是否需要對資料庫進行彈性升級，或者升級到多少規格。常常看到雙11當天還有較多商家進行臨時升級，這個時候其實已經比較危險了，這個時候系統壓力往往非常大，對彈性升級的任務是有較大影響的。所以在雙11備戰前期，我們的系統能不能夠針對使用者的系統壓力分析，提前通知使用者進行升級，這樣對雙11的平穩渡過有著重要的意義。所以在每年雙11期間，系統通過分析例項資源使用情況，通過一套智慧演算法預測使用者未來使用者的資源使用趨勢，然後自動推動客戶升級。

   RDS在設計初期為了實現故障切換和後端節點對使用者透明，系統設計中包括了眾多元件，例如RDS的資料訪問鏈路包括了DNS-SLB-Proxy-DB。面對如此複雜的資料訪問鏈路，如何快速的幫助故障處理人員去發現問題？故障指揮官系統應運而生，該系統會基於天象資料，收集全鏈路資料，從例項到主機到機架到機房的物理部署鏈路，從例項到proxy到SLB的資料訪問鏈路，幫助我們快速去發現故障問題點，逐點排查，這樣幫助決策者大大降低故障的排查時間，減少故障的影響。

故障指揮官

CloudDBA
一．CloudDBA起源

   雲資料庫服務不僅要保障底層系統的穩定，同時也要保證使用者資料庫執行穩定，使用者這一層往往最困難的。使用者的技術參差不齊，你無法去幹涉使用者怎麼去使用資料庫，或者說他們沒有很好的規範去使用資料庫，面對這種情況，我們該如何處理呢？在前面5年的客戶保障中，我們積累了大量客戶問題經驗，但是人的精力是有限的，例項規模是在不斷膨脹的，光靠人堆已經行不通了，所以我們決定將診斷經驗產品化，將經驗沉澱到產品中去，於是就有了CloudDBA這個產品。

   使用者使用資料庫的問題各式各樣，首先我們來分析一下使用者在使用資料庫過程中的分類，第一類運維操作，使用者在購買完成一個數據庫例項後，緊接著馬上會做賬號和DB的建立，或者新增只讀節點，新增白名單，修改網路配置和訪問模式等；第二類業務變更操作，比如建立表結構，儲存過程和函式等物件操作，然後在將資料匯入到資料庫中去；第三類屬於日常的巡檢，優化以及故障排查，隨著業務發展和資料量不斷的變化，我們要實時關注資料庫的健康執行，還有諸如IO、CPU、Disk 100%資源類的問題診斷，資料庫出現鎖等待和慢SQL後的業務優化等，類似這樣的問題都是可以通過CloudDB進行解決，所以CloudDBA首先做巡檢。

二．健康體檢
通過巡檢可以直觀看到資料庫例項是否有問題，將資料庫的核心指標比如活躍連線數、CPU、IO、Disk、可用性納入到評分模型中去，給資料庫的健康狀況進行打分。通過巡檢-優化-巡檢這樣不斷去迭代優化，將資料庫中存在的風險點一個個進行修復，提升系統整體的穩定性。

   在每年的雙11保障過程中發現雙11當天往往最容易出現問題是使用者自身的應用程式問題導致系統卡慢。雙11前沒有暴露出的問題，會由於雙11當天巨量的訂單和高頻的系統呼叫將這些潛在問題放大。提前找出並解決問題是保障雙11穩定執行的最佳手段。因此雙11活動之前，我們就對所有相關資料庫進行了全面的體檢，將資料庫中的潛在風險提前識別出來，並通知使用者進行優化和升級。所以我們設計了體檢報告，其主要特點：1）診斷報告生成的高度自動化。生成健康診斷報告上萬份且全程無人工干預，這一全新的運維方式在之前是不可想象的；2）診斷內容的深度化。從基本的資源使用情況和慢SQL分析，到死鎖檢測和審計日誌全方位統計，再到事務的深層次分析找出應用中的潛在問題等都包含在我們的診斷報告當中；3）運維保障的人性化。雙11保障不是簡單粗暴的讓客戶升級系統規格，而是以優化為主升級為輔的方式。提前主動給出診斷優化建議極大的提升了使用者體驗。

   下面分享一個通過診斷報告解決一個大型線上系統壓測選型問題。客戶壓測RDS記憶體12G和24G兩種規格的效能，但是發現記憶體24G規格的還不如記憶體12G規格的，為什麼規格升級性能反而下降了？我們必須進入到資料庫中的每一條SQL去對比到底是那些SQL的執行時間增加了，但是如何在成千上萬的SQL中找到效能差異的SQL是關鍵突破點。體檢報告這個時候就成為了英雄，RDS的體檢報告中含有TOP SQL的功能，我們發現 TOPSQL中TRUNCATE語句的效能出現了不一致，低規格的truncate語句執行速度優於高規格。通過這個報告定位差異的SQL，那麼為什麼truncate語句在大記憶體中變慢了，truncate 屬於DDL語句，這個讓我們聯想到MySQL的一個bug，就MySQL DDL過程中會將記憶體中的髒頁連結串列遍歷一下，如果記憶體越大，髒頁連結串列也就越長，所以遍歷的時間也就越久，所以很快就定位到這裡truncate語句變慢是因為記憶體上升後遍歷髒頁連結串列時間變長。

三．產品化

   通過前面五年的積累，CloudDBA已經很好支援了我們內部管理人員快速簡單的診斷資料庫的效能問題，包括例項大盤（例項健康狀態）、 實時問題檢測、SQL多維度效能分析（全量SQL，慢SQL）、問題事務分析（事務未提交，查詢開啟事務，長事務，語句時間間隔）、SQL Review（事務列表，事務頻率，時間軸分佈）、例項空間分析、只讀庫延遲分析、死鎖分析、實時會話狀態、熱點表/冗餘索引分析、 SQL分析（執行計劃，相關表DDL，索引建議）、健康體檢報告。計劃將在今年10月初將其產品化輸出到控制檯，真正將我們的經驗和最佳實踐賦能給我們的使用者。

可診斷性建設

   RDS經過5年的發展在穩定性和易用性上不斷積累和沉澱，前面天象和CloudDBA這兩個產品是這5年的一個濃縮。同時在產品的可診斷性上，全鏈路監控可以達到例項級別35個基本監控，主機級別13個基本監控，支援自定義分組監控大盤，監控粒度可達秒級。下面在重點介紹一下RDS的診斷快照。

   診斷快照的設計初衷在於診斷過去時間點發生的問題，比如某客戶反饋昨天晚上凌晨3點中資料庫出現了鎖等待，或者資料庫cpu瞬間抖動了一下，這個時候由於沒有當時出現問題時候的現場，導致問題排查起來顯得比較麻煩，不得不去檢視慢日誌，審計日誌，監控資料等指標。所以如果能夠把出問題時候的現場保留下來，比如核心的show full processlist，show engine innodb status，慢SQL，資料庫中的事務狀態等等，那麼問題診斷起來將會非常容易。所以診斷快照為了解決儲存現場的問題，我們設定了有不同型別的診斷快照，包括定時快照和觸發快照。定時快照是每隔2個小時自動觸發一次資料庫快照，將資料庫中的執行緒，鎖，事務，慢SQL等資訊儲存下來。觸發式快照可以設定CPU、磁碟，連線數等關鍵指標的閥值，觸發式引發診斷快照，這樣就可以把資料庫出現異常情況的時候將現場保留下來，例如上圖顯示的診斷快照列表中，有一個診斷快照診斷分數為0分，就可以檢視process list這一列發現有很多的慢SQL出現了堆積，將資料庫CPU打滿，這樣就非常方便的排查出問題的根源所在。

   此外，可診斷性建設中還有較關鍵的審計日誌，RDS最早的審計日誌採用網路抓包的方式進行採集，但是這種方式收集日誌存在嚴重的日誌丟失和效能損耗。後面改進了資料庫核心，採用類似general_log的方式進行收集審計日誌，實現日誌0丟失，效能損耗只有2%。審計日誌記錄欄位：源ip，使用者名稱，執行緒id，掃描行數，latency，執行時間(us),返回行數，更新行數錯誤號，消耗記憶體。在一些資料庫效能優化中，比如出現QPS抖動，那麼就可以通過TOP SQL功能找出QPS異常抖動是那些SQL帶來的。還有一些問題比如遇到了鎖等待問題，由於資料庫已經持有鎖的SQL是無法檢視的，所以必須通過查審計日誌去找到最終的業務呼叫來自哪裡。

可運維性建設

   前面說過面對使用者的行為習慣是不可控的，不好的使用方法會給後端的例項運維帶來極大的壓力。第一個就是使用者建表時候不指定主鍵，簡簡單單的一個主鍵在使用者刪除資料的時候可能會導致備庫直接hang主，這個時候主備失效，備份無法完成。所以這個簡單的最佳實踐並不所有使用者都遵守的，作為雲廠商該怎麼處理，我們沒有辦法控制使用者行為。所以我們在產品設計時需要規避掉這樣的問題，我們在原始碼中進行優化，如果使用者不指定主鍵，雲端將會自動為使用者建立主鍵。

   第二個問題是很多使用者選擇Memory、Miyisam儲存引擎，在使用者的眼裡這些引擎的效能都是非常好的，卻不知這些引擎後面留著非常多的坑。比如Memory引擎的例項宕掉後，資料就會丟失，進而主備同步會斷。Miyisam引擎不支援事務，在備份時候會鎖住全庫，造成主備延遲，對後端維護挑戰非常大。所以作為雲廠商，我們需要有一定的規範來控制住這些引擎的使用，所以在產品設計的時候，我們將兩個儲存引擎自動轉化成Innodb儲存引擎，這樣對系統的可維護性是具有非常大的幫助。

   第三個問題是主備延遲的問題，MySQL原生複製是單執行緒複製，5.6版本可以支援庫級別的並行複製，對於大部分使用者來說，如果主庫頻繁寫入，備庫必然會出現延遲，主備失效。所以我們優化了MySQL原生複製，預設開啟並行複製。

   第四個是在主備複製中斷上，MySQL原生的邏輯複製存在很多的問題，你會發現主備中斷是一個逃不掉的問題，所以我們在自動化建設上，將常見的主備中斷進行自動化修復，減小主備中斷給客戶帶來的影響。

未來，賦能客戶

   雙11是全民的雙11，雲端計算是全民的雲端計算，我們忠心希望未來使用者在使用雲端計算的時候能夠像使用水電煤一樣簡單。隨著雙11的全民化，有許多企業公司也開始做雙11促銷，但是他們的經驗往往是比較匱乏的。歷年雙11當天我們收到了很多使用者的援助請求，由於前期沒有做好系統壓測，導致在雙十一當天業務高峰來臨的時候系統垮掉，然後才考慮擴容，這個時候往往已經為時已晚。雙11的護航保障經驗是可以更廣的傳播到這些客戶身上，我們也會不斷地將最佳實踐和保障經驗沉澱到專家系統中，今年雙十一，我們將會推出智慧優化服務，將我們多年的資料庫診斷優化經驗直接賦能客戶，只有這樣才能將其作用最大化，規模化，可複製化，讓使用者真正簡單方便的使用雲端計算。