数据库的故障诊断方法、装置、主机及存储介质与流程

1.本公开实施例涉及数据库技术领域，尤其涉及一种数据库的故障诊断方法、装置、主机及存储介质。


背景技术：

2.针对数据库经常出现的不可用的问题，相关技术一般采用容器内部搜集内存和磁盘性能指标的方式或者探活数据库端口的方式实现对数据库的故障检测。
3.但是，由于搜集性能指标的方式，不但要在容器内部搜集内存和磁盘的性能指标，还需要将搜集到的性能指标发送给数据库外部的主机，因而，存在故障检测效率低的问题，并且如果网络发生故障，那么搜集到的性能指标可能无法及时发送给外部的主机，导致外部主机无法及时发现数据库故障的问题；另外，探活数据库端口的方式一般在发现数据库端口不通时，就会第一时间发起修复过程，但是这时的端口不通可能是由网络问题导致的，存在误检的问题。


技术实现要素：

4.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开实施例提供了一种数据库的故障诊断方法、装置、主机及存储介质。
5.本公开实施例第一方面提供了一种数据库的故障诊断方法，该方法包括：向数据库发送访问请求，以使数据库根据接收到的访问请求，访问数据库的系统表并生成访问请求反馈消息；若在第一预设时间范围内未接收到访问请求反馈消息，确定数据库故障。
6.本公开实施例第二方面提供了一种数据库的故障诊断装置，该装置包括：
7.第一发送模块，用于向数据库发送访问请求，以使数据库根据接收到的访问请求，访问数据库的系统表并生成访问请求反馈消息。
8.第一确定模块，用于在第一预设时间范围内未接收到访问请求反馈消息时，确定数据库故障。
9.本公开实施例第三方面提供了一种主机，该主机包括：存储器和处理器；其中，存储器中存储有计算机程序，该计算机程序被处理器执行时，可以实现上述第一方面的方法。
10.本公开实施例第四方面提供了一种计算机可读存储介质，该存储介质上存储有计算机程序，当该计算机程序被处理器执行时，可以实现上述第一方面的方法。
11.本公开实施例提供的技术方案与现有技术相比具有如下优点：
12.通过向数据库发送访问请求，使得数据库根据该访问请求访问数据库的系统表并生成访问请求反馈消息，从而在第一预设时间范围内未收到访问请求反馈消息时，确定无法对数据库的系统表进行访问，数据库出现故障。由于本公开实施例是通过向数据库发送访问请求的方式来判断数据库是否故障的，不需要数据库中的容器搜集内存和磁盘性能指标，也不需要等待性能指标搜集结束后向数据库外部主机发送性能指标，因此能够提升数据库的故障检测效率，克服外部主机无法及时发现数据库故障的问题。
附图说明
13.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
14.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
15.图1是本公开实施例提供的一种数据库的故障诊断方法的流程图；
16.图2是本公开实施例提供的一种应用场景的示意图；
17.图3是本公开实施例提供的又一种数据库的故障诊断方法的流程图；
18.图4是本公开实施例提供的又一种应用场景的示意图；
19.图5是本公开实施例提供的又一数据库的故障诊断方法的流程图；
20.图6是本公开实施例提供的一种数据库的故障诊断装置的结构示意图；
21.图7是本公开实施例提供的一种主机的结构示意图。
具体实施方式
22.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
23.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
24.在相关技术中网络故障、数据库容器内部服务挂起等原因可能会导致诸如云服务数据库等关系型数据库不可用的问题。因此，为了保证关系型数据库服务(relational database service，简称rds)的可用性，相关技术一般是通过搜集数据库容器内部的内存和磁盘的性能指标(比如，剩余空间、是否可读写等)来对数据库容器的故障进行检测，通过探活数据库端口的方式来对数据库的端口进行检测。
25.具体的，在搜集内存和磁盘性能指标的方式中，一般是通过在数据库的容器中配置一个服务，通过该服务执行系统指令获取容器内部内存和磁盘的性能指标，并将获取到的性能指标发送给数据库外部的主机(是指在装配有数据库的主机之外，专门设置的用于进行数据库故障诊断的主机)，使得数据库外部的主机可以根据该些性能指标判断数据库是否发生故障。但是内存和磁盘性能指标的搜集需要耗费时间，并且只有在性能指标搜集完毕后才能将性能指标发送给外部主机，导致数据库故障检测的效率较低，从故障发生到解决的时间间隔较长。并且若网络出现故障，搜集到的性能指标将无法发送给外部主机，外部主机只有在网络超时之后才能发现网络故障，无法及时接收性能指标并发现故障，降低了故障检测的实时性。
26.在探活数据库端口的方式中，可以通过诸如远程终端协议(或者称为telent协议)或者因特网包探索器(packet internet groper，ping)的方式检测数据库端口的连通性，若数据库的端口不通，则立即发起修复过程，但是这时端口不通可能是由网络问题导致的，因此，探活数据库端口的方式存在误检的问题。
27.另外，无论探活数据库端口的方式还是搜集性能指标的方式均无法判别故障是属于数据库级别的还是主机级别的或者是可用区级别的，不利于故障的排除。其中，可用区是指包含两个及以上主机的区域，其中，每个主机上均装载有至少一个数据库。
28.针对相关技术存在的上述技术缺陷，本公开实施例提供了一种数据库的故障诊断方案，该方案通过向数据库发送访问请求，根据预设时间范围内是否能够收到访问请求反馈消息来判断数据库是否发生了故障。由于该方案不需要数据库中的容器搜集内存和磁盘的性能指标，也不需要等待性能指标搜集结束后再向数据库外部主机发送性能指标，因此能够提升数据库的故障检测效率，克服外部主机无法及时发现数据库故障的问题。
29.为了更好的理解本公开实施例的技术方案，下面结合示例性的实施例对本公开实施例的技术方案进行说明。
30.示例的，图1是本公开实施例提供的一种数据库的故障诊断方法的流程图，该方法示例性的可由数据库外部的主机执行，该主机可以被示例性的理解为预先配置的专门用于进行数据库故障诊断的主机。如图1所示，该方法包括：
31.步骤101、数据库外部的主机向数据库发送访问请求，以使数据库根据接收到的访问请求，访问数据库的系统表并生成访问请求反馈消息。
32.步骤102、数据库外部的主机若在第一预设时间范围内未接收到访问请求反馈消息，则确定数据库故障。
33.本实施例中所称的访问请求可以被示例性的理解为一种系统表更新请求，该请求中包括更新指令，更新指令用于指示数据库对系统表进行如下中的一种更新操作：写入、修改、删除。
34.其中，在本实施例的一种实施方式中，数据库外部的主机可以基于异步的方式同时向不同的数据库发送访问请求。
35.下面以系统表更新请求为例进行说明。
36.示例的，图2是本公开实施例提供的一种应用场景的示意图，如图2所示，在图2所示的场景中包括主机22、主机23和主机20。其中，主机22和主机23上装配有数据库，该数据库可以被示例性的理解为云服务数据库，但不局限于云服务数据库。主机22和主机23位于同一可用区21。主机20上搭载有用于对数据库进行故障诊断的计算机程序。当该计算机程序被执行时，主机20对主机22和主机23上的数据库执行故障诊断操作。
37.本领域技术人员可以理解的是，图2所示场景仅为一种示例性的场景，并不是本实施例适用的全部场景。实际上，在本实施例适用的其他场景中可用区21和主机20的数量均可以有多个，每个可用区21中可以包括两个及以上的主机。每个主机20可以用于对一个及以上的可用区中的主机进行数据库故障诊断操作。
38.本实施例中数据库外部的主机在执行数据库故障诊断操作时，可以基于不同的线程异步的向不同主机上的数据库发送系统表更新请求，也可以在同一线程上逐一向不同主机上的数据库发送系统表更新请求。尤其针对数据库数量较多的情况，上述两种方式也可以结合使用。比如，在图2中，主机20可以通过不同线程并发的向主机22和主机23上的数据库发送系统表更新请求，或者可以通过同一线程逐一的向主机22和主机23上的数据库发送系统表更新请求，或者当可用区21中还有其他主机的情况下，也可以通过同一线程异步的向主机22和主机23上的数据库发送系统表更新请求，同时采用其他线程异步的向可用区21
中的其他主机上的数据库发送系统表更新请求。
39.进一步地，可用区中的主机在接收到系统表更新请求之后，根据系统表更新请求的具体内容执行相应的数据库操作，并在第一预设时间范围内将操作结果作为成功更新的反馈消息反馈给数据库外部的主机，若不能成功执行相应的数据库操作，则不向数据库外部的主机反馈消息，或者反馈系统表更新失败的消息。其中，第一预设时间范围可以根据需要进行设定，本实施例不做限定。比如，在图2中，主机23在接收到系统表更新请求之后，成功的执行了相应的数据库操作(比如写操作)则在第一预设时间范围内将数据库操作结果作为反馈消息，反馈给主机20，相应的，主机20在接收到主机23的反馈消息后，判断主机23上的数据库正常。而如果主机22未能成功执行相应的数据库操作，则不向主机20反馈成功更新的消息，由于主机20未能在第一预设时间范围内接收到主机22成功更新的反馈消息，因而可以确定数据库发生故障，此时的故障可能是数据库容器中的内存和/或磁盘不能读写，属于数据库级别中的磁盘和/或内存故障。
40.由于本实施例是通过向数据库发送访问请求的方式来判断数据库是否故障的，不需要数据库中的容器搜集内存和磁盘性能指标，也不需要等待性能指标搜集结束后向数据库外部主机发送性能指标，因此能够提升数据库的故障检测效率，克服外部主机无法及时发现数据库故障的问题。另外，本实施例中的异步访问方式不受主机线程数量的约束，能够在单位时间内向更多的数据库发送系统表更新请求，实现更多数据库的故障诊断，提高了可用区的数据库故障检测效率。
41.图3是本公开实施例提供的又一种数据库的故障诊断方法的流程图。如图3所示，在向数据库发送访问请求之后，以使数据库根据接收到的访问请求，访问数据库的系统表并生成访问请求反馈消息之前，本实施例提供的方法还可以包括如下步骤：
42.步骤301、数据库外部的主机检测数据库是否接收到访问请求。
43.步骤302、数据库外部的主机在检测到数据库未接收到访问请求时，确定数据库故障。
44.具体的，在本实施例中，数据库在收到访问请求后，会向数据库外部的主机反馈用于表示已收到访问请求的响应消息，如果数据库外部的主机在预设时间内没有收到该响应消息，则确定数据库没有收到访问请求。
45.在确定数据库没有收到访问请求后，数据库外部的主机判断其与数据库的连接状态，若是已连接状态，则确定数据库发生故障，如果是未连接状态，则向数据库发送连接请求。其中，若在第二预设时间范围内未接收到数据库对该连接请求的响应信息，则继续向数据库发送连接请求，若在第二预设时间范围之后的第三预设时间范围内成功完成连接则说明之前是网络出现故障，而若是在第三预设时间范围内，仍未收到连接请求的响应信息，则确定数据库发生故障。
46.示例的，图4是本公开实施例提供的又一种应用场景的示意图，如图4所示，可用区41中包括主机42和主机43。主机40用于对可用区41中的数据库进行故障诊断。其中关于主机40、可用区41，以及主机42和主机43的情况可以参见图2相关部分的描述，在这里不在赘述。
47.参见图4，主机40通过不同线程或者相同线程异步的向可用区41中的主机上的数据库发送连接请求。可用区41中的主机若接收到连接请求，则向主机40反馈相应的响应信
息，若未接收到该连接请求，则不向主机40反馈任何消息。比如，可用区41中的主机43接收到了连接请求，那么就在第二预设时间范围内向主机40反馈响应消息，此时，主机40判断数据库的端口可用。而主机42未收到连接请求，则不向主机40反馈任何信息，主机40在第二预设时间范围内将不会收到主机42的响应信息，此时，导致这种情况的原因可能是网络故障，也可能是数据库的端口故障。
48.为了进一步确定故障原因，主机40在第二预设时间范围之后继续向主机42发送连接请求，如果在第二预设时间范围之后的第三预设时间范围内仍旧未收到主机42反馈的响应信息，那么确定数据库的端口故障。反之，如果在第二预设时间范围之后的第三预设时间范围内收到主机42反馈的响应信息，那么停止向主机42发送连接请求，确定故障为网络故障。
49.当然上述仅是以图4为例进行的示例说明，并不是对本公开的唯一限定。
50.本实施例通过向数据库发送连接请求，并在第二预设时间范围内未收到连接请求的响应信息时，继续向数据库发送连接请求，从而在第三预设时间范围内还没收到数据库的响应信息时判断当前故障为数据库故障，避免了网络故障导致的误判，提升了数据库故障诊断的准确性。
51.图5是本公开实施例提供的又一数据库的故障诊断方法的流程图，如图5所示，在图1实施例的基础上，本实施例提供的方法还可以包括如下步骤：
52.步骤501、数据库外部的主机向数据库发送性能指标查询请求，以使数据库中的容器根据性能指标查询请求，查询并反馈容器内的存储设备的性能指标。
53.步骤502、数据库外部的主机接收数据库反馈的性能指标。
54.步骤503、数据库外部的主机根据接收到的性能指标，确定数据库是否故障。
55.本实施例的方法可以与图1实施例的方法并行执行，也可以在图1方法执行之前或者之后执行。
56.本实施例所称的存储设备可以示例性的理解为内存和磁盘。存储设备的性能指标可以包括但不局限于存储设备的剩余空间以及是否可读写等。
57.数据库中的容器在搜集得到存储设备的性能指标之后，通过有线网络或无线网络将性能指标发送给数据库外部的主机，以使数据库外部的主机根据存储设备的性能指标判断数据库是否故障，比如当存储设备不能读写，或者存储空间已满时，判断数据库故障。
58.示例的，当基于性能指标确定出数据库发生故障和/或基于访问请求确定出数据库发生故障时，数据库外部的主机可以通过自身搭载的高可用服务程序向数据库发送修复指令，使得数据库根据该修复指令进行故障修复。
59.另外考虑到故障修复也需要一定的时间，为了避免在短时间内对同一故障进行重复修复，在一些实施方式中，还可以在基于性能指标确定出数据库发生故障和/或基于系统表更新请求确定出数据库发生故障之后，对上次修复的时间进行判断，比如可以设置一个定时器从每次修复操作之后开始计时，若距离上次修复的时间小于第三预设阈值，则放弃本次修复，否则执行本次修复操作。
60.本实施例基于访问请求的故障诊断方法，结合传统的基于性能指标的故障诊断方法，综合判断两种方法的诊断结果，在至少二者之一检测到数据库故障时，发起故障修复，能够避免单一方法存在的误检和漏检的问题，提高了故障检测的准确性，为及时排除故障
提供了保证。
61.本公开实施例还提供一种数据库的故障诊断方法，该方法在上述任一实施例的基础上，还可以包括如下步骤：
62.步骤601、数据库外部的主机判断数据库的故障率是否超过第一预设阈值。其中，若是，则确定发生主机级别的故障，执行步骤602。
63.其中，数据库的故障率是指数据库的故障次数与数据库的总诊断次数的比值。数据库的总诊断次数可以从数据库外部的主机的元数据中获得。
64.其中，第一预设阈值可以根据需要进行设置，本实施例不做具体限定。
65.步骤602、数据库外部的主机输出主机故障报警。
66.其中，这里的主机区别于数据库外部的主机，是指可用区中装载有数据库的主机，该主机上装载的数据库的故障率超过第一预设阈值。
67.步骤603、数据库外部的主机判断可用区中发生故障的主机的数量是否超过第二预设阈值，其中，若是，则确定发生可用区级别的故障，执行步骤604。
68.其中，第二预设阈值的数值可以根据需要进行设置，本实施例不做限定。
69.步骤604、输出可用区故障报警。
70.其中，本实施例所称的可用区中包括两个及以上的主机，各主机上分别设置有数据库。数据库外部的主机用于对可用区中的数据库进行诊断。
71.本实施例通过判断数据库的故障率是否超过第一预设阈值能够对主机级别的故障进行判断，通过判断可用区中发生故障的主机的数量是否超过第二预设阈值，能够对可用区级别的故障进行判断。从而克服了相关技术无法识别主机级别故障和可用区级别故障的问题。
72.图6是本公开实施例提供的一种数据库的故障诊断装置的结构示意图，如图6所示，故障诊断装置60包括：
73.第一发送模块61，用于向数据库发送访问请求，以使数据库根据接收到的访问请求，访问数据库的系统表并生成访问请求反馈消息；
74.第一确定模块62，用于在第一预设时间范围内未接收到所述访问请求反馈消息时，确定数据库故障。
75.在一种实施方式中，访问请求中包括更新指令，更新指令用于指示数据库对系统表进行如下中的一种更新操作：写入、修改、删除。
76.在一种实施方式中，装置60还可以包括：
77.检测模块，用于检测数据库是否接收到所述访问请求。
78.第二确定模块，用于在检测到数据库未接收到访问请求时，确定数据库故障。
79.在一种实施方式中，第二确定模块可以包括：
80.判断单元，用于在检测到数据库未接收到访问请求时，判断与数据库是否处于连接状态。
81.第一确定单元，用于判断与数据库处于连接状态时，确定数据库故障。
82.发送单元，用于在判断与数据库处于非连接状态时，向数据库发送连接请求；以及在第二预设时间范围内未接收到连接请求的响应信息时，继续向数据库发送连接请求。
83.第二确定单元，用于在第二预设时间范围之后的第三预设时间范围内，仍未收到
连接请求的响应信息时，确定数据库故障。
84.在一种实施方式中，装置60还可以包括：
85.第二发送模块，用于向数据库发送性能指标查询请求，以使数据库中的容器根据性能指标查询请求，查询并反馈容器内的存储设备的性能指标。
86.接收模块，用于接收数据库反馈的存储设备的性能指标。
87.第三确定模块，用于根据性能指标，确定数据库是否故障。
88.在一种实施方式中，装置60还可以包括：
89.第三发送模块，用于在基于性能指标确定数据库故障和/或基于访问请求确定数据库故障时，向数据库发送修复指令，以使数据库根据修复指令进行故障修复。
90.在一种实施方式中，装置60还可以包括：
91.第一判断模块，用于判断数据库的故障率是否超过第一预设阈值。
92.第一输出模块，用于在数据库的故障率超过第一预设阈值时，输出主机故障报警。
93.其中，所述主机是指装载有所述数据库的主机，所述数据库的故障率是指所述数据库的故障次数与所述数据库的总诊断次数的比值。
94.在一种实施方式中，装置60还可以包括：
95.第二判断模块，用于判断可用区中发生故障的主机的数量是否超过第二预设阈值；
96.第二输出模块，用于在可用区中发生故障的主机的数量超过第二预设阈值时，输出可用区故障报警；
97.其中，可用区是指包括两个及以上主机的区域，所述主机上装载有数据库。
98.本实施例提供的装置能够执行上述任一方法实施例的方法，其执行方式和有益效果类似，在这里不再赘述。
99.图7是本公开实施例提供的一种主机的结构示意图，如图7所示，主机70包括：存储器71和处理器72；
100.其中，存储器71中存储有计算机程序，计算机程序被处理器72执行时，实现上述任一方法实施例的方法，其执行方式和有益效果类似，在这里不再赘述。
101.本公开实施例还提供一种计算机可读存储介质，存储介质上存储有计算机程序，当所述计算机程序被处理器执行时，实现上述任一方法实施例的方法，其执行方式和有益效果类似，在这里不再赘述。
102.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
103.以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开
将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。