前天发了一篇对于国产说合式数据库的通用会诊尺度，有一又友问这个尺度是否适用于散播式数据库呢?大体想路是不错模仿的，可是散播式数据库是十足不同的，想要把说合式数据库的会诊尺度径直用于散播式数据库也曾不十足可行的。

用过散播式数据库的一又友王人知说念，散播式数据库从构成结构上来说愈加复杂。以致有些国产散播式数据库是由几十个不同的开源组件组合而成的。只是装配部署，咱们就需要学习ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、普罗米修斯等大型开源组件后才智完成。不外也有些一又友说散播式数据库运维其实没那么复杂，大部分的运行中碰到的软硬件故障，散播式数据库王人会自动处理，不需要运维东说念主员干涉。散播式数据库出小问题的时候相比容易处理，数据库本人的高可用就能自动逃避一些小问题，不外散播式数据库最怕出大问题，最怕出了问题不知说念奈那边理。那么咱们该奈何来分析散播式数据库的问题呢?

领先是散播式数据库本人的高可用架构会屏蔽一定的故障。因此对于散播式数据库来说，某个组件的故障是最容易处理的。遮拦故障硬件，缔造后再加入集群就不错了。最怕的是硬件不踏实，时好时坏。比如某个汇集接口瞬息UP，瞬息宕，况且是不是丢包。这种情况很可能激发散播式数据库的严重故障。不外如若简略尽早发现这个问题，况且尽快手工停掉这个汇集端口，对数据库的影响就很小了。硬盘故障亦然如斯，绝顶是多旅途故障，很容易造成时好时坏的场面，这时候IO读写变得十分不踏实，这个节点就会变得不踏实，从而可能激发通盘数据库的问题。

对于硬件故障来说，汇集故障对散播式数据库的影响是全标的的，偶发的汇集延时增大，汇集丢包等，可能会导致散播式数据库性能抖动以致激发主从副本误切换，从而激发更大的故障。确保散播式数据库的汇集带宽与汇集延时在一个合理的规模内况且汇集带宽不出现瓶颈十分要津。

集群数据散播不平衡和负载散播不平衡也可能会导致散播式数据库的严重故障，当某个节点出现资源瓶颈时，这个影响可能会激发大型故障。因此对节点资源的监控，一朝发现较长本领出现某些节点资源瓶颈，则需要尽快排查，幸免激发大故障。

散播式数据库的慢SQL分析亦然十分要津的，发现慢SQL，读懂散播式施行筹办，发现施行筹办中存在的问题，是散播式数据库运维DBA平日频繁要干的事情。如若发现某个节点上的并行施行相比慢，那么就需要对某个节点进行分析，摈斥隐患了。

笔据上头的内容，咱们对局部想维导图作念了改写。实践上动作通用的散播式数据库分析尺度。领先也曾需要分析操作系统日记和数据库日记。只是现在来说国产散播式数据库的日记分析十分艰难，缺少好的器具不错从数据库中自动抽取日记说合信息，况且简略自动对多节点日记中的多样事件进行排序。OceanBase的开源会诊器具obdiag是现在我见到过的相比好的国产散播式数据库会诊器具，在日记分析方面的功能也曾挺灵验的。不外离我设想中的分析智商还有一定的差距。

在通盘分析运行之前，领先要摈斥硬件故障的可能性。对大型散播式数据库而言，硬件监控是必须要有的。如若靠东说念主工排查，那么将会十分耗时。通过OS日记分析等也不错快速定位硬件故障，只不外如若是手工操作，则使命量过大。

日记分析后就插足了今天我画的这张图的内容了。第一步领先要查验的是时钟同步和时钟源(clocksource)是否一致，时钟问题对于说合式数据库来说说合不是很大，可是对于大无数散播式数据库来说十分要津。

第二步是查验汇集是否存在问题，包括网卡故障、PING延时、汇集微辞量、汇集丢包、汇集流量的平衡性等王人需要关爱。

第三步是进行多样操作系统资源的分析。对于散播式数据库而言开云kaiyun.com领先咱们不需要径直下钻到某台职业器去进行不雅察，而是要不雅察多个平等职业器节点的资源平衡性。散播式数据库极容易出问题的方位是资源不平衡，如若一个几十台职业器节点的散播式数据库环境中只须某一个或者某几个职业器的内存换页严重或者IO延时过高，那么可能会让通盘集群的性能王人受到极大的影响。如若发现不平衡，那么领先要斟酌是不是诓骗负载不平衡，或者散播式施行筹办出现了问题，这些王人是十分常见的。

对于散播式数据库而言，会话分析也与说合式数据库不同，会话平衡性、活跃会话平衡性、新增会话平衡性等绸缪是发现问题的要津，因此针对这些绸缪，需要常态化汇聚。