昨天在南京举办了分布式数据库运维与优化沙龙。关于分布式数据库的运维，遇到一个朋友说现在很头疼。分布式数据库是小问题不需要运维，大问题是运维人员解决不了的。这让他觉得，请外包的DBA不划算，不请也觉得不放心，用不起原厂。目前的情况是，很多公司已经开始使用分布式数据库，也有一些公司在观望，不敢马上入坑。他们担心的主要是运维问题。运维领域有一句名言，“运维最大的困难在于未知”。这句话包含了多层次的含义：数据库运行状态未知；未知的技术；未知的可能遇到的问题。这些未知数的聚集就是恐惧。我们从foxpro转大数据库再转oracle的时候，也遇到过这样的时期。当时出现了几次大问题，几次大问题之后，很多公司都想回到简单的不需要运维的foxpro。.与我们熟悉的中心化数据库相比，分布式数据库就像一个巨大的史前生物，神秘、未知、令人生畏。用过分布式数据库的朋友都知道，分布式数据库在组成和结构上都比较复杂。甚至国内的一些分布式数据库也是由几十个不同的开源组件组成的。仅仅是安装部署，就需要学习ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、Prometheus等大型开源组件来完成。不过有朋友说分布式数据库的运维其实没有那么复杂。运行过程中遇到的软硬件故障，大部分都会由分布式数据库自动处理，不需要运维人员的干预。说实话，有一说一。在分布式数据库中处理小问题更容易。数据库本身的高可用可以自动避免一些小问题。但是，分布式数据库最怕出大问题，最怕不知道怎么处理。在分布式数据库中，我最害怕遇到两件事。一是后台自动任务在维护窗口还没有运行完，不敢轻易停止。另外一个就是一个大query好像总是没完没了，不敢kill掉重新来过。遇到这种事，我们也无能为力。我们既不能killsession，也不敢重启数据库。以往在中心化数据库运维中的利器，似乎都派不上用场了。在这种情况下，未知带来的恐惧是运维中最大的问题。因恐惧而采取错误的措施，导致灾难性的后果，是运维中最难以忍受的。因此，我们需要对分布式数据库产品有更深入的了解，为分布式数据库产品的运维探索一些新的思路。既然未知是最大的难点，那么把未知变成已知，甚至是已知，是解决分布式数据库运维的一个非常重要的措施。我们看到国内很多分布式数据库都开始关注其可观察性。它们不仅提供了大量的运行指标和等待事件，还提供了一些接口，比如ASH，全面跟踪SQL执行状态。这些接口正在不断改进。虽然数据库提供了一些可观察性接口，但是如果我们不知道如何使用它是没有用的。因此，我们需要构建分布式数据库的可观察接口的收集和分析能力。与中心化数据库不同，分布式数据库是多节点、多分区、多租户的，计算节点和存储节点都是分布式的。它的指标体系非常复杂。比如一个简单的参数“IOreadqueuedelay”，就是关于数据库读磁盘时的AIO队列延迟。在分布式数据库中，这个索引有一个详细的列表，比如每个服务、每个租户都有一个索引。我们在分析这些指标的时候，直接使用详细的指标是不方便的。我们还需要构造一组统计数据，比如最大值、最小值、标准差、平均值等，在分析的时候，也需要对这些统计数据进行分析，而不仅仅是分析原始数据。这将导致本已复杂的指标体系变得更加复杂，更难以手动监控。因此，对于分布式数据库的运维监控，必须构建自动化系统。否则，即使是专家，在遇到一些没有见过的问题时，也难以完成快速分析和问题定位。分布式数据库中监控指标体系的构建非常复杂。上图是一个分布式思维指标体系的组成示意图。只有完成了这样的指标体系，才能进行分布式数据库的健康管理。仅有原始指标是不够的，我们必须了解指标背后的含义。因此，我们需要构建分布式数据库索引系统的知识图谱。比如上面提到的加强bufferhitrate指标关联的问题，涉及到很多方面。在构建知识图谱时，必须考虑主次因素、直接关系和间接关系。这样在分析问题的时候可以找到更多的推导路径。这些知识的来源主要是原厂文档、专家运维知识、运维案例，甚至是开源数据库的源代码。因为目前我们国内数据库的数据和运维案例都比较匮乏，运维经验的积累并不容易。但是这个工作是必须要进行的，否则当国产数据库大规模应用的时候，就会蒙蔽双眼。最后分享一下分布式数据库运维中的一些常见问题。首先，分布式数据库本身的高可用架构会屏蔽一定的故障。因此，对于分布式数据库来说，某个组件的故障是最容易处理的。隔离故障硬件，修复它并重新加入集群。最怕的就是硬件不稳定，有起有落。比如某个网口一会儿up一会儿down，有没有丢包。这种情况很可能导致分布式数据库的严重故障。不过这个问题如果能尽早发现，尽早停止网口，对数据库的影响会很小。硬盘故障也是如此，尤其是多路径故障，很容易导致时好时坏。这个时候IO读写变得很不稳定，这个节点就会变得不稳定，可能会导致整个数据库出现问题。对于硬件故障，网络故障对分布式数据库的影响是综合性的。网络延迟、网络丢包等偶尔增加，可能会导致分布式数据库性能抖动，甚至导致主从副本错误切换，从而造成更大的毛刺。保证分布式数据库的网络带宽和网络延迟在一个合理的范围内，网络带宽不会出现瓶颈是非常重要的。不平衡的集群数据分布和负载分布也可能导致分布式数据库的严重故障。当某个节点出现资源瓶颈时，这种影响可能会导致大规模故障。因此，在节点资源的监控中，一旦发现一些节点资源瓶颈长期存在，需要尽快排查，避免出现重大故障。分布式数据库慢SQL分析也很关键。发现慢SQL，了解分布式执行计划，发现执行计划中的问题，是分布式数据库运维DBA的日常工作。如果发现在某个节点上并行执行比较慢，那么就需要对某个节点进行分析，排除隐患。对于企业和DBA来说，分布式数据库的运维处于初级阶段，相关的运维知识、故障案例、专家经验都比较匮乏。数据库厂商也有义务将这些资料整理出来发布在自己的管网上，让大家在遇到运维问题时有参考依据。我们也希望一些使用同款数据库产品的公司也能建立朋友圈，分享自己在这方面的经验，尽快打通运维知识和能力上的这个鸿沟。原文地址：https://mp.weixin.qq.com/s/yDIodMTdZz-iLytX6uOY0g
