314
我們是如何做數據庫運維和優化
8月24日阿裏雲數據庫技術峰會上，阿裏雲高級DBA專家玄慚帶來麵對超大規模的數據庫集群，尤其是在每年像雙11這樣重大促銷活動中，阿裏雲是如何進行運維和優化的。本文主要介紹了天象和CloudDBA兩個產品，包括他們的起源、基於係統畫像倉庫的應用、產品化等，最後對RDS產品的可診斷性建設和可運維性建設作了補充。
隨著雲數據庫時代的到來，它的運維體係不僅僅包括保持數據庫集群的穩定，同時我們還要關注用戶體驗。在業務上，體量大，用戶各類，例如有公有雲小客戶，也有企業大客戶，每類客戶的需求都各式不一，眾口難調。在係統上，為了實現故障切換和資源對用戶透明，係統設計中包括了眾多組件，例如RDS的數據訪問鏈路從DNS-SLB-Proxy-DB節點，也有管理控製鏈路從前端控製台-OPEN API-後端組件-DB節點，這樣給問題的排查帶來了巨大的困難，出現了一個問題你不知道是出現在那個環節。在服務上，每個用戶都要求一樣高的SLA，服務的不好可能就會引發公關危機。所以在雲數據庫時代我們麵臨著下麵三個挑戰：
一． 實例數呈指數級別增長，後端運維壓力急劇上升。
二． 用戶端不在我們的管理範圍內，無法配合排查，巨大的成本。
麵對這樣的挑戰該如何突破，冰凍三尺非一日之寒，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的護航保障經驗是可以更廣的傳播到這些客戶身上，我們也會不斷地將最佳實踐和保障經驗沉澱到專家係統中，今年雙十一，我們將會推出智能優化服務，將我們多年的數據庫診斷優化經驗直接賦能客戶，隻有這樣才能將其作用最大化，規模化，可複製化，讓用戶真正簡單方便的使用雲計算。
最後更新：2017-09-07 10:32:35