CN115981919A - 数据库集群的管理控制方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种数据库集群的管理控制方法、装置、设备及存储介质，涉及集群管理技术领域，实现了数据库集群的异常自动恢复，提升了集群高可用性。该技术方案在数据库集群出现异常时，则管理节点可以及时检测并进行相应的自动修复，无需等待相关人员人工修复，减少异常修复所需消耗的时长，从而提升数据库集群的可用性，以向用户提供更高可用的数据库服务。并且，本申请实施例所提供的分布式数据库包括至少两个管理节点以及多个成对的数据节点，每对数据节点包含主数据节点和备用数据节点，从而能够实现数据的备份，提升数据存储的可靠性。

Description

数据库集群的管理控制方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及集群管理技术领域，提供一种数据库集群的管理控制方法、装置、设备及存储介质。

背景技术

分布式数据库包括多个互连的数据库，通过分布式数据库的管理集群进行管理，由于其运行性能更高，从而分布式数据库的应用前景将越来越广。

但是，在分布式数据库的运行过程中不可避免的会出现一些异常，目前，当数据库出现异常时，通常需要人为的检测异常并进行修复，并且，人工恢复的过程繁杂，效率不高，而往往分布式数据库其本身承载着业务数据的存储加工功能，在等待人工恢复的过程中，其带来的业务损失是难以接受的，对于用户的数据库使用体验也不佳。

因此，目前如何实现分布式数据库的自动恢复是目前亟待解决的问题。

发明内容

本申请实施例提供一种数据库集群的管理控制方法、装置、设备及存储介质，用于实现分布式数据库的自动恢复功能。

一方面，提供一种数据库集群的管理控制方法，应用于分布式数据库集群包括的任一管理节点中，所述集群包含存储所述集群的元数据的至少两个管理节点，以及存储数据的多对数据节点，每一对数据节点包括主数据节点和备份数据节点；所述方法包括：

基于异常恢复指令的触发，执行数据库操作功能所对应的测试指令，获得相应的执行结果；其中，所述执行结果表征所述测试指令是否成功执行；

基于所述执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态；其中，所述角色状态信息用于表征本节点为主管理节点或者备用管理节点；

若确定本节点处于异常状态，则基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景；

获取为所述目标异常场景配置的异常恢复策略，并基于所述异常恢复策略执行异常恢复处理，以对所述数据库操作功能进行恢复。

在一种可能的实施方式中，基于所述执行结果以及本节点的角色状态信息，确定本节点的数据库操作功能是否处于异常状态，包括：

若所述执行结果指示测试指令执行失败的次数超过设定数量阈值，则确定本节点的数据库操作功能处于异常状态；

若所述执行结果指示测试指令执行失败的次数未超过设定数量阈值，则对本节点的网络环境进行检测，以确认网络环境是否出现异常。

在一种可能的实施方式中，所述方法还包括：

监测预设时长内是否接收到其他管理节点发送的心跳信息；

若未收到，则对其他管理节点进行离线检测，以确定其他管理节点是否处于离线模式；

若确定其他管理节点是否处于所述离线模式，则将本节点的运行模式切换为单节点模式。

一方面，提供一种数据库集群的管理控制装置，应用于分布式数据库集群包括的任一管理节点中，所述集群包含存储所述集群的元数据的至少两个管理节点，以及存储数据的多对数据节点，每一对数据节点包括主数据节点和备份数据节点；所述装置包括：

异常检测单元，用于基于异常恢复指令的触发，执行数据库操作功能所对应的测试指令，获得相应的执行结果；其中，所述执行结果表征所述测试指令是否成功执行；以及，基于所述执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态；其中，所述角色状态信息用于表征本节点为主管理节点或者备用管理节点；

异常场景检测单元，用于若确定本节点处于异常状态，则基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景；

异常恢复单元，用于获取为所述目标异常场景配置的异常恢复策略，并基于所述异常恢复策略执行异常恢复处理，以对所述数据库操作功能进行恢复。

在一种可能的实施方式中，所述异常检测单元，具体用于：

基于异常恢复指令的触发，根据所述至少两个管理节点各自的角色状态信息，确定是否存在多个管理节点为主管理节点；

若不存在多个管理节点为主管理节点，则执行数据库操作功能所对应的测试指令，获得相应的执行结果。

在一种可能的实施方式中，所述集群通过连接池对外提供服务；则异常恢复单元，还用于：

若存在多个管理节点为主管理节点，则停止所述连接池的对外服务功能；

根据所述多个管理节点的数据操作进度，从所述多个管理节点中确定数据操作时间最靠后的目标管理节点；

若本节点并非所述目标管理节点，则将本节点的操作数据发送给所述目标管理节点，以使得所述目标管理节点在基于所述操作数据重新执行相应的数据操作后，重新启动所述连接池的对外服务功能。

在一种可能的实施方式中，异常恢复单元，还用于：

若确定所述数据库操作功能处于正常状态，则检测所述集群的连接池所对应的对外服务功能是否处于异常状态；

若所述对外服务功能处于异常状态，则获取为所述对外服务功能配置的异常恢复策略，并基于所述异常恢复策略执行异常恢复处理。

在一种可能的实施方式中，所述异常检测单元，具体用于：

若所述执行结果指示测试指令执行失败的次数超过设定数量阈值，则确定本节点的数据库操作功能处于异常状态；

若所述执行结果指示测试指令执行失败的次数未超过设定数量阈值，则对本节点的网络环境进行检测，以确认网络环境是否出现异常。

在一种可能的实施方式中，所述装置还包括角色状态切换单元，用于：

基于本节点与数据库之间的连接状态，确定本节点当前的角色状态信息；

若所述角色状态信息为备用管理节点，则执行地址解绑操作，以解除本节点与数据库的虚拟访问地址的绑定关系；

在检测到所述集群的数据库操作功能处于异常状态时，确定本节点是否满足切换为主管理节点的前置条件；

若满足，执行角色状态切换操作，以将本节点切换为主管理节点。

在一种可能的实施方式中，所述装置还包括锁管理单元，用于：

响应于针对所述集群进行的目标操作所触发的锁请求消息，从本节点获取相应的锁；其中，所述锁请求消息用于请求为所述目标操作分配锁，所述目标操作为针对所述集群进行的任意操作；

若所述锁请求消息为本节点中的本地应用所触发，则向除本节点之外的其他管理节点发起锁获取请求；

若除本节点之外的其他管理节点均成功返回锁，则输出指示所述锁请求消息获取锁成功的指示信息。

在一种可能的实施方式中，所述锁管理单元，具体用于：

若所述锁请求消息为本节点中的本地应用所触发，则确认所述集群当前是否处于单节点模式；其中，所述单节点模式表征除本节点之外的其他管理节点均处于离线模式；

若未处于单节点模式，则除本节点之外的其他管理节点发起锁获取请求；

若处于单节点模式，则输出指示所述锁请求消息获取锁成功的指示信息。

在一种可能的实施方式中，所述锁管理单元，还用于：

监测预设时长内是否接收到其他管理节点发送的心跳信息；

若未收到，则对其他管理节点进行离线检测，以确定其他管理节点是否处于离线模式；

若确定其他管理节点是否处于离线模式，则将本节点的运行模式切换为所述单节点模式。

在一种可能的实施方式中，所述锁管理单元，还用于：

针对本节点记录的锁信息进行遍历，直至所有锁信息遍历结束为止，针对每一条锁信息，执行如下操作：

根据所述锁信息中的进程标识，确定所述锁信息对应的目标进程是否还存在；

若所述目标进程已不存在，且当前处于单节点模式时，释放本节点中所述锁信息对应的锁；

若所述目标进程已不存在，且当前未处于单节点模式时，则请求相应的管理节点释放所述锁信息对应的锁。

一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一种方法的步骤。

一方面，提供一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一种方法的步骤。

一方面，提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行上述任一种方法的步骤。

本申请实施例中，通过执行数据库操作功能所对应的测试指令，以基于执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态，当处于异常状态时，能够基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景，从而相应获取为目标异常场景配置的异常恢复策略，并基于异常恢复策略执行异常恢复处理，以对数据库操作功能进行恢复，那么，在数据库集群出现异常时，则管理节点可以及时检测并进行相应的自动修复，无需等待相关人员人工修复，减少异常修复所需消耗的时长，从而提升数据库集群的可用性，以向用户提供更高可用的数据库服务。并且，本申请实施例所提供的分布式数据库包括至少两个管理节点以及多个成对的数据节点，每对数据节点包含主数据节点和备用数据节点，从而能够实现数据的备份，提升数据存储的可靠性。

附图说明

为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的分布式数据库集群的架构示意图；

图2为本申请实施例提供的管理节点的结构示意图；

图3为本申请实施例提供的集群切换流程的流程示意图；

图4为本申请实施例提供的异常恢复过程的一种流程示意图；

图5为本申请实施例提供的异常恢复过程的另一种流程示意图；

图6为本申请实施例提供的实现操作时申请锁的流程示意图；

图7为本申请实施例提供的管理节点之间同步各自的在线状态的流程示意图；

图8为本申请实施例提供的释放锁的流程示意图；

图9为本申请实施例提供的数据库集群的管理控制装置的一种结构示意图；

图10为本申请实施例提供的计算机设备的一种结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

为便于理解本申请实施例提供的技术方案，这里先对本申请实施例使用的一些关键名词进行解释：

角色状态：角色状态是指数据库集群包含的管理节点的状态，本申请实施例涉及到的角色状态主要包括主管理节点状态、备用管理节点以及非主管理节点或者备用管理节点的其他状态，在不同的角色状态时管理节点所能够实现的功能不同。

管理节点：管理节点用于实现分布式数据库的管理功能，存储分布式数据库的元数据信息。管理节点可以包括主管理节点和备用管理节点，主管理节点用于提供分布式数据库的主要功能，即对外提供数据库服务，备用管理节点则处于备用状态，必要时可切换为主管理节点来提供服务。对于一个管理节点而言，其可以为主管理节点，也可以为备用管理节点，可以通过一定的切换机制进行切换。

数据库操作功能：数据库操作功能主要包括需要对数据进行的操作功能，例如查询、写入或者修改等操作，通常而言，数据库操作功能是针对管理节点而言的，当一个管理节点为主管理节点时，则可以具备数据库操作功能，来对外提供数据库服务。

目前，分布式数据库的运行性能相较于传统的数据库更高，因此其应用更为广泛。但是，分布式数据库的运行过程中难免会出现一些异常，当出现异常时，则需要相关的维保人员进行维护修复，人工恢复的过程繁杂，效率不高，这对于分布式数据库而言，其本身承载着业务数据的存储加工功能，其带来的业务损失是难以接受的。

基于此，本申请实施例提供了一种数据库集群的管理控制方法，该方法可以实现周期性的检测和修复异常，具体而言，通过执行数据库操作功能所对应的测试指令，以基于执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态，当处于异常状态时，能够基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景，从而相应获取为目标异常场景配置的异常恢复策略，并基于异常恢复策略执行异常恢复处理，以对数据库操作功能进行恢复，那么，在数据库集群出现异常时，则管理节点可以及时检测并进行相应的自动修复，无需等待相关人员人工修复，减少异常修复所需消耗的时长，从而提升数据库集群的可用性，以向用户提供更高可用的数据库服务。并且，本申请实施例所提供的分布式数据库包括至少两个管理节点以及多个成对的数据节点，每对数据节点包含主数据节点和备用数据节点，从而能够实现数据的备份，提升数据存储的可靠性。

此外，本申请实施例为了增加分布式数据库的高可用性，每个管理节点都会周期性的检测集群的状态，即是否正常提供服务，若主管理节点无法提供服务，而本节点满足切换为主管理节点的条件时，则自动触发切换为主管理节点，来对外提供服务，保障数据库服务的高可用性。

本申请实施例中，为了避免同时进行排他操作而引起集群异常甚至数据的损坏，提供了一种分布式锁，在执行某一操作时，需要向所有管理节点申请锁，只有当同时获取了所有管理节点的锁时，才能够允许执行，以避免个管理节点同时执行使得集群异常。

下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

本申请实施例提供的方案可以适用于分布式数据库场景中。如图1所示，为本申请实施例提供的一种分布式数据库集群的架构示意图，该数据库集群架构由客户端、连接池、至少两个管理节点和多对存储节点组成，每一对存储节点包括成对的存储节点，一个作为主存储节点，另一个作为备份存储节点，以对数据进行备份，保障数据的可靠性。

其中，客户端可以部署于终端设备上，用于向用户提供数据库相关的服务功能。管理节点用于存储数据库表的元数据信息，每个管理节点均可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式集群，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、即内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云端服务器，但并不局限于此。存储节点用于存储实际数据，其可以采用任意具备数据存储功能的设备来实现，其可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式集群。

连接池是一个位于管理节点和数据库客户端之间的中间件，用于实现对外提供数据库服务，即接收客户端发送的数据库操作请求，并转发给当前的主管理节点进行相应数据库处理。在一种可能的实施方式中，可以采用单机的pgpool连接池，即仅使用pgpool连接池提供的连接池功能，不依赖pgpool做集群的切换。

需要说明的是，本申请实施例中的数据库集群的管理控制方法可以由任意的管理节点来执行，每个管理节点均可以包括一个或多个处理器、存储器以及与交互I/O接口等。其中，每个管理节点的存储器中可以存储本申请实施例提供的数据库集群的管理控制方法中各自所需执行的程序指令，这些程序指令被处理器执行时能够用以实现本申请实施例提供的数据库异常恢复过程。

在一种可能的实施方式中，分布式数据库集群可以包括两个管理节点，其中一个为主管理节点，另一个为备用管理节点，当然，必要时二者之间可进行切换。

本申请实施例中，客户端、连接池、至少两个管理节点和多对存储节点之间可以通过一个或者多个网络进行直接或间接的通信连接。该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(Wireless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本申请实施例对此不做限制。

参见图2所示，为本申请实施例提供的管理节点的结构示意图，其中，图2具体是以双管理节点为例进行示出，当为更多数量的管理节点时则可以也以此类推。针对每个管理节点而言，其均可以包括高可用性(High Available，HA)模块、异常恢复模块和集群控制模块，各模块所能实现的功能如下：

(1)HA模块

HA模块主要用于监测集群的状态，并在主管理节点异常时触发集群的切换，即将备用管理节点切换为主管理节点，保障高可用性。HA模块定时巡检本节点的角色状态，角色状态分为主管理节点(以primary表示)、备用管理节点(以mirror表示)以及除这两种情况之外的其他角色状态(以other表示)，根据不同的角色状态会执行不同的操作。例如巡检本节点为primary时，则会将对外服务的数据库的虚拟访问地址绑定至本节点上，并重置获取集群状态失败的计数次数；或者，当巡检本节点为mirror时，则会将虚拟访问地址与本节点进行解绑定，并根据条件检查是否需要触发切换；又或者，当巡检本节点为other，时，则将虚拟访问地址与本节点进行解绑定，并重置获取集群状态失败计数。

(2)异常恢复模块

异常恢复模块主要用于常见的异常场景的恢复，从而实现实时的自动异常恢复，避免数据库服务的中断。具体而言，管理节点可以循环执行异常恢复的检查操作，对于不同的角色状态的管理节点而言，其可以执行不同的操作。当检测到当前发生脑裂场景时，则根据数据和预写日志的情况判断出哪一个管理节点可以作为的主管理节点，则另一个管理节点被重做为备用管理节点。当管理节点处于正常状态的情况下，则进一步检查连接池状态，主管理节点会进行数据节点的检查与维护，备用管理节点会检查维护备管理节点服务状态；而当处于异常状态，则会可以按照预定的恢复策略方案尝试进行恢复。

(3)集群控制模块

集群控制模块主要用于管理集群的启动、停止以及恢复等操作，以避免出现同时进行排他操作引起集群异常甚至数据损坏的情况，集群控制模块实现了分布式锁的管理和分配，其主要包括接收请求线程、心跳发送线程、心跳接收线程和定时检查线程，接收请求线程接收来自本地应用和另一个管理节点的请求消息，并且如果是本地应用的请求则将请求同步发送另一个管理节点，本地和远端都申请成功才能算做最终申请成功；心跳发送和接收线程用于两个管理节点之间的在线状态的同步，如果一个管理节点的心跳丢失，则另一个管理节点ping对端管理节点，如果确定对端管理节点离线了就将自身切换为单节点模式，即除本节点之外的其他管理节点均处于离线模式时，则采用单节点模式运行，而如果获取到心跳信息则从单节点模式切换回双节点模式，同时心跳信息中带上当前节点的锁信息；定时检查线程根据自身内存中的锁信息，检查本地占锁进程是否还存活，如果进程挂了没释放锁，将锁释放。需要对集群进行操作的时候需要向本节点的集群控制模块申请锁，管理节点对于锁信息维护采用单例模式加锁实现线程间共享。

上述各个模块具体执行的功能将在后续的方法实施例中具体进行介绍，因而在此先不过多赘述。

下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供的数据库集群的管理控制方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

在分布式数据库集群的运行过程中，主管理节点用于对外提供服务，当主管理节点出现异常，则会使得集群无法正常提供数据库服务，因而需要将备用管理节点切换为主管理节点，以保证集群的高可用性，该过程可以由上述提及的HA模块来实现，HA模块可以在任意的管理节点中运行。参见图3所示，为本申请实施例提供的集群切换流程的流程示意图，该流程可以由任意的管理节点来执行，其具体实施流程如下：

步骤301：确定本节点当前的角色状态信息。

本申请实施例中，HA模块可以周期性检测是否触发集群的切换，或者也可以基于集群事件的触发来进行检测是否进行切换。

其中，角色状态包括primary、mirror和other三种，管理节点可以通过尝试执行各个角色状态所能够执行的功能，并基于执行结果来确定自身的角色状态。

在一种可能的实施方式中，考虑到只有对外提供数据库服务的主管理节点能够实现与数据库的连接，正常访问数据节点，那么管理节点可以基于本节点与数据库之间的连接状态，来确定本节点当前的角色状态信息。也就是说，管理节点可以与数据库进行尝试连接，若能够正常连接，则表明本节点为主管理节点，而若是连接不上，则表明本节点为备用管理节点，即处于mirror状态，若出现其他情况，则可以确定角色状态为other状态。

在一种可能的实施方式中，管理节点中可以根据自身的配置信息中相关配置字段确定本节点当前的角色状态信息，该配置字段用于表征本节点当前的角色状态信息。

步骤302：若角色状态信息指示本节点为primary，则执行地址绑定操作，以将数据库的虚拟访问地址与本节点进行绑定。

在实际应用时，执行地址绑定操作后，则数据库的虚拟访问地址与本节点进行绑定，客户端访问该虚拟访问地址时，连接池可以将相应的访问请求分发至本节点来处理，以实现数据库的访问功能。

具体的，执行地址绑定操作可以是指修改虚拟访问地址与之对应的管理节点的映射关系，从而连接池分发访问请求时能够基于该映射关系确认当前的主管理节点。

步骤303：重置集群异常计数次数。

其中，集群异常计数次数表示为failed_times，则将failed_times重置为零，即表征当前集群的对外数据库服务功能正常。

步骤304：若角色状态信息指示本节点为mirror，则执行地址解绑操作，以解除本节点与数据库的虚拟访问地址的绑定关系。

当本节点为mirror时，则表明本节点无需实现主节点的功能，为避免连接池的分发错误，则需要解除本节点与数据库的虚拟访问地址的绑定关系，这样，当连接池进行访问请求的分发时，则可以根据绑定关系分发至相应的主管理节点，而避免分发至备用管理节点，从而保障数据库访问的正常进行。

步骤305：检测集群的数据库操作功能是否处于异常状态。

本申请实施例中，数据库操作功能异常时，则无法正常对数据库实现操作，也就表明当前的主管理节点处于异常状态，无法实现正常的工作，从而可能需要进行角色状态的切换，以保证集群的高可用性。

在一种可能的实施方式中，可以通过尝试访问数据库，根据访问结果来判定数据库操作功能是否处于异常状态，若能够正常访问，则表明数据库操作功能正常；相反的，若无法正常访问，则表明数据库操作功能处于异常状态。

在一种可能的实施方式中，还可以通过与主管理节点保持状态的通信，从主管理节点获取其是否处于异常状态。

步骤306：当数据库操作功能处于异常状态时，更新集群异常计数次数，即对failed_times进行+1操作。

步骤307：判断集群异常计数次数是否达到上限值。

步骤308：若集群异常计数次数达到上限值，确定本节点是否满足切换为主管理节点的前置条件。

具体的，前置条件是指本节点是否满足切换检查项，也就是判断本节点是否正处于一些特殊场景中，例如当本节点正在执行重启操作时，则无法正常提供服务，从而可以确定不满足前置条件。

步骤309：若满足前置条件，执行角色状态切换操作，以将本节点切换为主管理节点。

步骤310：当数据库操作功能处于正常状态时，重置集群异常计数次数，

步骤311：若角色状态信息指示本节点为other，则执行地址解绑操作，以解除本节点与数据库的虚拟访问地址的绑定关系。

步骤312：重置集群异常计数次数。

需要说明的是，上述HA模块的状态切换是在备管理节点去触发切换，因为此时原来的主管理节点可能已经离线，所以此操作一定是在备管理节点进行的。因此，在执行上述过程的过程中，同样会收到集群控制模块的约束，即一个操作只有在申请到锁的情况下才能够执行，例如在触发切换时，需要申请到锁时才能够执行，避免出现多个管理节点切换为主管理节点的情况，当然，在具体应用时，可能存在原始主管理节点已经离线的情况，这种情况无法从原始主管理节点获取到锁，那么可以变更集群为单节点模式，以便于切换的正常进行。

参见图4所示，为本申请实施例提供的异常恢复过程的一种流程示意图，该过程可以通过上述的异常恢复模块来实现，可以对一些常见的异常场景进行恢复，以实现实时的异常恢复，避免业务的中断。其具体实施流程如下：

步骤401：基于异常恢复指令的触发，执行数据库操作功能所对应的测试指令，获得相应的执行结果；其中，执行结果表征测试指令是否成功执行。

本申请实施例中，异常恢复的过程可以是周期性执行的，那么异常恢复指令可以是预先设置好的周期性的指令，每间隔预定时长触发执行；或者，异常恢复的过程也可以是基于条件触发来执行的，那么当满足触发条件时，则触发异常恢复指令的执行，来执行异常恢复的过程。

具体的，测试指令用于测试本节点是否能够成功执行数据库操作功能，若是能够成功执行时，则能够表明本节点能够实现主管理节点所能够实现的数据库服务功能，而若不能成功执行，则能够表明本节点不能实现主管理节点所能够实现的数据库服务功能，即并非主管理节点。

步骤402：基于执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态；其中，角色状态信息用于表征本节点为主管理节点或者备用管理节点。

其中，角色状态信息能够表征本节点当前实际的角色状态，从而可以判断执行结果与角色状态信息指示的角色状态是否相符，来确定本节点是否处于异常状态。

具体的，正常来讲，主管理节点是能够成功执行数据库操作功能的，因而当角色状态信息指示本节点为主管理节点，但执行结果指示无法成功执行数据库操作功能时，则表明本节点处于异常状态；或者，当角色状态信息指示本节点为主管理节点，且执行结果指示成功执行数据库操作功能时，则表明本节点处于正常状态。

同理，备用管理节点无法成功执行数据库操作功能，因此，当角色状态信息指示本节点为备用管理节点，且执行结果指示无法成功执行数据库操作功能时，则表明本节点处于正常状态；或者，当角色状态信息指示本节点为备用管理节点，但执行结果指示成功执行数据库操作功能时，则表明本节点处于异常状态。

步骤403：若确定本节点处于异常状态，则基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景。

步骤404：获取为目标异常场景配置的异常恢复策略，并基于异常恢复策略执行异常恢复处理，以对数据库操作功能进行恢复。

本申请实施例中，可以针对各个异常场景预先配置好异常场景条件以及相应的异常恢复策略，从而当本节点处于异常状态时，则可以与各个预设异常场景进行匹配，以从中确定与之匹配的目标异常场景，从而可以利用为该目标异常场景配置好的异常恢复策略进行异常恢复。

具体的，在进行匹配时，可以逐一与各个预设异常场景进行匹配，确定本节点当前的异常数据能够匹配上当前预设异常场景的异常场景条件，若能够匹配，则停止匹配流程；若不能匹配，则继续与下一个预设异常场景进行匹配，直至所有预设异常场景匹配完成。若无法成功匹配上任何预设异常场景，则可以向相关人员触发提醒，以便相关人员及时进行修复。

参见图5所示，为本申请实施例提供的异常恢复过程的另一种流程示意图，其具体实施流程如下：

步骤501：获取各管理节点的角色状态信息。

具体的，可以通过各个管理节点之间的同步，来获取到出本节点之外的其他管理节点的角色状态信息。

步骤502：确定是否存在多个管理节点为主管理节点。

具体的，可以在异常恢复指令的触发，根据各个管理节点各自的角色状态信息，确定当前是否存在多个管理节点为主管理节点，通常而言，在正常运行时，只会允许一个管理节点提供数据库服务，当存在多个管理节点为主管理节点时，可能会使得数据库的数据出现错误，这种现象称为脑裂现象。

步骤503：若存在多个管理节点为主管理节点，停止连接池的对外服务功能。

具体的，若判断出现了脑裂现象，为了避免多个主管理节点对数据库进行操作，使得数据库异常，则首先停止连接池的对外服务功能，以避免新的数据写入到数据库。

步骤504：根据多个管理节点的数据操作进度，从多个管理节点中确定数据操作时间最靠后的目标管理节点。

以两个管理节点的场景为例，则出现脑裂现象时，本节点与另一管理节点均为主管理节点，则本节点可以向与另一管理节点发起请求，以获取另一管理节点的数据操作进度，从而基于自身与另一管理节点的数据操作进度，选取出一个作为最终的主管理节点。

在一种可能的实施方式中，可以将数据操作时间最靠后的目标管理节点作为最终的主管理节点。

步骤505：若本节点并非目标管理节点，则本节点进行备重做。

步骤506：重启连接池功能。

也就是说，若选定了主管理节点之后，若本节点并非目标管理节点，则需要进行备重做。具体而言，可以将操作数据发送给选择定的目标管理节点，使得目标管理节点基于操作数据重新执行相应的数据操作后，重新启动连接池的对外服务功能，以继续对外提供数据库服务。

本申请实施例中，考虑到脑裂现象出现时会出现多个管理节点同时对数据库服务进行操作的情况，因而可能数据库出现操作冲突的情况，那么则通过上述的异常修复流程，可以在脑裂现象出现时及时进行修复，从而避免对数据库的操作出现冲突，使得数据库中数据混淆的情况，提升数据库管理的可靠性。

步骤507：若步骤502的确定结果为否，即不存在多个管理节点为主管理节点，则确定本节点是否处于异常状态。

考虑到脑裂现象对于数据库的影响较大，从而为了避免脑裂现象带来的数据库数据的混淆，从而在进行本节点的数据库操作功能的测试之前，还需要首先判断当前系统是否出现脑裂现象，只有当确定不存在脑裂现象时，则本节点需要继续检验自身是否处于异常状态，即可以执行数据库操作功能所对应的测试指令，进而根据相应的执行结果以及自身的角色状态信息判断本节点是否处于异常状态。

步骤508：若本节点是否处于正常状态，则重置执行测试指令的次数；其中，执行测试指令的次数可以表示为retryCheckMaster。

步骤509：检测连接池状态，若异常则执行异常恢复处理。

本申请实施例中，当管理节点状态正常的情况下，则会继续检查是否存在其他异常。由于连接池是用于客户端和管理节点之间的通信连接，因而为了保障客户端与管理节点之间的通信畅通，则还会检查连接池状态，从而当连接池状态出现异常，能够及时对连接池进行修复，避免客户端无法正常连接至管理节点的情况，提升数据库服务功能的可靠性。

具体的，主管理节点会进行数据节点的检查与维护，备管理节点会检查维护备管理节点服务状态。

具体的，本节点可以通过尝试连接连接池，以对集群的连接池所对应的对外服务功能是否处于异常状态进行检测，若对外服务功能处于异常状态，则获取为对外服务功能配置的异常恢复策略，并基于异常恢复策略执行异常恢复处理。

步骤510：确定本节点是否为主管理节点。

步骤511：若为是，即本节点为主管理节点，则检测数据节点是否存在异常，若存在异常对数据节点进行异常恢复处理。

步骤512：若为否，即本节点为备用管理节点，则再次检测本节点是否存在异常，若存在根据本节点异常类型尝试进行异常恢复处理。

步骤513：若步骤507的确定结果为是，即本节点处于异常状态时，确定测试指令执行失败的次数费是否超过设定数量阈值。

本申请实施例中，若结合本次的执行结果确定本节点处于异常状态时，则对retryCheckMaster进行加一，当retryCheckMaster的值大于设定数量阈值时，则表明本节点确实处于异常状态，通过多次确定以避免出现误判的情况，提升准确率。

步骤514：若超过，则根据条件判断，选择相应预设异常场景的异常恢复策略进行恢复处理。例如当数据节点出现异常时，则对数据节点进行异常恢复；或者，节点切换出现故障，则将该节点恢复至该节点更加倾向于的状态。

步骤515：若未超过，则对本节点的网络环境进行检测，以确认网络环境是否出现异常。例如检测网卡链路聚合的带宽是否能够到达服务要求。

通过周期性的进行上述异常检测，能够使得管理节点对于出现的异常及时进行修复，以避免数据库服务中断，提升服务的可靠性。

本申请实施例中，考虑到管理节点的操作可能会对其他管理节点甚至整个集群产生一定的影响，并且给分布式的架构使得管理节点之间相互独立，若同时进行排他性的操作则可能引起集群异常甚至数据损坏。例如，上述的HA模块涉及到的切换只有当管理节点为备用管理节点时才会触发，并且考虑到主管理节点可能已经离线，因此该操作一定是在备用管理节点进行的。对异常恢复模块中针对数据节点的检测以及恢复的过程，也一定是在主管理节点进行，因为备管理节点也可能离线。上面的这类操作都会影响整个集群的运转，但却不在同一节点无法用本地锁解决冲突。类似的还有用户下发的服务启停等，因此需要一个分布式锁，但是常规的分布式锁的实现都依赖于分布式锁中间件，两节点场景下中间件本身的高可用就成为了问题，因此本申请实施例提供了一种简易的分布式锁管理模块。

参见图6所示，为本申请实施例实现操作时申请锁的流程示意图，该流程可以由集群控制模块的接收请求线程来处理，其可以接收来自本地应用和其他管理节点的请求消息，并且如果是本地应用的请求则将请求同步发送另其他管理节点，本地和远端都成功则认为锁申请成功。

步骤601：接收锁请求消息。

本申请实施例中，如上所述，为避免出现排他操作带来的影响，在进行操作之前，都需要申请锁，当申请成功才能顺利执行。

步骤602：从本节点获取相应的锁。

进而，响应于针对集群进行的目标操作所触发的锁请求消息，从本节点获取相应的锁；其中，锁请求消息用于请求为目标操作分配锁，目标操作为针对集群进行的任意操作，当然，在实际应用时，可以选定某些操作作为目标操作，而不是将所有操作作为目标操作，对于未选定为目标操作的其他操作而言，则可以直接执行，无需等待锁分配。

步骤603：判断锁请求消息是否为本节点中的本地应用所触发。

若是成功获取了本地锁，则需要判断该锁请求是否本地应用所触发，本地应用可以是指在本节点进行的操作或者本节点所需执行的操作，即可以认为本地应用触发，例如重启本节点等，若并非本地应用触发，则应为其他管理节点触发，则返回成功信息即可，即跳转至步骤608。

步骤604：若锁请求消息为本节点中的本地应用所触发，确认集群当前是否处于单节点模式。

步骤605：若并非单节点模式，则向除本节点之外的其他管理节点发起锁获取请求。

为了在其他节点出现异常时操作得以正常进行，则本申请实施例还提供了单节点模式，以单节点模式运行时，则本节点无需考虑其他节点，而独立运行，因此若确定为本地节点触发，则还需要向其他管理节点申请锁，因而需要确认当前是否为单节点模式，即其他管理节点出现离线等无法通信的情况时，则无需向其申请锁，那么当并非单节点模式时，则需要向其他管理节点申请锁，而若是单节点模式时，则返回成功信息即可，即跳转至步骤608。

步骤606：判断其他管理节点是否成功分配锁。

步骤607：若未成功，释放本地锁，并跳转至步骤609；若成功，返回成功信息即可，即跳转至步骤608。

步骤608：输出指示锁请求消息获取锁成功的指示信息。

步骤609：输出指示锁请求消息获取锁失败的指示信息。

具体的，当获取锁成功，则目标操作得以顺利执行，反之，若获取锁失败，则目标操作拒绝响应。

本申请实施例中，管理节点之间需要同步各自的在线状态，从而如果一个管理节点心跳丢失，其他管理节点可以通过ping对端节点，如果确认对方节点离线就将自身切换为单节点模式，如果获取到心跳信息则从单节点模式切换回双节点模式，同时心跳信息中带上当前节点的锁信息，从而使得对于集群的操作得以正常的进行。

参见图7所示，为本申请实施例管理节点之间同步各自的在线状态的流程示意图，该流程可以由集群控制模块的心跳发送和接收线程来处理。需要说明的是，如下的同步流程仅以两个管理节点的场景示例一次同步过程，在实际应用时可以是一次也可以是循环多次进行的，本申请实施例对此不做限制。

步骤701：向对端管理节点发送心跳信息获取请求。

步骤702：判断是否已获取到对端管理节点的心跳信息。

步骤703：若已经获取到对端管理节点的心跳信息，则更新对端管理节点的心跳信息。

步骤704：若当前为单节点模式，则切换为双节点模式。

步骤705：若未获取到对端管理节点的心跳信息，则多次进行尝试获取，并确定未获取到心跳信息的连续时长是否超过预设时长阈值，例如是否连续30s未能接收到心跳信息。

步骤706：判断对端管理节点是否已离线。例如可以通过ping对端节点的方式来确认对方节点是否已经离线。

步骤707：若确定已经离线，则自身标记为单节点模式。

对于任意的管理节点其执行上述过程是相同的，因此不再进行赘述。

本申请实施例中，需要定时检查本地占锁进程是否还存活，如果进程挂了没释放锁，则需要将锁释放，并且应用需要操作集群的时候只需要向本机的集群控制模块申请锁。管理节点对于锁信息维护采用单例模式加锁实现线程间共享。上述过程可以通过集群控制模块中的定时检查线程来实现。参见图8所示，本申请实施例提供的释放锁的流程示意图。

步骤801：基于对端管理节点的心跳信息中的锁信息，剔除本节点中由对端管理节点申请且时间大于预设时长阈值，但是对端管理节点已经释放的锁。

步骤802：遍历当前管理模块记录的锁信息，直至所有锁信息遍历结束位为止。

步骤803：根据本节点锁信息中进程标识信息，例如IP和PID信息等，检查本节点申请锁的目标进程是否还存在，若存在，则不能对其释放，则跳转至步骤802，对下一锁信息进行遍历。

步骤804：若不存在，则需要对锁进行释放，首先需要确定本节点当前是否单节点模式。

步骤805：若为是，则释放本节点中该锁信息对应的锁。

步骤806：若为否，则向对端管理节点申请释放该锁信息对应的锁。

通过上述的过程，在进行心跳检测的同时，还能够将锁信息发送给对端，从而能够对已经无用的锁进行释放，从而降低锁所占用的资源消耗，提升集群的资源利用率。

需要说明的是，上述的示例主要是以两个管理节点为例进行介绍，但是上述方法同样可以适用于多个管理节点的场景中，例如在切换为单节点模式时则需要确定其他管理节点均已离线等，因而针对多个管理节点的情况本申请实施例不再进行赘述。

本申请实施例中，考虑到上述过程中并没有设置锁等待过程，故无法处理不同锁级别或是不同锁资源的死锁场景，但是，在实际使用时也可以按照实际的需求进行扩展，增加锁等待，这样定时检查线程可以从两节点的锁信息中找到死锁信息，并按一定规则解锁，使得不会发生冲突的请求可以同时进行响应。

综上所述，本申请实施例中实现了一套稳定的数据库集群的异常自动恢复和高可用方案，通过在主备管理节点进行针对不同场景的不同恢复操作，保障了系统的高可用，能够灵活地应对各种异常，大大减少了人力投入，并有良好的扩展性，并通过自实现的两节点分布式锁管理，解决了恢复操作之间及用户操作之间可能带来的冲突。

请参见图9，基于同一发明构思，本申请实施例还提供了一种数据库集群的管理控制装置90，应用于分布式数据库集群包括的任一管理节点中，集群包含存储集群的元数据的至少两个管理节点，以及存储数据的多对数据节点，每一对数据节点包括主数据节点和备份数据节点；该装置包括：

异常检测单元901，用于基于异常恢复指令的触发，执行数据库操作功能所对应的测试指令，获得相应的执行结果；其中，执行结果表征测试指令是否成功执行；以及，基于执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态；其中，角色状态信息用于表征本节点为主管理节点或者备用管理节点；

异常场景检测单元902，用于若确定本节点处于异常状态，则基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景；

异常恢复单元903，用于获取为目标异常场景配置的异常恢复策略，并基于异常恢复策略执行异常恢复处理，以对数据库操作功能进行恢复。

在一种可能的实施方式中，异常检测单元901，具体用于：

基于异常恢复指令的触发，根据至少两个管理节点各自的角色状态信息，确定是否存在多个管理节点为主管理节点；

若不存在多个管理节点为主管理节点，则执行数据库操作功能所对应的测试指令，获得相应的执行结果。

在一种可能的实施方式中，集群通过连接池对外提供服务；则异常恢复单元903，还用于：

若存在多个管理节点为主管理节点，则停止连接池的对外服务功能；

根据多个管理节点的数据操作进度，从多个管理节点中确定数据操作时间最靠后的目标管理节点；

若本节点并非目标管理节点，则将本节点的操作数据发送给目标管理节点，以使得目标管理节点在基于操作数据重新执行相应的数据操作后，重新启动连接池的对外服务功能。

在一种可能的实施方式中，异常恢复单元903，还用于：

若确定数据库操作功能处于正常状态，则检测集群的连接池所对应的对外服务功能是否处于异常状态；

若对外服务功能处于异常状态，则获取为对外服务功能配置的异常恢复策略，并基于异常恢复策略执行异常恢复处理。

在一种可能的实施方式中，异常检测单元901，具体用于：

若执行结果指示测试指令执行失败的次数超过设定数量阈值，则确定本节点的数据库操作功能处于异常状态；

若执行结果指示测试指令执行失败的次数未超过设定数量阈值，则对本节点的网络环境进行检测，以确认网络环境是否出现异常。

在一种可能的实施方式中，该装置还包括角色状态切换单元904，用于：

基于本节点与数据库之间的连接状态，确定本节点当前的角色状态信息；

若角色状态信息为备用管理节点，则执行地址解绑操作，以解除本节点与数据库的虚拟访问地址的绑定关系；

在检测到集群的数据库操作功能处于异常状态时，确定本节点是否满足切换为主管理节点的前置条件；

若满足，执行角色状态切换操作，以将本节点切换为主管理节点。

在一种可能的实施方式中，该装置还包括锁管理单元905，用于：

响应于针对集群进行的目标操作所触发的锁请求消息，从本节点获取相应的锁；其中，锁请求消息用于请求为目标操作分配锁，目标操作为针对集群进行的任意操作；

若锁请求消息为本节点中的本地应用所触发，则向除本节点之外的其他管理节点发起锁获取请求；

若除本节点之外的其他管理节点均成功返回锁，则输出指示锁请求消息获取锁成功的指示信息。

在一种可能的实施方式中，锁管理单元905，具体用于：

若锁请求消息为本节点中的本地应用所触发，则确认集群当前是否处于单节点模式；其中，单节点模式表征除本节点之外的其他管理节点均处于离线模式；

若未处于单节点模式，则除本节点之外的其他管理节点发起锁获取请求；

若处于单节点模式，则输出指示锁请求消息获取锁成功的指示信息。

在一种可能的实施方式中，锁管理单元905，还用于：

监测预设时长内是否接收到其他管理节点发送的心跳信息；

若未收到，则对其他管理节点进行离线检测，以确定其他管理节点是否处于离线模式；

若确定其他管理节点是否处于离线模式，则将本节点的运行模式切换为单节点模式。

在一种可能的实施方式中，锁管理单元905，还用于：

针对本节点记录的锁信息进行遍历，直至所有锁信息遍历结束为止，针对每一条锁信息，执行如下操作：

根据锁信息中的进程标识，确定锁信息对应的目标进程是否还存在；

若目标进程已不存在，且当前处于单节点模式时，释放本节点中锁信息对应的锁；

若目标进程已不存在，且当前未处于单节点模式时，则请求相应的管理节点释放锁信息对应的锁。

通过上述装置，实现了一套稳定的数据库集群的异常自动恢复和高可用方案，通过在主备管理节点进行针对不同场景的不同恢复操作，保障了系统的高可用，能够灵活地应对各种异常，大大减少了人力投入，并有良好的扩展性，并通过自实现的两节点分布式锁管理，解决了恢复操作之间及用户操作之间可能带来的冲突。

该装置可以用于执行本申请各实施例中所示的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考前述实施例的描述，不多赘述。

请参见图10，基于同一技术构思，本申请实施例还提供了一种计算机设备。在一种实施例中，该计算机设备可以为图1所示的管理节点，该计算机设备如图10所示，包括存储器1001，通讯模块1003以及一个或多个处理器1002。

存储器1001，用于存储处理器1002执行的计算机程序。存储器1001可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作集群，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。

存储器1001可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器1001也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；或者存储器1001是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1001可以是上述存储器的组合。

处理器1002，可以包括一个或多个中央处理单元(central processing unit，CPU)或者为数字处理单元等等。处理器1002，用于调用存储器1001中存储的计算机程序时实现上述数据库集群的管理控制方法。

通讯模块1003用于与终端设备和其他服务器进行通信。

本申请实施例中不限定上述存储器1001、通讯模块1003和处理器1002之间的具体连接介质。本申请实施例在图10中以存储器1001和处理器1002之间通过总线1004连接，总线1004在图10中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1004可以分为地址总线、数据总线、控制总线等。为便于描述，图10中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。

存储器1001中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的数据库集群的管理控制方法，处理器1002用于执行上述各实施例的数据库集群的管理控制方法。

基于同一发明构思，本申请实施例还提供一种存储介质，该存储介质存储有计算机程序，当该计算机程序在计算机上运行时，使得计算机执行本说明书上述描述的根据本申请各种示例性实施方式的数据库集群的管理控制方法中的步骤。

在一些可能的实施方式中，本申请提供的数据库集群的管理控制方法的各个方面还可以实现为一种计算机程序产品的形式，其包括计算机程序，当程序产品在计算机设备上运行时，计算机程序用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的数据库集群的管理控制方法中的步骤，例如，计算机设备可以执行各实施例的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的集群、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机程序，并可以在计算机设备上运行。然而，本申请的程序产品不限于此，在本申请件中，可读存储介质可以是任何包含或存储程序的有形介质，其包括的计算机程序可以被命令执行集群、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由命令执行集群、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的计算机程序，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、集群、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种数据库集群的管理控制方法，其特征在于，应用于分布式数据库集群包括的任一管理节点中，所述集群包含存储所述集群的元数据的至少两个管理节点，以及存储数据的多对数据节点，每一对数据节点包括主数据节点和备份数据节点；所述方法包括：

基于异常恢复指令的触发，执行数据库操作功能所对应的测试指令，获得相应的执行结果；其中，所述执行结果表征所述测试指令是否成功执行；

基于所述执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态；其中，所述角色状态信息用于表征本节点为主管理节点或者备用管理节点；

若确定本节点处于异常状态，则基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景；

获取为所述目标异常场景配置的异常恢复策略，并基于所述异常恢复策略执行异常恢复处理，以对所述数据库操作功能进行恢复。

2.如权利要求1所述的方法，其特征在于，基于异常恢复指令的触发，执行数据库操作功能所对应的测试指令，获得相应的执行结果，包括：

基于异常恢复指令的触发，根据所述至少两个管理节点各自的角色状态信息，确定是否存在多个管理节点为主管理节点；

若不存在多个管理节点为主管理节点，则执行数据库操作功能所对应的测试指令，获得相应的执行结果。

3.如权利要求2所述的方法，其特征在于，所述集群通过连接池对外提供服务；则在基于异常恢复指令的触发，根据所述至少两个管理节点各自的角色状态信息，确定是否存在多个管理节点为主管理节点之后，所述方法还包括：

若存在多个管理节点为主管理节点，则停止所述连接池的对外服务功能；

根据所述多个管理节点的数据操作进度，从所述多个管理节点中确定数据操作时间最靠后的目标管理节点；

若本节点并非所述目标管理节点，则将本节点的操作数据发送给所述目标管理节点，以使得所述目标管理节点在基于所述操作数据重新执行相应的数据操作后，重新启动所述连接池的对外服务功能。

4.如权利要求1所述的方法，其特征在于，在基于所述执行结果以及本节点的角色状态信息，确定本节点的数据库操作功能是否处于异常状态之后，所述方法还包括：

若确定所述数据库操作功能处于正常状态，则检测所述集群的连接池所对应的对外服务功能是否处于异常状态；

若所述对外服务功能处于异常状态，则获取为所述对外服务功能配置的异常恢复策略，并基于所述异常恢复策略执行异常恢复处理。

5.如权利要求1～4任一所述的方法，其特征在于，所述方法还包括：

基于本节点与数据库之间的连接状态，确定本节点当前的角色状态信息；

若所述角色状态信息为备用管理节点，则执行地址解绑操作，以解除本节点与数据库的虚拟访问地址的绑定关系；

在检测到所述集群的数据库操作功能处于异常状态时，确定本节点是否满足切换为主管理节点的前置条件；

若满足，执行角色状态切换操作，以将本节点切换为主管理节点。

6.如权利要求1～4任一所述的方法，其特征在于，所述方法还包括：

响应于针对所述集群进行的目标操作所触发的锁请求消息，从本节点获取相应的锁；其中，所述锁请求消息用于请求为所述目标操作分配锁，所述目标操作为针对所述集群进行的任意操作；

若所述锁请求消息为本节点中的本地应用所触发，则向除本节点之外的其他管理节点发起锁获取请求；

若除本节点之外的其他管理节点均成功返回锁，则输出指示所述锁请求消息获取锁成功的指示信息。

7.如权利要求6所述的方法，其特征在于，若所述锁请求消息为本节点中的本地应用所触发，则向除本节点之外的其他管理节点发起锁获取请求，包括：

若所述锁请求消息为本节点中的本地应用所触发，则确认所述集群当前是否处于单节点模式；其中，所述单节点模式表征除本节点之外的其他管理节点均处于离线模式；

若未处于单节点模式，则除本节点之外的其他管理节点发起锁获取请求；

若处于单节点模式，则输出指示所述锁请求消息获取锁成功的指示信息。

8.如权利要求6所述的方法，其特征在于，所述心跳信息携带了其他管理节点的锁信息，则所述方法还包括：

针对本节点记录的锁信息进行遍历，直至所有锁信息遍历结束为止，针对每一条锁信息，执行如下操作：

根据所述锁信息中的进程标识，确定所述锁信息对应的目标进程是否还存在；

若所述目标进程已不存在，且当前处于单节点模式时，释放本节点中所述锁信息对应的锁；

若所述目标进程已不存在，且当前未处于单节点模式时，则请求相应的管理节点释放所述锁信息对应的锁。

9.一种数据库集群的管理控制装置，其特征在于，应用于分布式数据库集群包括的任一管理节点中，所述集群包含存储所述集群的元数据的至少两个管理节点，以及存储数据的多对数据节点，每一对数据节点包括主数据节点和备份数据节点；所述装置包括：

异常检测单元，用于基于异常恢复指令的触发，执行数据库操作功能所对应的测试指令，获得相应的执行结果；其中，所述执行结果表征所述测试指令是否成功执行；以及，基于所述执行结果以及本节点的角色状态信息，确定本节点是否处于异常状态；其中，所述角色状态信息用于表征本节点为主管理节点或者备用管理节点；

异常场景检测单元，用于若确定本节点处于异常状态，则基于各个预设异常场景所对应的异常场景条件，确定本节点所满足异常场景条件的目标异常场景；

异常恢复单元，用于获取为所述目标异常场景配置的异常恢复策略，并基于所述异常恢复策略执行异常恢复处理，以对所述数据库操作功能进行恢复。

10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现权利要求1至8任一项所述方法的步骤。

Images