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

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

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

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

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

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

圖片

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

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

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

第二步是檢查網絡是否存在問題，包括網卡故障、PING延時、網絡吞吐量、網絡丟包、網絡流量的均衡性等都需要關注。

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

對于分布式數據庫而言，會話分析也與集中式數據庫不同，會話均衡性、活躍會話均衡性、新增會話均衡性等指標是發現問題的關鍵，因此針對這些指標，需要常態化采集。