分散式資料庫運維有啥特殊的？

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

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

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

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

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

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

雖然資料庫提供了一些可觀測性介面，但是我們如果不懂如何去使用它也是白搭。因此我們需要構建分散式資料庫的可觀測性介面的採集、分析能力。與集中式資料庫不同，分散式資料庫是多節點、多分割槽、多租戶的，計算節點和儲存節點都是分散式的。其指標體系十分複雜。比如一個簡單的引數“IO讀取佇列延時”，就是關於資料庫讀磁碟時的AIO佇列延時。

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

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

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

最後我分享幾點分散式資料庫運維中的常見問題，首先是分散式資料庫本身的高可用架構會遮蔽一定的故障。因此對於分散式資料庫來說，某個元件的故障是最容易處置的。隔離故障硬體，修復後再加入叢集就可以了。最怕的是硬體不穩定，時好時壞。比如某個網路介面一會兒UP，一會兒宕，並且是不是丟包。這種情況很可能引發分散式資料庫的嚴重故障。不過如果能夠儘早發現這個問題，並且儘快手工停掉這個網路埠，對資料庫的影響就很小了。硬碟故障也是如此，特別是多路徑故障，很容易形成時好時壞的局面，這時候IO讀寫變得十分不穩定，這個節點就會變得不穩定，從而可能引發整個資料庫的問題。

對於硬體故障來說，網路故障對分散式資料庫的影響是全方位的，偶發的網路延時增大，網路丟包等，可能會導致分散式資料庫效能抖動甚至引發主從副本誤切換，從而引發更大的故障。確保分散式資料庫的網路頻寬與網路延時在一個合理的範圍內並且網路頻寬不出現瓶頸十分關鍵。

叢集資料分佈不均衡和負載分佈不均衡也可能會導致分散式資料庫的嚴重故障，當某個節點出現資源瓶頸時，這個影響可能會引發大型故障。因此對節點資源的監控，一旦發現較長時間出現某些節點資源瓶頸，則需要儘快排查，避免引發大故障。

分散式資料庫的慢SQL分析也是十分關鍵的，發現慢SQL，讀懂分散式執行計劃，發現執行計劃中存在的問題，是分散式資料庫運維DBA日常經常要乾的事情。如果發現某個節點上的並行執行比較慢，那麼就需要對某個節點進行分析，排除隱患了。

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