前天發(fā)了一篇關(guān)于國產(chǎn)集中式數(shù)據(jù)庫的通用診斷方法，有朋友問這個(gè)方法是否適用于分布式數(shù)據(jù)庫呢？大體思路是可以借鑒的，但是分布式數(shù)據(jù)庫是完全不同的，想要把集中式數(shù)據(jù)庫的診斷方法直接用于分布式數(shù)據(jù)庫還是不完全可行的。

用過分布式數(shù)據(jù)庫的朋友都知道，分布式數(shù)據(jù)庫從組成結(jié)構(gòu)上來說更加復(fù)雜。甚至有些國產(chǎn)分布式數(shù)據(jù)庫是由幾十個(gè)不同的開源組件組合而成的。僅僅安裝部署，我們就需要學(xué)習(xí)ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、普羅米修斯等大型開源組件后才能完成。不過也有些朋友說分布式數(shù)據(jù)庫運(yùn)維其實(shí)沒那么復(fù)雜，大部分的運(yùn)行中遇到的軟硬件故障，分布式數(shù)據(jù)庫都會自動處置，不需要運(yùn)維人員干預(yù)。分布式數(shù)據(jù)庫出小問題的時(shí)候比較容易處理，數(shù)據(jù)庫本身的高可用就能自動規(guī)避一些小問題，不過分布式數(shù)據(jù)庫最怕出大問題，最怕出了問題不知道如何處置。那么我們該如何來分析分布式數(shù)據(jù)庫的問題呢？

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

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

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

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

圖片

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

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

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

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

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

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