前天发了一篇对于国产聚首式数据库的通用会诊步伐，有一又友问这个步伐是否适用于漫步式数据库呢?大体想路是不错鉴戒的开yun体育网，然则漫步式数据库是填塞不同的，想要把聚首式数据库的会诊步伐平直用于漫步式数据库依然乌有足可行的。
用过漫步式数据库的一又友王人知说念，漫步式数据库从构成结构上来说愈加复杂。甚而有些国产漫步式数据库是由几十个不同的开源组件组合而成的。只是装配部署，咱们就需要学习ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、普罗米修斯等大型开源组件后身手完成。不外也有些一又友说漫步式数据库运维其实没那么复杂，大部分的运行中遭受的软硬件故障，漫步式数据库王人会自动科罚，不需要运维东说念主员烦闷。漫步式数据库出小问题的时候相比容易处理，数据库自己的高可用就能自动侧目一些小问题，不外漫步式数据库最怕出大问题，最怕出了问题不知说念怎样科罚。那么咱们该怎样来分析漫步式数据库的问题呢?
最初是漫步式数据库自己的高可用架构会屏蔽一定的故障。因此对于漫步式数据库来说，某个组件的故障是最容易科罚的。停止故障硬件，栽种后再加入集群就不错了。最怕的是硬件不牢固，时好时坏。比如某个收集接口一忽儿UP，一忽儿宕，何况是不是丢包。这种情况很可能激励漫步式数据库的严重故障。不外要是约略尽早发现这个问题，何况尽快手工停掉这个收集端口，对数据库的影响就很小了。硬盘故障亦然如斯，罕见是多旅途故障，很容易造成时好时坏的口头，这时候IO读写变得十分不牢固，这个节点就会变得不牢固，从而可能激励通盘这个词数据库的问题。
张开剩余67%对于硬件故障来说，收集故障对漫步式数据库的影响是全主义的，偶发的收集延时增大，收集丢包等，可能会导致漫步式数据库性能抖动甚而激励主从副本误切换，从而激励更大的故障。确保漫步式数据库的收集带宽与收集延时在一个合理的界限内何况收集带宽不出现瓶颈十分关节。
集群数据漫步不平衡和负载漫步不平衡也可能会导致漫步式数据库的严重故障，当某个节点出现资源瓶颈时，这个影响可能会激励大型故障。因此对节点资源的监控，一朝发现较长本事出现某些节点资源瓶颈，则需要尽快排查，幸免激励大故障。
漫步式数据库的慢SQL分析亦然十分关节的，发现慢SQL，读懂漫步式实践盘算，发现实践盘算中存在的问题，是漫步式数据库运维DBA宽泛庸俗要干的事情。要是发现某个节点上的并行实践相比慢，那么就需要对某个节点进行分析，放弃隐患了。
阐发上头的内容，咱们对局部想维导图作念了改写。实际上动作通用的漫步式数据库分析步伐。最初依然需要分析操作系统日记和数据库日记。只是当今来说国产漫步式数据库的日记分析十分艰巨，缺少好的用具不错从数据库中自动抽取日记关连信息，何况约略自动对多节点日记中的各式事件进行排序。OceanBase的开源会诊用具obdiag是当今我见到过的相比好的国产漫步式数据库会诊用具，在日记分析方面的功能依然挺有效的。不外离我想象中的分析智商还有一定的差距。
在通盘分析初始之前，最初要放弃硬件故障的可能性。对大型漫步式数据库而言，硬件监控是必须要有的。要是靠东说念主工排查，那么将会卓越耗时。通过OS日记分析等也不错快速定位硬件故障，只不外要是是手工操作，则职责量过大。
日记分析后就干与了今天我画的这张图的内容了。第一步最初要查验的是时钟同步和时钟源(clocksource)是否一致，时钟问题对于聚首式数据库来说关系不是很大，然则对于大多量漫步式数据库来说十分关节。
第二步是查验收集是否存在问题，包括网卡故障、PING延时、收集迷糊量、收集丢包、收集流量的平衡性等王人需要柔顺。
第三步是进行各式操作系统资源的分析。对于漫步式数据库而言最初咱们不需要平直下钻到某台劳动器去进行不雅察，而是要不雅察多个平等劳动器节点的资源平衡性。漫步式数据库极容易出问题的所在是资源不平衡，要是一个几十台劳动器节点的漫步式数据库环境中惟一某一个或者某几个劳动器的内存换页严重或者IO延时过高，那么可能会让通盘这个词集群的性能王人受到极大的影响。要是发现不平衡，那么最初要考虑是不是愚弄负载不平衡，或者漫步式实践盘算出现了问题，这些王人是十分常见的。
对于漫步式数据库而言，会话分析也与聚首式数据库不同开yun体育网，会话平衡性、活跃会话平衡性、新增会话平衡性等计较是发现问题的关节，因此针对这些计较，需要常态化积聚。
发布于：北京市