乾貨|上雲了，如何保障雲資料庫的高可用？

和京東雲平臺質量部的同學們對上述的Case進行分析後，我們總結了以下原因：

慢SQL

常態下系統中存在很多慢SQL，其執行時間少則15s，多則60s以上，如果慢SQL的執行次數增加，必然導致雲資料庫壓力上升，資料庫連線被佔用，處理其他請求的速率也慢了下來，直至連線數被耗光，導致服務異常，或者在連線數沒耗光之前，就因為資料庫CPU使用率100%而導致服務異常了。

高頻SQL

高頻SQL看似沒有問題，但延時一旦增加或者網路抖動，高頻SQL就可能變為較慢的SQL，基於其基礎足夠大，足以將系統拖垮。

複用

上面的多次故障都是因為某一個業務異常導致資料庫故障後，影響到了資料庫上的所有業務，這可能是源於期望降低運維複雜度，所以搞了一個最大規格資料庫的原因，確實，所有業務共用一個資料庫從管理角度肯定更簡單。

讀寫未分離

上述的Case，大部分都是讀請求導致的故障，突然間因為各種原因，導致請求上漲，而資料庫例項只有一個，沒有水平擴充套件，所以很容易被打掛。

資料庫連線數設定不合理

從故障描述中可以看到，隨便一個請求，都可以把資料庫的併發連線數打到2000+以上，進而導致其他業務不可用，沒有對不同業務進行合理的資源分配。

缺乏變更流程

研發直接到線上資料庫中修改資料，修改錯誤的原因有表的名字錯了，where條件錯了，或者是對較大的表結構進行調整，操作前不線上下進行測試驗證，操作前也不進行資料庫備份，很容易導致重大事故。

許可權管理混亂

多個CASE都是研發直接操作線上資料，這是許可權管理混亂的表現，也是很危險的事情。試想，人人都能修改資料庫，會有什麼後果大家應該都很清楚。如果修改了和交易資料相關的資料，或者是刪庫跑路，那就麻煩了。

不限流

TOP-N的SQL限流

在京東雲上，提供了效能最佳化的功能，可以查詢到所有的慢SQL，一定要加以使用

最後提一句，一定要想辦法在叢集上實現自動化kill慢SQL的功能，而不要等遇到出問題後挨個找人來看能不能殺這些SQL，那就太晚了，經驗值，一旦走到這個地步，故障時長起步40分鐘。

隔離部署

讀寫分離

京東雲的雲資料庫提供只讀例項，需要利用好該特性。簡單點就是新增幾個只讀例項將讀請求進行遷移，複雜點，可以將不同業務型別的讀請求分配到不同的只讀例項上，利用隔離的特性將故障控制在較小的範圍內，從而保障大部分功能的正常使用。

限流

資料備份

對資料庫的任何修改和調整，都需要進行備份，以免發生上述朋友的問題。京東雲提供了靈活的資料庫備份管理功能，需要好好的使用起來。這個地方的重要性，就不贅述了。

資料庫的監控

沒上雲之前，可能會有專門的DBA團隊來對資料庫進行監控，上雲後，如果沒有專職的DBA，那麼業務運維團隊就需要承擔起這個責任來。下面是從京東雲的監控中擷取的幾個關鍵指標，當然，還需要有對資料庫功能的監控。在這點上，雲平臺質量部有較為豐富的經驗，大家也可以參考《監控不到位，當機兩行淚》。

流程建立

最後，感謝平臺質量部的多個小夥伴一起群策群力完成的上述方案。

參考文獻：