前天发了一篇对于国产汇聚式数据库的通用会诊要道，有一又友问这个要道是否适用于散布式数据库呢?大体想路是不错模仿的，然而散布式数据库是系数不同的，想要把汇聚式数据库的会诊要道径直用于散布式数据库已经不系数可行的。

用过散布式数据库的一又友皆知谈，散布式数据库从构成结构上来说愈加复杂。致使有些国产散布式数据库是由几十个不同的开源组件组合而成的。只是装配部署，咱们就需要学习ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、普罗米修斯等大型开源组件后技能完成。不外也有些一又友说散布式数据库运维其实没那么复杂，大部分的运行中际遇的软硬件故障，散布式数据库皆会自动解决，不需要运维东谈主员干扰。散布式数据库出小问题的时候比拟容易处理，数据库本人的高可用就能自动销毁一些小问题，不外散布式数据库最怕出大问题，最怕出了问题不知谈怎样解决。那么咱们该怎样来分析散布式数据库的问题呢?

当先是散布式数据库本人的高可用架构会屏蔽一定的故障。因此对于散布式数据库来说，某个组件的故障是最容易解决的。断绝故障硬件，建树后再加入集群就不错了。最怕的是硬件不分解，时好时坏。比如某个蚁集接口一霎UP，一霎宕，而且是不是丢包。这种情况很可能激励散布式数据库的严重故障。不外若是八成尽早发现这个问题，而且尽快手工停掉这个蚁集端口，对数据库的影响就很小了。硬盘故障亦然如斯，杰出是多旅途故障，很容易酿成时好时坏的场所，这时候IO读写变得十分不分解，这个节点就会变得不分解，从而可能激励通盘这个词数据库的问题。

对于硬件故障来说，蚁集故障对散布式数据库的影响是全方向的，偶发的蚁集延时增大，蚁集丢包等，可能会导致散布式数据库性能抖动致使激励主从副本误切换，从而激励更大的故障。确保散布式数据库的蚁集带宽与蚁集延时在一个合理的范围内而且蚁集带宽不出现瓶颈十分环节。

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

散布式数据库的慢SQL分析亦然十分环节的，发现慢SQL，读懂散布式实施筹画，发现实施筹画中存在的问题，是散布式数据库运维DBA平频频常要干的事情。若是发现某个节点上的并行实施比拟慢，那么就需要对某个节点进行分析，摒除隐患了。

阐述上头的内容，咱们对局部想维导图作念了改写。试验上动作通用的散布式数据库分析要道。当先已经需要分析操作系统日记和数据库日记。只是现在来说国产散布式数据库的日记分析十分贫苦，枯竭好的用具不错从数据库中自动抽取日记接洽信息，而且八成自动对多节点日记中的多样事件进行排序。OceanBase的开源会诊用具obdiag是现在我见到过的比拟好的国产散布式数据库会诊用具，在日记分析方面的功能已经挺有效的。不外离我想象中的分析智商还有一定的差距。

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

日记分析后就投入了今天我画的这张图的内容了。第一步当先要查验的是时钟同步和时钟源(clocksource)是否一致，时钟问题对于汇聚式数据库来说联系不是很大，然而对于大巨额散布式数据库来说十分环节。

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

第三步是进行多样操作系统资源的分析。对于散布式数据库而言当先咱们不需要径直下钻到某台做事器去进行不雅察，而是要不雅察多个平等做事器节点的资源平衡性。散布式数据库极容易出问题的场合是资源不平衡，若是一个几十台做事器节点的散布式数据库环境中独一某一个或者某几个做事器的内存换页严重或者IO延时过高，那么可能会让通盘这个词集群的性能皆受到极大的影响。若是发现不平衡，那么当先要计划是不是诈骗负载不平衡，或者散布式实施筹画出现了问题，这些皆是十分常见的。

对于散布式数据库而言，会话分析也与汇聚式数据库不同，会话平衡性、活跃会话平衡性、新增会话平衡性等意见是发现问题的环节体育游戏app平台，因此针对这些意见，需要常态化蚁集。