前天发了一篇关于国产集中式数据库的通用诊断方法，有朋友问这个方法是否适用于分布式数据库呢?大体思路是可以借鉴的，但是分布式数据库是完全不同的，想要把集中式数据库的诊断方法直接用于分布式数据库还是不完全可行的。

用过分布式数据库的朋友都知道，分布式数据库从组成结构上来说更加复杂。甚至有些国产分布式数据库是由几十个不同的开源组件组合而成的。仅仅安装部署，我们就需要学习ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、普罗米修斯等大型开源组件后才能完成。不过也有些朋友说分布式数据库运维其实没那么复杂，大部分的运行中遇到的软硬件故障，分布式数据库都会自动处置，不需要运维人员干预。分布式数据库出小问题的时候比较容易处理，数据库本身的高可用就能自动规避一些小问题，不过分布式数据库最怕出大问题，最怕出了问题不知道如何处置。那么我们该如何来分析分布式数据库的问题呢?

首先是分布式数据库本身的高可用架构会屏蔽一定的故障。因此对于分布式数据库来说，某个组件的故障是最容易处置的。隔离故障硬件，修复后再加入集群就可以了。最怕的是硬件不稳定，时好时坏。比如某个网络接口一会儿UP，一会儿宕，并且是不是丢包。这种情况很可能引发分布式数据库的严重故障。不过如果能够尽早发现这个问题，并且尽快手工停掉这个网络端口，对数据库的影响就很小了。硬盘故障也是如此，特别是多路径故障，很容易形成时好时坏的局面，这时候IO读写变得十分不稳定，这个节点就会变得不稳定，从而可能引发整个数据库的问题。

对于硬件故障来说，网络故障对分布式数据库的影响是全方位的，偶发的网络延时增大，网络丢包等，可能会导致分布式数据库性能抖动甚至引发主从副本误切换，从而引发更大的故障。确保分布式数据库的网络带宽与网络延时在一个合理的范围内并且网络带宽不出现瓶颈十分关键。

集群数据分布不均衡和负载分布不均衡也可能会导致分布式数据库的严重故障，当某个节点出现资源瓶颈时，这个影响可能会引发大型故障。因此对节点资源的监控，一旦发现较长时间出现某些节点资源瓶颈，则需要尽快排查，避免引发大故障。

分布式数据库的慢SQL分析也是十分关键的，发现慢SQL，读懂分布式执行计划，发现执行计划中存在的问题，是分布式数据库运维DBA日常经常要干的事情。如果发现某个节点上的并行执行比较慢，那么就需要对某个节点进行分析，排除隐患了。

根据上面的内容，我们对局部思维导图做了改写。实际上作为通用的分布式数据库分析方法。首先还是需要分析操作系统日志和数据库日志。只是目前来说国产分布式数据库的日志分析十分困难，缺乏好的工具可以从数据库中自动抽取日志相关信息，并且能够自动对多节点日志中的各种事件进行排序。OceanBase的开源诊断工具obdiag是目前我见到过的比较好的国产分布式数据库诊断工具，在日志分析方面的功能还是挺有用的。不过离我理想中的分析能力还有一定的差距。

在所有分析开始之前，首先要排除硬件故障的可能性。对大型分布式数据库而言，硬件监控是必须要有的。如果靠人工排查，那么将会相当耗时。通过OS日志分析等也可以快速定位硬件故障，只不过如果是手工操作，则工作量过大。

日志分析后就进入了今天我画的这张图的内容了。第一步首先要检查的是时钟同步和时钟源(clocksource)是否一致，时钟问题对于集中式数据库来说关系不是很大，但是对于大多数分布式数据库来说十分关键。

第二步是检查网络是否存在问题，包括网卡故障、PING延时、网络吞吐量、网络丢包、网络流量的均衡性等都需要关注。

第三步是进行各种操作系统资源的分析。对于分布式数据库而言首先我们不需要直接下钻到某台服务器去进行观察，而是要观察多个对等服务器节点的资源均衡性。分布式数据库极容易出问题的地方是资源不均衡，如果一个几十台服务器节点的分布式数据库环境中只有某一个或者某几个服务器的内存换页严重或者IO延时过高，那么可能会让整个集群的性能都受到极大的影响。如果发现不均衡，那么首先要考虑是不是应用负载不均衡，或者分布式执行计划出现了问题，这些都是十分常见的。

对于分布式数据库而言，会话分析也与集中式数据库不同，会话均衡性、活跃会话均衡性、新增会话均衡性等指标是发现问题的关键，因此针对这些指标，需要常态化采集。