CN116841834A - 状态调节方法和装置、存储介质及电子装置 - Google Patents

Abstract

本申请公开了一种状态调节方法和装置、存储介质及电子装置，上述方法包括：监测数据库的监控指标是否异常，以确定数据库是否处于目标异常状态，其中，监控指标包括以下子监控指标：数据库的第一节点，数据库中的表；在确定数据库处于目标异常状态的情况下，根据监控指标中出现异常的异常子监控指标确定与异常子监控指标对应的调节方式；根据调节方式将数据库从目标异常状态调节至正常状态；采用上述方案，解决了相关技术中，目前已有的Greenplum数据库监控方法只关注了segment节点明确死亡、主/备节点颠倒的情况，未对数据库运行效率不足等亚健康状态进行监测，导致运维人员对数据库状态产生误判的问题。

Description

状态调节方法和装置、存储介质及电子装置

技术领域

本申请涉及通信领域，具体而言，涉及一种状态调节方法和装置、存储介质及电子装置。

背景技术

Greenplum数据库作为一个分布式并行处理数据库，广泛应用于大规模数据仓库分析、商业智能挖掘场景中。在实际运行中，经常会出现数据库运行效率低下、SQL执行慢等亚健康的情况，导致批量作业不能按时完成，最终影响报表生成。

Greenplum数据库包括了多个节点，主要分为2类：master节点和segment节点。master节点不存放任何用户数据，只是对客户端进行访问控制和存储表分布逻辑的元数据；而segment节点负责数据的存储和计算。目前已有的Greenplum数据库监控、故障自愈方法只关注了segment节点死亡、主/备节点颠倒的情况，未对数据库运行效率不足等亚健康状态进行监测，这会导致运维人员对数据库状态出现误判。

针对相关技术中，目前已有的Greenplum数据库监控方法只关注了segment节点明确死亡、主/备节点颠倒的情况，未对数据库运行效率不足等亚健康状态进行监测，导致运维人员对数据库状态产生误判等问题，尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种状态调节方法和装置、存储介质及电子装置，以至少解决相关技术中，目前已有的Greenplum数据库监控方法只关注了segment节点明确死亡、主/备节点颠倒的情况，未对数据库运行效率不足等亚健康状态进行监测，导致运维人员对数据库状态产生误判的问题。

根据本申请实施例的一个实施例，提供了一种状态调节方法，包括：监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

在一个示例性实施例中，监测数据库的监控指标是否异常，包括：通过以下方式对所述第一节点进行监测：从所述数据库的配置文件中获取所述第一节点的地址信息，其中，所述地址信息包括：所述第一节点对应的主机名称，所述第一节点的IP地址；根据所述地址信息访问所述第一节点，以确定所述第一节点是否出现以下异常至少之一：所述第一节点未存活，所述第一节点对应的磁盘故障，所述第一节点出现负载离群。

在一个示例性实施例中，确定所述第一节点是否存活，包括：按照第一预设周期调用第一预设方法，得到探测结果，其中，所述第一预设方法用于探测所述第一节点是否响应；在当前探测结果为目标结果、且与所述当前探测结果相邻的第一数量的探测结果均为所述目标结果的情况下，确定所述第一节点未存活，其中，所述目标结果用于指示所述第一节点未响应。

在一个示例性实施例中，确定所述第一节点对应的磁盘是否故障，包括：按照第二预设周期调用第二预设方法，得到磁盘占用结果，其中，所述磁盘占用结果用于指示所述第一节点对应的磁盘的磁盘占用率；在当前磁盘占用结果所指示的当前磁盘占用率大于第一阈值、且与所述当前磁盘占用结果相邻的第二数量的磁盘占用结果所指示的磁盘占用率均大于所述第一阈值的情况下，将所述磁盘标记为异常磁盘；读取所述异常磁盘的磁盘日志，确定所述磁盘日志中是否包含预设关键字；在确定所述磁盘日志中包含所述预设关键字的情况下，确定所述磁盘故障。

在一个示例性实施例中，确定所述第一节点是否出现负载离群，包括：按照第三预设周期调用第三预设方法，得到所述第一节点在多个时间段内的平均负载；以目标时间段的第一平均负载为标准负载，确定多个所述平均负载中是否存在目标负载，其中，所述目标时间段在所述多个时间段中时间跨度最长，所述目标负载与所述标准负载的差值大于第二阈值；在确定存在所述目标负载的情况下，确定所述第一节点出现负载离群。

在一个示例性实施例中，监测数据库的监控指标是否异常，包括：通过以下方式对所述数据库中的表进行监测：按照第四预设周期调用第四预设方法，以确定所述数据库中的表是否处于锁定状态；根据所述第四预设周期和调用所述第四预设方法的调用次数计算所述数据库中的表处于所述锁定状态的锁定时长；在所述锁定时长大于第三阈值的情况下，确定所述数据库中的表异常。

在一个示例性实施例中，根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态，包括：在确定所述第一节点异常的情况下，调用第一预设脚本将所述第一节点从所述数据库中分离，以将所述数据库从所述目标异常状态调节至正常状态；和/或在确定所述数据库中的表异常的情况下，调用第二预设脚本将目标指令删除，以将所述数据库从所述目标异常状态调节至所述正常状态，其中，所述目标指令用于访问所述数据库中的表。

根据本申请实施例的另一个实施例，还提供了一种状态调节装置，包括：监测模块，用于监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；确定模块，用于在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；调节模块，用于根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

根据本申请实施例的另一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述状态调节方法。

根据本申请实施例的又一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，上述处理器通过计算机程序执行上述的状态调节方法。

在本申请实施例中，通过监测数据库的监控指标是否异常来确定数据库是否处于目标异常状态，其中，监控指标包括以下子监控指标：数据库的第一节点，数据库的表；若确定数据库处于目标异常状态，则根据监控指标中出现异常的异常子监控指标确定与该异常子监控指标对应的调节方式；然后根据确定出的调节方式将数据库从该目标异常状态调节至正常状态；采用上述技术方案，在数据库处于亚健康状态后快速发现并自动处置，将数据库快速恢复至正常状态；从而解决了相关技术中，目前已有的Greenplum数据库监控方法只关注了segment节点明确死亡、主/备节点颠倒的情况，未对数据库运行效率不足等亚健康状态进行监测，导致运维人员对数据库状态产生误判的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请实施例的一种可选的状态调节方法的计算机终端的硬件结构框图；

图2是本申请实施例的一种可选的状态调节方法的流程图；

图3是本申请实施例的一种可选的状态调节系统的结构示意图；

图4是本申请实施例的一种可选的状态调节方法的流程示意图；

图5是根据本申请实施例的一种状态调节装置的结构框图。

具体实施方式

以下对本申请中出现的专业名词进行解释说明：

集群：一个集群通常包含2台master节点和数十台segment节点，一般以集群为单位来处理某一类业务作业，目前共有50多套集群在使用。

Greenplum数据库亚健康状态：Greenplum数据库中的SQL能够执行，但是效率严重不足，运行效率是正常状态下的10％甚至1％。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请实施例所提供的方法实施例可以在计算机终端或者类似的运算系统中执行。以运行在计算机终端上为例，图1是本申请实施例的一种状态调节方法的计算机终端的硬件结构框图。如图1所示，计算机终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理系统)和用于存储数据的存储器104，在一个示例性实施例中，上述计算机终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述计算机终端的结构造成限定。例如，计算机终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示等同功能或比图1所示功能更多的不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本申请实施例中的状态调节方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储系统、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至安全文本。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。

在本实施例中提供了一种状态调节方法，应用于上述计算机终端，图2是根据本申请实施例的一种可选的状态调节方法的流程图，该流程包括如下步骤：

步骤S202，监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；

需要说明的是，上述数据库可以理解为Greenplum数据库，上述第一节点可以理解为segment节点，Greenplum数据库的segment节点主要负责数据的存储和计算，是数据仓库加工作业的主要执行者。理论上segment节点故障后，master节点会探测到该情况，主动将segment节点隔离，并修改gp_segment_configuration系统表。但在实际运维中发现，时常出现segment节点假死的情况，即segment已无法执行SQL，但master却没有发现。

步骤S204，在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；

需要说明的是，上述目标异常状态可以理解为亚健康状态，数据库处于亚健康状态时，会导致数据库运行效率不足。

步骤S206，根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

通过上述步骤，通过监测数据库的监控指标是否异常来确定数据库是否处于目标异常状态，其中，监控指标包括以下子监控指标：数据库的第一节点，数据库的表；若确定数据库处于目标异常状态，则根据监控指标中出现异常的异常子监控指标确定与该异常子监控指标对应的调节方式；然后根据确定出的调节方式将数据库从该目标异常状态调节至正常状态；采用上述技术方案，在数据库处于亚健康状态后快速发现并自动处置，将数据库快速恢复至正常状态；从而解决了相关技术中，目前已有的Greenplum数据库监控方法只关注了segment节点明确死亡、主/备节点颠倒的情况，未对数据库运行效率不足等亚健康状态进行监测，导致运维人员对数据库状态产生误判的问题。

可选的，上述监测步骤S202：监测数据库的监控指标是否异常，可以通过以下步骤来实现，包括：通过以下方式对所述第一节点进行监测：从所述数据库的配置文件中获取所述第一节点的地址信息，其中，所述地址信息包括：所述第一节点对应的主机名称，所述第一节点的IP地址；根据所述地址信息访问所述第一节点，以确定所述第一节点是否出现以下异常至少之一：所述第一节点未存活，所述第一节点对应的磁盘故障，所述第一节点出现负载离群。

对于不同的子监控指标，需要采用不同的方式来监测，对于第一节点(segment节点)而言，可能会出现以下几种异常情况：1、segment节点假死；2、segment节点对应的磁盘出现故障；3、segment节点的CPU出现负载离群点；因此，可以通过以下方式来监测：先从数据库的配置文件中获取所有segment节点的地址信息，地址信息包括segment节点物理服务器的主机名(相当于上述主机名称)和IP地址；然后根据地址信息来访问这些segment节点，来确定segment节点是否出现以下异常情况：segment未存活(即假死)，segment对应的磁盘故障，segment节点的CPU出现负载离群点。

需要说明的是，Greenplum数据库的segment节点主要负责数据的存储和计算，是数据仓库加工作业的主要执行者。理论上segment节点故障后，master节点会探测到该情况，主动将segment节点隔离，并修改gp_segment_configuration系统表。但在实际运维中发现，时常出现segment节点假死的情况，即segment已无法执行SQL，但master却没有发现。

可选的，可以通过以下方案来确定所述第一节点是否存活，包括：按照第一预设周期调用第一预设方法，得到探测结果，其中，所述第一预设方法用于探测所述第一节点是否响应；在当前探测结果为目标结果、且与所述当前探测结果相邻的第一数量的探测结果均为所述目标结果的情况下，确定所述第一节点未存活，其中，所述目标结果用于指示所述第一节点未响应。

具体的，通过以下方案来确定segment节点是否假死：先通过get_host_name()方法去master节点上读取all_host.conf文件(配置文件)的内容，获取该集群所有segment节点物理服务器的主机名、IP地址；根据返回结果分别调用get_survival()方法探测集群内的每一个segment节点是否存活，探测频率为5秒/次，若连续12次探测失败(即探测结果为目标结果)(即连续1分钟segment节点未响应)，则判断该segment节点未存活。

需要说明的是，上述探测频率和探测次数仅用作示例，还可以为其他的数值，本申请对此不作限制。

可选的，可以通过以下方案来确定所述第一节点对应的磁盘是否故障，包括：按照第二预设周期调用第二预设方法，得到磁盘占用结果，其中，所述磁盘占用结果用于指示所述第一节点对应的磁盘的磁盘占用率；在当前磁盘占用结果所指示的当前磁盘占用率大于第一阈值、且与所述当前磁盘占用结果相邻的第二数量的磁盘占用结果所指示的磁盘占用率均大于所述第一阈值的情况下，将所述磁盘标记为异常磁盘；读取所述异常磁盘的磁盘日志，确定所述磁盘日志中是否包含预设关键字；在确定所述磁盘日志中包含所述预设关键字的情况下，确定所述磁盘故障。

Greenplum数据库主要用于处理大数据类业务，在处理该业务的过程中segment节点会频繁对磁盘进行读写操作。正常情况下磁盘IO率不会超过60％，遇到业务量大的情况会偶尔冲高到100％，但只会持续几分钟。只有当磁盘故障时才会因读写性能下降而导致磁盘IO长时间100％。同时，当segment节点的磁盘坏道数目达到一定数量时，linux操作系统会在/var/log/message日志(相当于上述磁盘日志)中写一条包含“reset”关键字(相当于上述预设关键字)的报错日志，该报错日志中会写明故障磁盘的编号。因此，可以通过以下方案来确定segment节点对应的磁盘是否故障：根据地址信息调用get_busy()方法(第二预设方法)去读取segment节点上的磁盘IO情况，频率为2分钟/次(第二预设周期)，若连续15次磁盘IO率均为100％(相当于上述第一阈值)(即连续30分钟磁盘IO率为100％)，则判断该磁盘可能故障(相当于上述异常磁盘)；然后调用get_reset()方法去读取/var/log/message日志，若存在包含reset关键字的日志，则说明该磁盘故障。

需要说明的是，上述频率、磁盘IO率等数值均为示例，在实际应用过程中还可以设置为其他数值，本申请对此不做限制。

可选的，可以通过以下方案来确定所述第一节点是否出现负载离群，包括：按照第三预设周期调用第三预设方法，得到所述第一节点在多个时间段内的平均负载；以目标时间段的第一平均负载为标准负载，确定多个所述平均负载中是否存在目标负载，其中，所述目标时间段在所述多个时间段中时间跨度最长，所述目标负载与所述标准负载的差值大于第二阈值；在确定存在所述目标负载的情况下，确定所述第一节点出现负载离群。

可选的，可以通过以下方案来确定segment节点的CPU是否出现负载离群点：根据地址信息按照第三预设周期来调用get_loadaverage()方法(相当于上述第三预设方法)，来获取segment节点上最近1分钟、5分钟、30分钟的CPU平均负载情况；然后将返回结果作为参数输入get_outlier()方法中，计算当前离群segment的CPU负载是否存在离群点。

具体计算过程可以为：先以30分钟的CPU平均负载情况(第一平均负载)作为标准负载，然后确定每一个1分钟的平均负载中是否存在与标准负载相差大于第二阈值的目标负载，以及确定每一个5分钟的平均负载是否存在与标准负载相差大于第二阈值的目标负载；若确定存在目标负载，则确定segment节点出现负载离群。

可选的，上述步骤S202：监测数据库的监控指标是否异常，还可以通过以下方案来实现，包括：通过以下方式对所述数据库中的表进行监测：按照第四预设周期调用第四预设方法，以确定所述数据库中的表是否处于锁定状态；根据所述第四预设周期和调用所述第四预设方法的调用次数计算所述数据库中的表处于所述锁定状态的锁定时长；在所述锁定时长大于第三阈值的情况下，确定所述数据库中的表异常。

Greenplum数据库在执行增删改等操作时，会锁表以避免出现数据不一致的情况，短时间的锁表情况是正常的，但若长时间锁表则会影响其他批量作业的运行。因此，对于数据库的表这一子监控指标，可以通过以下方式来监测：每隔5分钟(相当于上述第四预设周期)调用一次get_lock()方法(相当于上述第四预设方法)，去检查Greenplum数据库中的锁表情况，根据调用频率和调用次数来计算锁表时长(相当于上述锁定时长)若发现某一SQL锁表超过2小时(相当于上述第三阈值)，则确定该表锁定异常。

需要说明的是，上述“5分钟”、“2小时”等数据仅用作示例，还可以为其他的数据，本申请对此不作限制。

基于上述步骤，根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态，包括：在确定所述第一节点异常的情况下，调用第一预设脚本将所述第一节点从所述数据库中分离，以将所述数据库从所述目标异常状态调节至正常状态；和/或在确定所述数据库中的表异常的情况下，调用第二预设脚本将目标指令删除，以将所述数据库从所述目标异常状态调节至所述正常状态，其中，所述目标指令用于访问所述数据库中的表。

在确定子监控指标异常后，通过以下方法来将数据库从目标异常状态调节至正常状态：若确定segment节点异常(即出现第一节点未存活、第一节点对应的磁盘故障、第一节点出现负载离群中至少一个异常情况)，则调用host_shutdown()脚本(相当于上述第一预设脚本)将对应的segment节点隔离出数据库；若确定数据库的表异常，则调用SQL_kill()脚本(相当于上述第二预设脚本)将对应的SQL(相当于上述目标指令)杀死。

可选的，上述状态调节方法可以应用于如图3所示的状态调节系统中，如图3所示，该状态调节系统包括：监控模块32、处置模块34；

其中，监控模块32包括以下监控子模块：segment节点存活探测302、磁盘busy检查304、CPU负载离群点计算306、SQL锁表超时308；在监测到segment节点异常时，监控模块会将该segment节点的主机名发送给处置模块；在监测到SQL锁表超时时，监控模块会将对应的SQL语句、PID发送给处置模块；

处置模块34主要用于接收监控模块发送过来的数据库Greenplum故障信息，并根据故障信息内容进行对应的处置。具体处置流程如下：

1、如果是segment存活探测302、磁盘busy检查304、CPU负载离群点计算306这三个子模块传过来的信息，则说明是硬件故障，会调用host_shutdown脚本将对应的segment节点隔离出数据库，然后将主机名通过告警发出，通知运维人员；

2、如果是SQL锁表超时308子模块传过来的信息，则说明是SQL异常问题，会调用SQL_kill()脚本，将对应的SQL杀死，然后将SQL通过告警发出，通知运维人员。

通过上述系统，新增了segment存活探测、磁盘busy检查、CPU负载离群点计算、SQL锁表超时等监测机制，在亚健康状态发生后快速发现并自动处置，隔离异常segment节点或终止异常SQL，将数据库快速恢复至正常状态，并通过告警短信通知运维人员；从而能够更加准确的监控Greenplum数据库的运行状态。

上述状态调节系统的运作流程可以如图4所示，图4是本申请实施例的一种可选的状态调节方法的流程示意图，具体包括以下步骤：

步骤S401：监控模块32发送数据库故障信息；

步骤S402：根据数据库故障信息判断数据库故障类型，若故障类型为segment节点异常导致，则执行步骤S403；若故障类型为SQL异常导致，则执行步骤S404；

步骤S403：调用host_shutdown()脚本隔离异常节点；

步骤S404：调用SQL_kill()脚本杀死异常SQL；

步骤S405：发送告警信息，通知运维人员。

通过上述步骤，通过处置模块在数据库处于亚健康状态时自动处置，减少Greenplum数据库的故障时间，同时减少了运维工程师处置时的人力成本。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例的方法。

图5是根据本申请实施例的一种状态调节装置的结构框图；如图5所示，包括：

监测模块52，用于监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；

确定模块54，用于在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；

调节模块56，用于根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

通过上述装置，通过监测数据库的监控指标是否异常来确定数据库是否处于目标异常状态，其中，监控指标包括以下子监控指标：数据库的第一节点，数据库的表；若确定数据库处于目标异常状态，则根据监控指标中出现异常的异常子监控指标确定与该异常子监控指标对应的调节方式；然后根据确定出的调节方式将数据库从该目标异常状态调节至正常状态；采用上述技术方案，在数据库处于亚健康状态后快速发现并自动处置，将数据库快速恢复至正常状态；从而解决了相关技术中，目前已有的Greenplum数据库监控方法只关注了segment节点明确死亡、主/备节点颠倒的情况，未对数据库运行效率不足等亚健康状态进行监测，导致运维人员对数据库状态产生误判的问题。

在一个示例性实施例中，上述监测模块52，还用于从所述数据库的配置文件中获取所述第一节点的地址信息，其中，所述地址信息包括：所述第一节点对应的主机名称，所述第一节点的IP地址；根据所述地址信息访问所述第一节点，以确定所述第一节点是否出现以下异常至少之一：所述第一节点未存活，所述第一节点对应的磁盘故障，所述第一节点出现负载离群。

对于不同的子监控指标，需要采用不同的方式来监测，对于第一节点(segment节点)而言，可能会出现以下几种异常情况：1、segment节点假死；2、segment节点对应的磁盘出现故障；3、segment节点的CPU出现负载离群点；因此，可以通过以下方式来监测：先从数据库的配置文件中获取所有segment节点的地址信息，地址信息包括segment节点物理服务器的主机名(相当于上述主机名称)和IP地址；然后根据地址信息来访问这些segment节点，来确定segment节点是否出现以下异常情况：segment未存活(即假死)，segment对应的磁盘故障，segment节点的CPU出现负载离群点。

在一个示例性实施例中，上述监测模块52，还用于按照第一预设周期调用第一预设方法，得到探测结果，其中，所述第一预设方法用于探测所述第一节点是否响应；在当前探测结果为目标结果、且与所述当前探测结果相邻的第一数量的探测结果均为所述目标结果的情况下，确定所述第一节点未存活，其中，所述目标结果用于指示所述第一节点未响应。

具体的，通过以下方案来确定segment节点是否假死：先通过get_host_name()方法去master节点上读取all_host.conf文件(配置文件)的内容，获取该集群所有segment节点物理服务器的主机名、IP地址；根据返回结果分别调用get_survival()方法探测集群内的每一个segment节点是否存活，探测频率为5秒/次，若连续12次探测失败(即探测结果为目标结果)(即连续1分钟segment节点未响应)，则判断该segment节点未存活。

需要说明的是，上述探测频率和探测次数仅用作示例，还可以为其他的数值，本申请对此不作限制。

在一个示例性实施例中，上述监测模块52，还用于按照第二预设周期调用第二预设方法，得到磁盘占用结果，其中，所述磁盘占用结果用于指示所述第一节点对应的磁盘的磁盘占用率；在当前磁盘占用结果所指示的当前磁盘占用率大于第一阈值、且与所述当前磁盘占用结果相邻的第二数量的磁盘占用结果所指示的磁盘占用率均大于所述第一阈值的情况下，将所述磁盘标记为异常磁盘；读取所述异常磁盘的磁盘日志，确定所述磁盘日志中是否包含预设关键字；在确定所述磁盘日志中包含所述预设关键字的情况下，确定所述磁盘故障。

Greenplum数据库主要用于处理大数据类业务，在处理该业务的过程中segment节点会频繁对磁盘进行读写操作。正常情况下磁盘IO率不会超过60％，遇到业务量大的情况会偶尔冲高到100％，但只会持续几分钟。只有当磁盘故障时才会因读写性能下降而导致磁盘IO长时间100％。同时，当segment节点的磁盘坏道数目达到一定数量时，linux操作系统会在/var/log/message日志(相当于上述磁盘日志)中写一条包含“reset”关键字(相当于上述预设关键字)的报错日志，该报错日志中会写明故障磁盘的编号。因此，可以通过以下方案来确定segment节点对应的磁盘是否故障：根据地址信息调用get_busy()方法(第二预设方法)去读取segment节点上的磁盘IO情况，频率为2分钟/次(第二预设周期)，若连续15次磁盘IO率均为100％(相当于上述第一阈值)(即连续30分钟磁盘IO率为100％)，则判断该磁盘可能故障(相当于上述异常磁盘)；然后调用get_reset()方法去读取/var/log/message日志，若存在包含reset关键字的日志，则说明该磁盘故障。

需要说明的是，上述频率、磁盘IO率等数值均为示例，在实际应用过程中还可以设置为其他数值，本申请对此不做限制。

在一个示例性实施例中，上述监测模块52，还用于按照第三预设周期调用第三预设方法，得到所述第一节点在多个时间段内的平均负载；以目标时间段的第一平均负载为标准负载，确定多个所述平均负载中是否存在目标负载，其中，所述目标时间段在所述多个时间段中时间跨度最长，所述目标负载与所述标准负载的差值大于第二阈值；在确定存在所述目标负载的情况下，确定所述第一节点出现负载离群。

可选的，可以通过以下方案来确定segment节点的CPU是否出现负载离群点：根据地址信息按照第三预设周期来调用get_loadaverage()方法

(相当于上述第三预设方法)，来获取segment节点上最近1分钟、5分钟、30分钟的CPU平均负载情况；然后将返回结果作为参数输入get_outlier()方法中，计算当前离群segment的CPU负载是否存在离群点。

具体计算过程可以为：先以30分钟的CPU平均负载情况(第一平均负载)作为标准负载，然后确定每一个1分钟的平均负载中是否存在与标准负载相差大于第二阈值的目标负载，以及确定每一个5分钟的平均负载是否存在与标准负载相差大于第二阈值的目标负载；若确定存在目标负载，则确定segment节点出现负载离群。

在一个示例性实施例中，上述监测模块52，还用于通过以下方式对所述数据库中的表进行监测：按照第四预设周期调用第四预设方法，以确定所述数据库中的表是否处于锁定状态；根据所述第四预设周期和调用所述第四预设方法的调用次数计算所述数据库中的表处于所述锁定状态的锁定时长；在所述锁定时长大于第三阈值的情况下，确定所述数据库中的表异常。

Greenplum数据库在执行增删改等操作时，会锁表以避免出现数据不一致的情况，短时间的锁表情况是正常的，但若长时间锁表则会影响其他批量作业的运行。因此，对于数据库的表这一子监控指标，可以通过以下方式来监测：每隔5分钟(相当于上述第四预设周期)调用一次get_lock()方法(相当于上述第四预设方法)，去检查Greenplum数据库中的锁表情况，根据调用频率和调用次数来计算锁表时长(相当于上述锁定时长)若发现某一SQL锁表超过2小时(相当于上述第三阈值)，则确定该表锁定异常。

需要说明的是，上述“5分钟”、“2小时”等数据仅用作示例，还可以为其他的数据，本申请对此不作限制。

在一个示例性实施例中，所述调节模块56，还用于在确定所述第一节点异常的情况下，调用第一预设脚本将所述第一节点从所述数据库中分离，以将所述数据库从所述目标异常状态调节至正常状态；和/或在确定所述数据库中的表异常的情况下，调用第二预设脚本将目标指令删除，以将所述数据库从所述目标异常状态调节至所述正常状态，其中，所述目标指令用于访问所述数据库中的表。

在确定子监控指标异常后，通过以下方法来将数据库从目标异常状态调节至正常状态：若确定segment节点异常(即出现第一节点未存活、第一节点对应的磁盘故障、第一节点出现负载离群中至少一个异常情况)，则调用host_shutdown()脚本(相当于上述第一预设脚本)将对应的segment节点隔离出数据库；若确定数据库的表异常，则调用SQL_kill()脚本(相当于上述第二预设脚本)将对应的SQL(相当于上述目标指令)杀死。

本申请的实施例还提供了一种存储介质，该存储介质包括存储的程序，其中，上述程序运行时执行上述任一项的方法。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：

S1，监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；

S2，在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；

S3，根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。

本申请的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；

S2，在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；

S3，根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算系统来实现，它们可以集中在单个的计算系统上，或者分布在多个计算系统所组成的网络上，可选地，它们可以用计算系统可执行的程序代码来实现，从而，可以将它们存储在存储系统中由计算系统来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种状态调节方法，其特征在于，包括：

监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；

在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；

根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

2.根据权利要求1所述的状态调节方法，其特征在于，监测数据库的监控指标是否异常，包括：

通过以下方式对所述第一节点进行监测：

从所述数据库的配置文件中获取所述第一节点的地址信息，其中，所述地址信息包括：所述第一节点对应的主机名称，所述第一节点的IP地址；

根据所述地址信息访问所述第一节点，以确定所述第一节点是否出现以下异常至少之一：所述第一节点未存活，所述第一节点对应的磁盘故障，所述第一节点出现负载离群。

3.根据权利要求2所述的状态调节方法，其特征在于，确定所述第一节点是否存活，包括：

按照第一预设周期调用第一预设方法，得到探测结果，其中，所述第一预设方法用于探测所述第一节点是否响应；

在当前探测结果为目标结果、且与所述当前探测结果相邻的第一数量的探测结果均为所述目标结果的情况下，确定所述第一节点未存活，其中，所述目标结果用于指示所述第一节点未响应。

4.根据权利要求2所述的状态调节方法，其特征在于，确定所述第一节点对应的磁盘是否故障，包括：

按照第二预设周期调用第二预设方法，得到磁盘占用结果，其中，所述磁盘占用结果用于指示所述第一节点对应的磁盘的磁盘占用率；

在当前磁盘占用结果所指示的当前磁盘占用率大于第一阈值、且与所述当前磁盘占用结果相邻的第二数量的磁盘占用结果所指示的磁盘占用率均大于所述第一阈值的情况下，将所述磁盘标记为异常磁盘；

读取所述异常磁盘的磁盘日志，确定所述磁盘日志中是否包含预设关键字；

在确定所述磁盘日志中包含所述预设关键字的情况下，确定所述磁盘故障。

5.根据权利要求2所述的状态调节方法，其特征在于，确定所述第一节点是否出现负载离群，包括：

按照第三预设周期调用第三预设方法，得到所述第一节点在多个时间段内的平均负载；

以目标时间段的第一平均负载为标准负载，确定多个所述平均负载中是否存在目标负载，其中，所述目标时间段在所述多个时间段中时间跨度最长，所述目标负载与所述标准负载的差值大于第二阈值；

在确定存在所述目标负载的情况下，确定所述第一节点出现负载离群。

6.根据权利要求2所述的状态调节方法，其特征在于，监测数据库的监控指标是否异常，包括：

通过以下方式对所述数据库中的表进行监测：

按照第四预设周期调用第四预设方法，以确定所述数据库中的表是否处于锁定状态；

根据所述第四预设周期和调用所述第四预设方法的调用次数计算所述数据库中的表处于所述锁定状态的锁定时长；

在所述锁定时长大于第三阈值的情况下，确定所述数据库中的表异常。

7.根据权利要求1至6任一项中所述的状态调节方法，其特征在于，根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态，包括：

在确定所述第一节点异常的情况下，调用第一预设脚本将所述第一节点从所述数据库中分离，以将所述数据库从所述目标异常状态调节至正常状态；和/或

在确定所述数据库中的表异常的情况下，调用第二预设脚本将目标指令删除，以将所述数据库从所述目标异常状态调节至所述正常状态，其中，所述目标指令用于访问所述数据库中的表。

8.一种状态调节装置，其特征在于，包括：

监测模块，用于监测数据库的监控指标是否异常，以确定所述数据库是否处于目标异常状态，其中，所述监控指标包括以下子监控指标：所述数据库的第一节点，所述数据库中的表；

确定模块，用于在确定所述数据库处于所述目标异常状态的情况下，根据所述监控指标中出现异常的异常子监控指标确定与所述异常子监控指标对应的调节方式；

调节模块，用于根据所述调节方式将所述数据库从所述目标异常状态调节至正常状态。

9.一种计算机可读的存储介质，其特征在于，所述计算机可读的存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1至7任一项中所述的方法。

10.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至7任一项中所述的方法。