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

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

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

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

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

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

雖然數(shù)據(jù)庫提供了一些可觀測性接口，但是我們?nèi)绻欢绾稳ナ褂盟彩前状睢Ｒ虼宋覀冃枰獦?gòu)建分布式數(shù)據(jù)庫的可觀測性接口的采集、分析能力。與集中式數(shù)據(jù)庫不同，分布式數(shù)據(jù)庫是多節(jié)點、多分區(qū)、多租戶的，計算節(jié)點和存儲節(jié)點都是分布式的。其指標(biāo)體系十分復(fù)雜。比如一個簡單的參數(shù)“IO讀取隊列延時”，就是關(guān)于數(shù)據(jù)庫讀磁盤時的AIO隊列延時。

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

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

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

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

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

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

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

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