?昨天在南京搞了一場分布式數據庫運維與優(yōu)化的沙龍，對于分布式數據庫的運維，我遇到過一個朋友，他說他們現(xiàn)在很頭痛。分布式數據庫是小問題不需要運維，大問題運維人員搞不定。搞得他請外包DBA覺得不劃算，不請又心里不踏實，用原廠又用不起。目前的情況是有不少企業(yè)已經開始使用分布式數據庫了，也還有些企業(yè)在觀望，不太敢馬上入坑。他們擔心的問題主要還是運維的問題。運維領域有句名言“運維最大的困難是未知”。

這句話包含了多個層面的含義：對數據庫運行狀態(tài)的未知；對技術的未知；對可能遇到的問題的未知，這些未知匯聚起來就是恐懼。當年我們從foxpro轉向大型數據庫，轉向Oracle的時候，也遇到過這樣的時期，那時候出過幾次大問題并且搞不定后，很多企業(yè)都有過想回到簡單的不需要運維的foxpro。與我們熟知的集中式數據庫相比，分布式數據庫就像一只巨大的史前生物一樣，神秘、未知、令人恐懼。

用過分布式數據庫的朋友都知道，分布式數據庫從組成結構上來說，更加復雜。甚至有些國產分布式數據庫是由幾十個不同的開源組件組合而成的。僅僅安裝部署，我們就需要學習ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、普羅米修斯等大型開源組件后才能完成。不過也有些朋友說分布式數據庫運維其實沒那么復雜，大部分的運行中遇到的軟硬件故障，分布式數據庫都會自動處置，不需要運維人員干預。

說句實在話，有一種說法。分布式數據庫出小問題的時候比較容易處理，數據庫本身的高可用就能自動規(guī)避一些小問題，不過分布式數據庫最怕出大問題，最怕出了問題不知道如何處置。

在分布式數據庫中最怕遇到的是兩個事情，一個是后臺自動任務沒在維護窗口跑完，又不敢輕易停止。另外一個就是一個大查詢好像總是跑不完，又不敢干掉重來。遇到這種事情我們是無能為力的，既不能殺掉會話，又不敢重啟數據庫，以往在運維集中式數據庫中的利器似乎都不靈了。

在這種情況下，未知帶來的恐懼是運維中最大的問題，因為恐懼而采取錯誤的處置措施，從而導致災難性的后果，是運維中最不能承受的。所以說，我們需要更深入的去理解分布式數據庫產品，去探討分布式數據庫產品運維的一些新的思路。既然未知是最大的困難，那么變未知為可知，甚至已知，是解決分布式數據庫運維中的十分重要的措施。我們看到現(xiàn)在很多國產分布式數據庫已經開始重視其可觀測性的問題，不僅提供大量的運行指標，等待事件，也開始提供一些ASH，SQL執(zhí)行狀態(tài)的全面跟蹤等接口都在不斷的完善中。

雖然數據庫提供了一些可觀測性接口，但是我們如果不懂如何去使用它也是白搭。因此我們需要構建分布式數據庫的可觀測性接口的采集、分析能力。與集中式數據庫不同，分布式數據庫是多節(jié)點、多分區(qū)、多租戶的，計算節(jié)點和存儲節(jié)點都是分布式的。其指標體系十分復雜。比如一個簡單的參數“IO讀取隊列延時”，就是關于數據庫讀磁盤時的AIO隊列延時。

在分布式數據庫中，這個指標有明細的清單，比如在每個服務，每個租戶上都有一個指標。我們來分析這些指標的時候，直接用明細指標不太方便，我們還需要構建一組統(tǒng)計數據，比如最大值，最小值，標準差，平均值等。在分析的時候，也需要通過這些統(tǒng)計數據來進行分析，不能僅僅分析原始數據。這樣就會導致原本就十分復雜的指標體系，變得更加復雜，更加難以人工監(jiān)控了。因此對于分布式數據庫的運維監(jiān)控，必須構建自動化的體系，否則哪怕是專家，遇到一些他們沒有見到過的問題，也很難完成快速分析與問題定位。

在分布式數據庫的監(jiān)控指標體系構建是十分復雜的，如上圖是一個分布式思考指標體系構成的示意圖。只有完成這樣的指標體系，分布式數據庫的健康管理才能進行。光有原始指標是不夠的，我們必須理解指標背后的含義。因此我們需要構建分布式數據庫指標體系的知識圖譜。

比如上面的加強緩沖命中率指標關聯(lián)的問題就涉及到很多個方面。在構建知識圖譜的時候，主因次因，直接關系，間接關系都要考慮到。這樣在問題分析的時候，才能發(fā)現(xiàn)更多的衍生路徑。這些知識的來源主要是原廠的文檔、專家的運維知識、運維案例、甚至是開源數據庫的源代碼。因為目前我們的國產數據庫的資料與運維案例相對匱乏，因此積累運維經驗并不容易。但是這項工作必須開展起來，否則當國產數據庫大規(guī)模應用的時候就抓瞎了。

最后我分享幾點分布式數據庫運維中的常見問題，首先是分布式數據庫本身的高可用架構會屏蔽一定的故障。因此對于分布式數據庫來說，某個組件的故障是最容易處置的。隔離故障硬件，修復后再加入集群就可以了。最怕的是硬件不穩(wěn)定，時好時壞。比如某個網絡接口一會兒UP，一會兒宕，并且是不是丟包。這種情況很可能引發(fā)分布式數據庫的嚴重故障。不過如果能夠盡早發(fā)現(xiàn)這個問題，并且盡快手工停掉這個網絡端口，對數據庫的影響就很小了。硬盤故障也是如此，特別是多路徑故障，很容易形成時好時壞的局面，這時候IO讀寫變得十分不穩(wěn)定，這個節(jié)點就會變得不穩(wěn)定，從而可能引發(fā)整個數據庫的問題。

對于硬件故障來說，網絡故障對分布式數據庫的影響是全方位的，偶發(fā)的網絡延時增大，網絡丟包等，可能會導致分布式數據庫性能抖動甚至引發(fā)主從副本誤切換，從而引發(fā)更大的故障。確保分布式數據庫的網絡帶寬與網絡延時在一個合理的范圍內并且網絡帶寬不出現(xiàn)瓶頸十分關鍵。

集群數據分布不均衡和負載分布不均衡也可能會導致分布式數據庫的嚴重故障，當某個節(jié)點出現(xiàn)資源瓶頸時，這個影響可能會引發(fā)大型故障。因此對節(jié)點資源的監(jiān)控，一旦發(fā)現(xiàn)較長時間出現(xiàn)某些節(jié)點資源瓶頸，則需要盡快排查，避免引發(fā)大故障。

分布式數據庫的慢SQL分析也是十分關鍵的，發(fā)現(xiàn)慢SQL，讀懂分布式執(zhí)行計劃，發(fā)現(xiàn)執(zhí)行計劃中存在的問題，是分布式數據庫運維DBA日常經常要干的事情。如果發(fā)現(xiàn)某個節(jié)點上的并行執(zhí)行比較慢，那么就需要對某個節(jié)點進行分析，排除隱患了。

分布式數據庫的運維，對于企業(yè)和DBA來說，都是處于剛剛起步的階段，相關的運維知識、故障案例、專家經驗都比較匱乏。數據庫廠商也有義務梳理整理這方面的資料，并在自己的管網上發(fā)布，以便于大家遇到運維問題的時候，有個可參考的依據。我們也希望一些使用同種數據庫產品的企業(yè)，也能建立起一個朋友圈，共同分享這方面的經驗，盡快渡過這個運維知識與能力的空窗期。