用過分布式數(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ù)庫的問題呢?

首先是分布式數(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)行分析，排除隱患了。

根據(jù)上面的內(nèi)容，我們對局部思維導(dǎo)圖做了改寫。實際上作為通用的分布式數(shù)據(jù)庫分析方法。首先還是需要分析操作系統(tǒng)日志和數(shù)據(jù)庫日志。只是目前來說國產(chǎn)分布式數(shù)據(jù)庫的日志分析十分困難，缺乏好的工具可以從數(shù)據(jù)庫中自動抽取日志相關(guān)信息，并且能夠自動對多節(jié)點日志中的各種事件進(jìn)行排序。OceanBase的開源診斷工具obdiag是目前我見到過的比較好的國產(chǎn)分布式數(shù)據(jù)庫診斷工具，在日志分析方面的功能還是挺有用的。不過離我理想中的分析能力還有一定的差距。

在所有分析開始之前，首先要排除硬件故障的可能性。對大型分布式數(shù)據(jù)庫而言，硬件監(jiān)控是必須要有的。如果靠人工排查，那么將會相當(dāng)耗時。通過OS日志分析等也可以快速定位硬件故障，只不過如果是手工操作，則工作量過大。

日志分析后就進(jìn)入了今天我畫的這張圖的內(nèi)容了。第一步首先要檢查的是時鐘同步和時鐘源(clocksource)是否一致，時鐘問題對于集中式數(shù)據(jù)庫來說關(guān)系不是很大，但是對于大多數(shù)分布式數(shù)據(jù)庫來說十分關(guān)鍵。

第二步是檢查網(wǎng)絡(luò)是否存在問題，包括網(wǎng)卡故障、PING延時、網(wǎng)絡(luò)吞吐量、網(wǎng)絡(luò)丟包、網(wǎng)絡(luò)流量的均衡性等都需要關(guān)注。

第三步是進(jìn)行各種操作系統(tǒng)資源的分析。對于分布式數(shù)據(jù)庫而言首先我們不需要直接下鉆到某臺服務(wù)器去進(jìn)行觀察，而是要觀察多個對等服務(wù)器節(jié)點的資源均衡性。分布式數(shù)據(jù)庫極容易出問題的地方是資源不均衡，如果一個幾十臺服務(wù)器節(jié)點的分布式數(shù)據(jù)庫環(huán)境中只有某一個或者某幾個服務(wù)器的內(nèi)存換頁嚴(yán)重或者IO延時過高，那么可能會讓整個集群的性能都受到極大的影響。如果發(fā)現(xiàn)不均衡，那么首先要考慮是不是應(yīng)用負(fù)載不均衡，或者分布式執(zhí)行計劃出現(xiàn)了問題，這些都是十分常見的。

對于分布式數(shù)據(jù)庫而言，會話分析也與集中式數(shù)據(jù)庫不同，會話均衡性、活躍會話均衡性、新增會話均衡性等指標(biāo)是發(fā)現(xiàn)問題的關(guān)鍵，因此針對這些指標(biāo)，需要常態(tài)化采集。