草庐IT

一篇读懂分布式数据库的健康评估

白鳝 2023-03-28 原文
​前阵子和一个做数据库服务的朋友交流，他们承接了某个企业的国产分布式数据库的运维工作，安排了一个该数据库的认证工程师驻场做服务，不过从半年的工作情况来看，效果并不好。作为分布式数据库的运维，平时小问题也不需要DBA介入，分布式数据库的故障自愈能力能够很好的屏蔽这些小问题，并且能够在短时间内完成自愈。如果真的出了大问题，DBA面对数十个节点的分布式数据库环境又束手无策，很难定位问题，这种情况让他们感到很困惑。

实际上这个问题还是挺复杂的，涉及到分布式数据库这种典型的分布式系统与集中式数据库之间在架构与功能上的巨大差异。在传统的数据库运维上，我们习惯于查看一些指标，例如CPU负载，锁超时，活跃会话数、错误率等。对于分布式数据库来说，这些指标实际上并没有相对于集中式数据库环境那么重要，因为分布式数据库从体系架构上具有极高的容错能力。数据库的某个物理节点、某个服务、某个分区、某个副本都可以出故障，此时数据库内部虽然已经存在故障，但是你一点都不需要为此担心，数据库依然能够很好的对外提供服务。这些指标实际上都没有正确的反映出数据库是否能够为客户端流量提供正常的服务，而这些才是用户需要关注的。

在“具有动态纠错能力”并且“可以自动扩展、动态负载均衡”的分布式数据库中，如果单个服务无法实现完整的数据库功能，那么单个服务是否处于“启动”或者“活跃”状态并不重要，因为这些很可能都不会影响分布式数据库对外提供服务，这使得像ping延时、CPU使用率这样的简单检查几乎毫无用处。虽然利用传统的监控理念，判断某个服务是否宕掉并不复杂，但要确定处于活动状态的数据库服务是否健康要困难得多。

也可以通过一些比较简单的方式来判断分布式数据库的服务是否正常。服务很有可能处于“启动”状态，并且并能够对外提供数据库服务，但是它无法在服务的 99分位延迟内完成给定的工作任务（比如完成一条标准SQL的执行），那么这个数据库就是不健康的。

对于分布式数据库来说，无法在P99延时内执行完某条SQL，但是数据库服务还是能承接相关业务的，这种情况是比较常见的故障场景，也是我们的DBA面对的束手无策的常见场景。这种场景大多数情况下与数据库的某些组件流量过载有关，在高并发服务中，“高并发的重负载”会在分布式数据库中受到某些串行化机制的影响，正常情况下，通过资源管理器与队列机制有序的排序。但是如果某个组件出现过载，那么队列会产生溢出，这可能导致 RPC 调用的延迟增加。一般情况下遇到这种情况，下游服务将简单地使请求超时并进行重试，这种机制将会导致高负载情况下出现分布式系统的效率下降的问题，此时分布式数据库的总体性能会有所下降。而如果此时叠加一些其他的因素，比如某块硬盘的IO延时过大、某个网卡出现丢包、某个节点的操作系统出现严重换页，那么整个分布式数据库环境就有可能出现了正常的处理逻辑无法承受的临界状态，再叠加上数据库本身就存在的一些对此类情况处理不周的BUG，那么数据库出现严重的问题，甚至出现无法对外提供服务的情况，也是必然的。

而且分布式数据库一旦进入这样的状态，要想通过自身的容错能力与资源调度能力恢复系统运行，那就不是秒钟级甚至分钟级能够完成的了。此时最好的方法应该是彻底关闭数据库系统，解决掉出现问题的根源问题，然后重新启动数据库。但是对于分布式数据库这种大型系统而言，在出现故障的时候关闭数据库在大多数场景中也是不现实的。因此我们只有退而求其次，降低数据库当前的复杂，解决掉故障问题是退而求其次的解决方案。如果这个方法还是无法执行，那么就只能先解决掉导致问题的故障，再慢慢等着系统恢复了。

综上所述，分布式数据库的某个服务在其生命周期中很可能在不同程度的“健康状态”之间波动，从完全正常，能够以预期的并发级别运行下降到接近不正常，此时可能某些高负载导致某的队列溢出，如果问题持续恶化，数据库将进入“不正常”状态，此时数据库服务质量大幅下降。对于分布式数据库而言，自适应、自我修复的能力在大部分情况下可以自动处理这种波动，并力求自动恢复。可惜的是这种最佳预期并不总是在生产环境中得以实现，分布式数据库可能存在某些BUG；而高并发负载的持续时间可能超出硬件的能力范围；面包掉在地上黄油朝下的概率也极高。因此分布式数据库可以解决一切集中式数据库运维中的问题，达到极高的可用性的说法并不成立。

对于分布式数据库运维来说，小问题无需介入，大问题介入不了是一种常态。其最主要的问题还是我们无法对分布式数据库的健康状态有一个十分准确的评估。如果我们能够了解分布式数据库的内部状态，并提前做出预警，那么很多故障还是可以避免的。比如负载过高达到硬件资源极限可以通过切断部分流量来实现快速恢复。而如果能够在问题发生的更早期介入，数据库的恢复时间也会缩短很多。

比较麻烦的是，分布式数据库的健康评估是比较复杂的，对于分布式数据库来说，健康评估更像是一个布鲁姆过滤器。你发现数据库有问题，那么数据库肯定有问题。但是如果你检查数据库的状态是健康的，那么数据库仅仅是“可能处于健康状态”，我们必须通过其他的因素来确认其实健康的。

基于上面的认知，我们觉得针对分布式数据库的健康度需要从几个方面来做综合评估，传统的指标当然还是需要的，我们需要从操作系统负载与性能、数据库负载、数据库并发、集群与网络、负载均衡度、数据库容量等数个方面进行评估。

除此之外针对分布式数据库，我们还需要引入新的评估要素，那就是数据库功能的健康度评估，简单查询、简单写入、全表扫描、索引扫描、并行扫描、DDL操作等多种数据库业务的响应时间是否合理（比如是否超出P99延时），不同计算节点执行相同的简单操作的延时是否均衡等，也应该作为健康评估的内容。必须如此，才能解决分布式数据库健康评估的“布鲁姆过滤器陷阱”。

仅仅实现准确的健康评估还不足够，更重要的是发现健康问题之后还需要能够进行问题溯源与解决方案分析。要想实现这一点，必须从两个方面做监控的增强。一方面是更加准确与全面的采集分布式数据库的指标，并能够高效的进行异常检测，从而能够全面的发现数据库指标的异常；另外一方面是能够快速的积累故障模型，构建常见故障的分析诊断与应急处置的标准化方法。

比如上面是某国产分布式数据库的一个故障场景，该场景会导致业务响应变慢。只要拥有充分的指标数据，通过规则引擎很容易描述出其中的场景，并形成自动化分析与诊断的工具。一切恐惧都来自于未知，正是因为我们对国产分布式数据库的运维经验积累还不充分，才导致了遇到问题时的手足无措。二十多年前，我们面对Oracle数据库的时候，也是如此的，随着应用场景的丰富以及运维经验被不断的积累，这些问题都会慢慢好起来的。​

一篇篇读的数据据库数据库其他数据库$分布式评估

有关一篇读懂分布式数据库的健康评估的更多相关文章

  1. ruby - 解析 RDFa、微数据等的最佳方式是什么，使用统一的模式/词汇(例如 schema.org)存储和显示信息 - 2

    我主要使用Ruby来执行此操作，但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式，例如使用这个yaml文件，它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i

  2. ruby - Ruby 有 `Pair` 数据类型吗？ - 2

    有时我需要处理键/值数据。我不喜欢使用数组，因为它们在大小上没有限制(很容易不小心添加超过2个项目，而且您最终需要稍后验证大小)。此外，0和1的索引变成了魔数(MagicNumber)，并且在传达含义方面做得很差(“当我说0时，我的意思是head...”)。散列也不合适，因为可能会不小心添加额外的条目。我写了下面的类来解决这个问题:classPairattr_accessor:head,:taildefinitialize(h,t)@head,@tail=h,tendend它工作得很好并且解决了问题，但我很想知道:Ruby标准库是否已经带有这样一个类？ 最佳

  3. ruby - 分布式事务和队列，ruby，erlang，scala - 2

    我有一个涉及多台机器、消息队列和事务的问题。因此，例如用户点击网页，点击将消息发送到另一台机器，该机器将付款添加到用户的帐户。每秒可能有数千次点击。事务的所有方面都应该是容错的。我以前从未遇到过这样的事情，但一些阅读表明这是一个众所周知的问题。所以我的问题。我假设安全的方法是使用两阶段提交，但协议(protocol)是阻塞的，所以我不会获得所需的性能，我是否正确？我通常写Ruby，但似乎Redis之类的数据库和Rescue、RabbitMQ等消息队列系统对我的帮助不大——即使我实现某种两阶段提交，如果Redis崩溃，数据也会丢失，因为它本质上只是内存。所有这些让我开始关注erlang和

  4. ruby - 我如何添加二进制数据来遏制 POST - 2

    我正在尝试使用Curbgem执行以下POST以解析云curl-XPOST\-H"X-Parse-Application-Id:PARSE_APP_ID"\-H"X-Parse-REST-API-Key:PARSE_API_KEY"\-H"Content-Type:image/jpeg"\--data-binary'@myPicture.jpg'\https://api.parse.com/1/files/pic.jpg用这个:curl=Curl::Easy.new("https://api.parse.com/1/files/lion.jpg")curl.multipart_form_

  5. 世界前沿3D开发引擎HOOPS全面讲解——集3D数据读取、3D图形渲染、3D数据发布于一体的全新3D应用开发工具 - 2

    无论您是想搭建桌面端、WEB端或者移动端APP应用，HOOPSPlatform组件都可以为您提供弹性的3D集成架构，同时，由工业领域3D技术专家组成的HOOPS技术团队也能为您提供技术支持服务。如果您的客户期望有一种在多个平台（桌面/WEB/APP，而且某些客户端是“瘦”客户端）快速、方便地将数据接入到3D应用系统的解决方案，并且当访问数据时，在各个平台上的性能和用户体验保持一致，HOOPSPlatform将帮助您完成。利用HOOPSPlatform，您可以开发在任何环境下的3D基础应用架构。HOOPSPlatform可以帮您打造3D创新型产品，HOOPSSDK包含的技术有：快速且准确的CAD

  6. FOHEART H1数据手套驱动Optitrack光学动捕双手运动(Unity3D) - 2

    本教程将在Unity3D中混合Optitrack与数据手套的数据流，在人体运动的基础上，添加双手手指部分的运动。双手手背的角度仍由Optitrack提供，数据手套提供双手手指的角度。 01  客户端软件分别安装MotiveBody与MotionVenus并校准人体与数据手套。MotiveBodyMotionVenus数据手套使用、校准流程参照：https://gitee.com/foheart_1/foheart-h1-data-summary.git02  数据转发打开MotiveBody软件的Streaming，开始向Unity3D广播数据；MotionVenus中设置->选项选择Unit

  7. 使用canal同步MySQL数据到ES - 2

    文章目录一、概述简介原理模块二、配置Mysql使用版本环境要求1.操作系统2.mysql要求三、配置canal-server离线下载在线下载上传解压修改配置单机配置集群配置分库分表配置1.修改全局配置2.实例配置垂直分库水平分库3.修改group-instance.xml4.启动监听四、配置canal-adapter1修改启动配置2配置映射文件3启动ES数据同步查询所有订阅同步数据同步开关启动4.验证五、配置canal-admin一、概述简介canal是Alibaba旗下的一款开源项目，Java开发。基于数据库增量日志解析，提供增量数据订阅&消费。Git地址：https://github.co

  8. ruby-on-rails - 创建 ruby​​ 数据库时惰性符号绑定(bind)失败 - 2

    我正在尝试在Rails上安装ruby​​，到目前为止一切都已安装，但是当我尝试使用rakedb:create创建数据库时，我收到一个奇怪的错误:dyld:lazysymbolbindingfailed:Symbolnotfound:_mysql_get_client_infoReferencedfrom:/Library/Ruby/Gems/1.8/gems/mysql2-0.3.11/lib/mysql2/mysql2.bundleExpectedin:flatnamespacedyld:Symbolnotfound:_mysql_get_client_infoReferencedf

  9. STM32读取串口传感器数据（颗粒物传感器，主动上传） - 2

    文章目录1.开发板选择*用到的资源2.串口通信（个人理解）3.代码分析（注释比较详细）1.主函数2.串口1配置3.串口2配置以及中断函数4.注意问题5.源码链接1.开发板选择我用的是STM32F103RCT6的板子，不过代码大概在F103系列的板子上都可以运行，我试过在野火103的霸道板上也可以，主要看一下串口对应的引脚一不一样就行了，不一样的就更改一下。*用到的资源keil5软件这里用到了两个串口资源，采集数据一个，串口通信一个，板子对应引脚如下：串口1，TX：PA9，RX：PA10串口2，TX：PA2，RX：PA32.串口通信（个人理解）我就从串口采集传感器数据这个过程说一下我自己的理解，

  10. SPI接收数据异常问题总结 - 2

    SPI接收数据左移一位问题目录SPI接收数据左移一位问题一、问题描述二、问题分析三、探究原理四、经验总结最近在工作在学习调试SPI的过程中遇到一个问题——接收数据整体向左移了一位（1bit）。SPI数据收发是数据交换，因此接收数据时从第二个字节开始才是有效数据，也就是数据整体向右移一个字节（1byte）。请教前辈之后也没有得到解决，通过在网上查阅前人经验终于解决问题，所以写一个避坑经验总结。实际背景：MCU与一款芯片使用spi通信，MCU作为主机，芯片作为从机。这款芯片采用的是它规定的六线SPI，多了两根线：RDY和INT，这样从机就可以主动请求主机给主机发送数据了。一、问题描述根据从机芯片手

随机推荐