資料庫智慧管理助手-CloudDB詳解及最佳實踐

摘要：阿里雲CloudDBA主要分為離線分析和線上分析兩種功能。幫助使用者節省成本，定位問題，分析原因並推薦解決方法。CloudDBA可以做到實時診斷，離線診斷和SQL最佳化。並且透過MySQL的引數調優，檢測引數的不合理或者準備的延遲的情況。

演講嘉賓簡介：

▲勳臣，阿里雲RDS核心團隊技術專家

以下內容根據演講嘉賓影片分享以及PPT整理而成。

本次的分享主要圍繞以下三個方面：

一、CloudDBA提供了什麼

二、核心能力

三、典型實踐應用

一、CloudDBA提供了什麼

CloudDBA主要提供了兩個功能，一個是離線分析，另一個是線上分析。我們知道DBA主要日常工作分為兩塊，一個是群檢，還有就是做線上的響應，比如說我的資料庫突然一下應用被卡住了，或者資料庫出現效能抖動，這些問題都是需要DBA實時響應的。Oracle包括兩個報告，一個是AWR報告，還有一個叫ASH報告，我們從功能上來說和Oracle有些類似。離線的分析主要是AWR報告，然後線上響應是ACTIVE SESS HISTORY。

CloudDBA在雲上是SASS化的一塊，是基於PaaS平臺的增值服務。雲上的SASS需要去解決效能的問題，問題的診斷，以及提供一些輔助的工具。雲上的資料庫跟自建的資料庫有一點不同，如果資料庫上雲了之後，PaaS這層的工作雲都幫忙解決了。比如，效能監控，HA等都已經做了。DBA真正要做的是上面這一層，就是怎麼讓資料庫執行的更好，讓使用者用好資料庫。

不管是雲上的還是自建的資料庫，它本身的成本實際上是看得見的，是很低的。對做DBA的同學來說，從準備到資料庫上線花費的精力實際上是有限的。而真正的難點是如何把資料庫管理好?因為我們為做產品的平臺應用提供支撐，如果使用者的使用習慣不好，很容易將我們的資料庫搞壞掉，整個業務都會受到影響。所以從下圖可以看到我們的資料庫會有大量的維護成本，大概大於80%。當然DBA主要是解決應用中的一些問題，節省時間成本。比如說，使用者反饋說應用卡住了，對DBA來說需要登入到資料庫中，到控制檯看動畫，看看到底發生了什麼?這些動作實際上是很重複，很機械的、如果有CloudDBA，它會有自己的一些小的指令碼，比如定位問題，很快的可以輸入使用者名稱密碼，把狀態抓出來，基於狀態做一些判斷。這種方式是可以的，但是還有更好的解決方式，如果作為一個產品，把這樣的行為產品化和服務化，交付出來。在應用卡住的時候，使用者只需要點一個按鈕，產品就可以把狀態抓出來，並且分析出資料庫卡住的點，並給出下一步的解決建議。甚至絕大部分場景，命令都會給生成出來，使用者直接複製執行就可以了。

二、核心能力

1.實時診斷

我們會把DBA積累的經驗產品化，編成程式，錄入到資料庫中去。將診斷的結果進行輸出。我們在日常工作當中會經常發現同樣的問題對不同的DBA來說解決的方式也不同。甚至說一位同學在當值班的時候遇到問題，知道怎麼解決了，換另一位同學指班沒有遇到問題，過了很長的時間再一次發生時大家可能都忘了如何解決這個問題。所以這時就需要將工作經驗進行沉澱，產品化，服務化，再把它輸入出來。我們把解決問題的方法。技巧，經驗錄入到資料庫(Knowledge Base)中，它就是一個診斷程式，經過不斷的錄入經驗，Knowledge Base會變得越來越豐富。結果格式會分為現象描述，原因描述和相關診斷建議。

2.離線診斷

離線診斷是基於狀態，做深層次的分析，挖掘Top SQL，看哪些SQL執行次數最多，最長，消耗時間最長。另外還有事物分析，看事物是否合理，以及SQL Review。因為我們做DBA，如果沒有一個很強大的工具去規範開發人員行為的話，這個工具遲早會被拖垮。在早期的時候，出一份規範發給開發人員，要求搜尋語句只能按照規範寫，否則會出事。但是如果沒有一個工具約束和規範，每個開發團隊都不可能看每一條規範語句。還有就是死鎖的分析。

3.SQL最佳化

MySQL的最佳化器當然沒有Qracle那麼優秀，我們經常會聽到它的執行效果不是很好，表的連線順序不是那麼的最優。比如表上面有索引，但是索引失效了，大家都知道索引失效的情況是欄位不匹配。我們的工具會幫助我們在欄位後面加個函式。比如說有一個交易表，交易表上有一個欄位用時間去get，因為目前時間都至少精確到秒。很多開發人員會把日期函式直接加在get上面，等於具體某一天就可以了。但是如果用Oracle或者SQL Server3的資料庫是沒有問題的，DBA會給你加一個函式索引。但是如果用的是MySQL，而且是5.7之前的版本是沒有辦法的，真正的寫法是大於等於這一天的開始和小於等於這一天的結束，應該是這一天24小時的範圍之內都可以識別出來。還有一個是計算代價的重寫，我們會到備庫動態的取樣，比如說一個查詢，上面沒有索引，帶有多個欄位，要建一個混合索引，那麼這個欄位的順序應該怎麼放?我們會到備庫中動態取樣，看這些列上的資料分佈，然後生成最優的欄位順序，最優的索引。因為不可能看幾個欄位有的所有索引順序，所以採取動態取樣。這一塊的內容可以到阿里雲的官網搜，有很多非常詳細的資料和影片。

三、最佳實踐

我們經常遇到使用者把規格升級，然後進行壓測，發現升級規格後效能反而下降。比如4C32G生級成了8C62G，發現吞吐下降。透過診斷報告TOP SQL定位效能下降原因。發現truncate的執行時間變慢了，為什麼變慢?因為表的記憶體變多了，的張頁變多了，MySQL truncate之前是要把張頁落入檔案裡面去，利用我們的工具可以很快的定位原因語句，下一步應該把MySQL的 Max present的引數調小，把張塊控制在一定的範圍裡面。

另外一個問題是使用者說每隔半小時就會出現壓力抖動，查明什麼原因。因為使用者提出這個問題時，抖動發生的時間是在前幾天或者過了幾個小時。所以我們會建議使用者開啟CloudDBA，這樣才方便我們跟蹤，具體的資料使用者在自己的的控制檯就可以看到了。如下圖是透過TOP SQL得到的診斷報告，知道哪個時間發生了抖動。

連線滿了也分為不同的場景。第一種是出現鎖了，這種是最常見的，這是把鎖會話KILL掉。第二種就是在業務高空的時候執行了ddl的操作，這時也很好解決，我們都會幫助使用者定位出來。還有一種是應用程式的連線使用有問題，沒有關掉。比如Java的JDBC開了之後沒有關掉，這時我們也可以識別出來。我們會建議使用者使用連線池，及時的把連線關掉。還有一個，既不是MySQL堆積也不是鎖，也正常使用連線池，這時就可能是規格太小，壓力太大。如果不能升級規格，那麼應用程式就要做限流。

連線滿了之後，CloudDBA可以幫助識別並終止會話。

CPU達到100%之後，CloudDBA可以幫忙識別出來，同時進行最佳化

除了上述的幾種場景，阿里還做了一些引數最佳化。MySQL有非常多的引數，引數的不合理或者準備的延遲都可以透過CloudDBA檢測出來。

CloudDBA是一個動態淨化的產品，我們是在不斷的更新。我們會和阿里雲的工單系統聯絡，他們處理的工單會扭轉到我們這邊，我們會吸收消化掉一部分，看哪些可以透過程式整合起來，RDBA會嵌在RDS資料庫的控制檯上面，使用者可以免費使用。

本文由雲棲志願小組董黎明整理