数据库的管理方法和装置

技术领域

本发明涉及互联网技术领域，特别涉及数据库的管理方法和装置。

背景技术

随着云计算和数据安全的发展，数据库的管理变得更加重要。例如，对于特性非常齐全的自由软件的对象-关系型数据库管理系统PostgreSQL，其通常利用开源工具套件repmgr管理PostgreSQL服务器集群中的复制和故障转移。通过repmgr可以实现集群的更高自动化搭建，省去一部分手动配置。

然后对于数据库来说，经常会出现节点故障的情况。比如，出现异步集群的主节点失效的情况。而出现的节点故障非常容易导致节点数据丢失。因此，有必要提供一种数据库的管理方案以解决上述不足。

发明内容

本发明提供了数据库的管理方法和装置，能够根据数据库集群的状态执行相应的处理策略，从而提高数据库系统的可靠性。

第一方面，本发明实施例提供了数据库的管理方法，包括：

定时对数据库执行心跳检测任务；

在执行所述心跳检测任务时，从所述数据库中读取集群节点的节点信息；其中，所述节点信息包括集群中各节点的主从关系；

根据所述心跳检测任务的结果和所述节点信息，确定节点的健康状态；

根据所述节点的健康状态，确定所述集群的状态；

根据所述集群的状态，执行相应的处理策略。

在一种可能的实现方式中，所述在执行所述心跳检测任务时从所述数据库中读取集群节点的节点信息，包括：

查询预设的故障转移记录表中是否存在满足故障转移失败条件的记录；其中，所述故障转移失败条件包括：在预设时间内至少连续N次执行故障转移操作失败；

若存在满足故障转移失败条件的记录，则将当前实例的状态更改为故障状态，并向用户发出故障告警；

若不存在满足故障转移失败条件的记录，则从管理侧数据库中读取当前实例的各节点的连接信息和主从关系。

在一种可能的实现方式中，所述根据所述心跳检测任务的结果和所述节点信息确定节点的健康状态，包括：

针对每一个节点均执行：

判断利用远程连接工具SSH是否成功在当前节点登录所述数据库的系统；

若无法成功在当前节点登录所述数据库的系统，则确定当前节点的健康状态为SSH登录故障；

若成功在当前节点登录所述数据库的系统，则判断所述当前节点是否具有虚拟IP；

若所述当前节点具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点正常；

若所述当前节点具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点异常；

若所述当前节点不具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点异常；

若所述当前节点不具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点正常。

在一种可能的实现方式中，根据各个所述节点的健康状态确定所述集群的状态，包括：

判断所有节点中主节点的数量是否大于1；

若所有节点中主节点的数量大于1，则确定所述数据库的集群存在集群脑裂故障；

若所有节点中主节点的数量不大于1，则判断所有节点中主节点和从节点的健康状态；

若主节点的健康状态为主节点正常，且存在从节点的健康状态为从节点异常，则确定所述集群的状态为从节点故障；

若主节点的健康状态为主节点异常，且存在从节点的健康状态为从节点异常，则确定所述集群的状态为集群故障；

若主节点和从节点的服务均正常，且虚拟IP在从节点上，则确定所述集群的状态为虚拟IP异常。

在一种可能的实现方式中，所述根据所述集群的状态执行相应的处理策略，包括：

若所述集群的状态为虚拟IP异常，则将虚拟IP挂载至集群的主节点网卡；

若所述集群的状态为从节点故障，则利用SSH登录至从节点虚机检查服务运行情况，并重启服务；

若所述集群的状态为集群脑裂故障，则重新配置集群中节点的主从关系；

若所述集群的状态为集群故障，则对主节点和从节点进行检查。

在一种可能的实现方式中，所述重新配置集群中节点的主从关系，包括：

在所述集群间的网络正常时，判断虚拟IP的数量；

若所述虚拟IP的数量为1，则将该虚拟IP所在的节点配置为新的主节点，并将其他节点配置为从节点后启动从节点的服务，以对各节点的主从关系进行检测；

若所述虚拟IP的数量不为1，则将预先设定的初始主节点配置为新的主节点，并将其他节点配置为从节点后启动从节点的服务，以对各节点的主从关系进行检测。

在一种可能的实现方式中，所述对主节点和从节点进行检查，包括：

利用SSH登录至主节点，并尝试启动主节点的服务；

在所述主节点启动成功后检查所述集群间的网络状况；

在所述网络状况通畅时，重启各从节点的服务进程；

针对每一个从节点，在该从节点启动成功后，从主节点调用预设的方法查看当前从节点的主从关系是否正确。

第二方面，本发明实施例提供了数据库的管理装置，包括：心跳检测模块、信息读取模块、节点状态确定模块、集群状态确定模块和策略执行模块；

所述心跳检测模块，配置为定时对数据库执行心跳检测任务；

所述信息读取模块，配置为在所述心跳检测模块执行所述心跳检测任务时，从所述数据库中读取集群节点的节点信息；其中，所述节点信息包括集群中各节点的主从关系；

所述节点状态确定模块，配置为根据所述心跳检测任务的结果和所述信息读取模块读取的所述节点信息，确定节点的健康状态；

所述集群状态确定模块，配置为根据所述节点状态确定模块确定的所述节点的健康状态，确定所述集群的状态；

所述策略执行模块，配置为根据所述集群状态确定模块确定的所述集群的状态，执行相应的处理策略。

在一种可能的实现方式中，所述述信息读取模块在执行所述心跳检测任务并从所述数据库中读取集群节点的节点信息时，配置成执行如下操作：

查询预设的故障转移记录表中是否存在满足故障转移失败条件的记录；其中，所述故障转移失败条件包括：在预设时间内至少连续N次执行故障转移操作失败；

若存在满足故障转移失败条件的记录，则将当前实例的状态更改为故障状态，并向用户发出故障告警；

若不存在满足故障转移失败条件的记录，则从管理侧数据库中读取当前实例的各节点的连接信息和主从关系。

在一种可能的实现方式中，所述节点状态确定模块在根据所述心跳检测任务的结果和所述节点信息确定节点的健康状态时，配置成针对每一个节点均执行如下操作：

判断利用远程连接工具SSH是否成功在当前节点登录所述数据库的系统；

若无法成功在当前节点登录所述数据库的系统，则确定当前节点的健康状态为SSH登录故障；

若成功在当前节点登录所述数据库的系统，则判断所述当前节点是否具有虚拟IP；

若所述当前节点具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点正常；

若所述当前节点具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点异常；

若所述当前节点不具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点异常；

若所述当前节点不具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点正常。

由上述技术方案可知，在对数据库进行管理时，首先可以定时对数据库执行心跳检测任务。在执行心跳检测任务时，从数据库中读取集群节点的节点信息。然后根据心跳检测任务的结果和节点信息确定节点的健康状态，并根据节点的健康状态确定集群的状态。进一步，根据集群的状态即可执行相应的处理策略。由此可见，本方案通过心跳检测可以确定出节点和集群的健康状态等情况，从而采取相应的策略进行处理。如此当集群和节点出现故障等情况时能够及时进行处理，从而能够提高数据库系统的可靠性。

附图说明

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

图1是本发明一个实施例提供的一种数据库的管理方法的流程图；

图2是本发明一个实施例提供的一种数据库的管理装置的结构示意图。

具体实施方式

PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统，常见的PostgreSQL高可用集群搭建有以下几种方式。

(1)使用PostgreSQL 9.0及更高版本自带的流复制工具搭建主从集群。该方式需要手动将主从关系写到配置文件中放到从节点指定目录下，配置较为繁琐，并且不能在主节点失效时提供自动故障转移功能，易用性较差，并且可靠性较低

(2)使用pgpool-II搭建高可用集群。pgpool-II是一个位于PostgreSQL服务器和PostgreSQL数据库客户端之间的中间件，它提供连接池、主从复制、负载均衡等功能。Pgpool-II功能非常丰富，但同时带来的问题是配置更加繁琐，在保证PostgreSQL原生配置的基础上增加了一套pgpool的配置文件，并且额外增加了一套用户认证系统，默认情况下用户需要先后经过pgpool与PostgreSQL数据库的两层认证，管理不方便。并且，pgpool对vip的处理并不跟随PostgreSQL主节点，而是跟随pgpool内的watchdog主节点，不符合大多数实际使用情况。

(3)使用repmgr。repmgr是一个开源工具套件，用于管理PostgreSQL服务器集群中的复制和故障转移。它使用工具来增强PostgreSQL的内置热备份功能，以设置备用服务器，监控复制以及执行管理任务。Repmgr相对于pgpool来说更轻量化，配置相对更简单，并且可以通过repmgr实现集群的更高自动化搭建，省去一部分手动配置操作。Repmgr也可实现集群的自动故障转移，但是对于异步集群的主节点失效情况处理，可能会导致部分主节点数据丢失，并且repmgr无法处理集群脑裂问题与vip异常问题。

基于此，本方案提供的数据库的管理方案，可以应用于基于repmgr的分离式的PostgreSQL数据库高可用系统，通过心跳检测、处理策略的故障处理等，能够提高系统的可靠性。

如图1所示，本发明实施例提供了一种数据库的管理方法，该方法可以包括如下步骤：

步骤101：定时对数据库执行心跳检测任务；

步骤102：在执行心跳检测任务时，从数据库中读取集群节点的节点信息；其中，节点信息包括集群中各节点的主从关系；

步骤103：根据心跳检测任务的结果和节点信息，确定节点的健康状态；

步骤104：根据节点的健康状态，确定集群的状态；

步骤105：根据集群的状态，执行相应的处理策略。

本发明实施例中，在对数据库进行管理时，首先可以定时对数据库执行心跳检测任务。在执行心跳检测任务时，从数据库中读取集群节点的节点信息。然后根据心跳检测任务的结果和节点信息确定节点的健康状态，并根据节点的健康状态确定集群的状态。进一步，根据集群的状态即可执行相应的处理策略。由此可见，本方案通过心跳检测可以确定出节点和集群的健康状态等情况，从而采取相应的策略进行处理。如此当集群和节点出现故障等情况时能够及时进行处理，从而能够提高数据库系统的可靠性。

比如，对于基于repmgr的分离式的postgresql数据库高可用系统，可以分别在虚机内和管理侧部署两套系统，虚机内使用repmgr搭建集群并提供基本故障转移功能，管理侧系统持续心跳检测，并对集群脑裂与vip异常等repmgr无法解决的情况作相应处理，两个系统互相补充，提供更可靠的高可用系统。

具体地，可以使用docker将PostgreSQL+repmgr封装至一个镜像，并且内置启动脚本、故障转移脚本、通知事件脚本等脚本，启动容器时将执行启动脚本，启动脚本接收启动参数然后组建集群并开启自动故障转移功能，此时repmgr之间的通信与PostgreSQL使用同一网络。主节点故障时调用故障转移脚本将当前节点提升为主节点，然后调用通知事件脚本通知管理系统侧。

管理侧系统使用另一管理网监测所有PostgreSQL节点心跳，通过判断各节点是否可以ssh登录、PostgreSQL服务状态及主从角色、虚拟IP(vip)挂载情况得出该节点的健康状态，然后通过汇总各节点状态分析得出集群状态，并对各种故障情况做出分别处理。

在一种可能的实现方式中，步骤102在执行心跳检测任务时从数据库中读取集群节点的节点信息时，可以通过如下方式实现：

查询预设的故障转移记录表中是否存在满足故障转移失败条件的记录；其中，故障转移失败条件包括：在预设时间内至少连续N次执行故障转移操作失败；

若存在满足故障转移失败条件的记录，则将当前实例的状态更改为故障状态，并向用户发出故障告警；

若不存在满足故障转移失败条件的记录，则从管理侧数据库中读取当前实例的各节点的连接信息和主从关系。

本实施例中，在执行心跳检测任务时，首先可以查询故障转移记录表是否有满足故障转移失败条件的记录。如果有，则说明当前故障系统无法处理，因而可以向用户发出故障警告，以提醒用户及时进行处理。而如果没有，则可以读取集群各节点的连接信息和主从关系，从而完成相应的故障处理流程。

比如，在执行心跳任务时，先查询故障转移记录表中的数据，查看是否在30分钟之内存在连续三次以上的故障转移并且均失败的情况，如果存在，则说明出现了本系统无法处理的故障情况，此时更改实例状态为故障并向用户发出告警。如果不存在上述情况，则从管理侧数据库中读取PostgreSQL实例各节点的连接信息及主从关系。

在一种可能的实现方式中，步骤103在根据心跳检测任务的结果和节点信息确定节点的健康状态时，可以针对每一个节点通过如下方式实现：

判断利用远程连接工具SSH是否成功在当前节点登录数据库的系统；

若无法成功在当前节点登录数据库的系统，则确定当前节点的健康状态为SSH登录故障；

若成功在当前节点登录数据库的系统，则判断当前节点是否具有虚拟IP；

若当前节点具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点正常；

若当前节点具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点异常；

若当前节点不具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点异常；

若当前节点不具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点正常。

本实施例中，在判断节点的健康状态时，首先可以判断该节点是否可以利用远程连接工具进行登录，从而判断是否存在登录故障。进而可以根据节点为主从关系，以及节点所具有的虚拟IP判断当前节点是否具有异常。如此能够准确地判断出各节点的异常情况，从而可以准确地采取相应的措施进行处理，保证故障处理的准确性。

比如，在进行节点的状态检测时，可以依次通过管理网使用SSH连接各节点，并保存SSH是否成功。管理网与用户服务网是两套网络，互不影响，管理网只用于运维管理，如果该网络通信异常，则管理侧系统认为虚机的SSHReachable为false，并且无法检测到集群的具体状态，也不能断定集群的服务出现异常，此时不会认为是一种集群故障。

然后登录当前节点PostgreSQL(pg)服务，并使用pg自带函数pg_is_in_recovery查询当前节点的主从角色，t表示从，f表示主，记录该数据。

进一步，查询当前节点是否有vip，记录该数据。当心跳检测完成，汇总上述所有数据返回至管理侧。管理侧系统分析以上几组数据，得出该节点的健康状态，分析过程如下：

①判断SSH状态，成功进行下一步，不正常返回该节点无法通过SSH登录；

②如果该节点pg_is_in_recovery＝f且存在vip，则返回主节点正常；

③如果该节点pg_is_in_recovery＝f且不存在vip，则返回主节点vip异常；

④如果该节点pg_is_in_recovery＝t且不存在vip，则返回从节点正常；

⑤如果该节点pg_is_in_recovery＝t且存在vip，则返回从节点vip异常；

在一种可能的实现方式中，步骤104在根据各个节点的健康状态确定集群的状态时，可以通过如下方式实现：

判断所有节点中主节点的数量是否大于1；

若所有节点中主节点的数量大于1，则确定数据库的集群存在集群脑裂故障；

若所有节点中主节点的数量不大于1，则判断所有节点中主节点和从节点的健康状态；

若主节点的健康状态为主节点正常，且存在从节点的健康状态为从节点异常，则确定集群的状态为从节点故障；

若主节点的健康状态为主节点异常，且存在从节点的健康状态为从节点异常，则确定集群的状态为集群故障；

若主节点和从节点的服务均正常，且虚拟IP在从节点上，则确定集群的状态为虚拟IP异常。

本实施例中，在确定集群状态时，首先可以根据集群中主节点的数量判断集群是否存在集群脑裂的故障。然后可以根据主节点和从节点的异常情况，判断集群的状态。如此能够清除地分析出集群当前的状态，从而能够选择合适的处理策略对集群的故障进行处理。

比如，在确定集群状态时，可以分析所有节点的数据得出集群状态，当所有节点服务状态正常并且只有一个主节点并且只有该节点存在vip时，认为当前集群状态正常(NORMAL)，且心跳检测结束。否则，执行故障切换流程。

具体在判断集群状态类型时，可以包括：

①如果主节点数量大于1，则认为是集群脑裂(POSTGRESQL_CLUSTER_SPLIT_BRAIN)；

②否则看从节点状态是否正常，主节点正常从节点故障则认为是从节点故障(STANDBY_DB_DOWN)；

③主节点和从节点都故障则认为集群故障，或宕机(ALL_DOWN)；

④主从节点服务均正常但是vip在从节点上，则认为是vip异常(VIP_ABNORMAL)；

由于repmgr的存在可以实现主节点宕机时的简单自动故障切换，策略为将损坏的主节点踢出集群，将原从节点提升为新主节点，所以本方案不会出现集群主节点宕机的情况，一定程度上提高了故障切换的响应速度，缩短了故障存在时间，提高了高可用性。

在一种可能的实现方式中，在步骤105根据集群的状态执行相应的处理策略时，可以通过如下方式实现：

若集群的状态为虚拟IP异常，则将虚拟IP挂载至集群的主节点网卡；

若集群的状态为从节点故障，则利用SSH登录至从节点虚机检查服务运行情况，并重启服务；

若集群的状态为集群脑裂故障，则重新配置集群中节点的主从关系；

若集群的状态为集群故障，则对主节点和从节点进行检查。

在本实施例中，通过针对不同的集群故障采取不同的处理策略，能够准确地对当前集群故障进行处理，保证了系统的可靠性。

而在实现上述重新配置集群中节点的主从关系的操作时，具体可以通过如下方式实现：

在集群间的网络正常时，判断虚拟IP的数量；

若虚拟IP的数量为1，则将该虚拟IP所在的节点配置为新的主节点，并将其他节点配置为从节点后启动从节点的服务，以对各节点的主从关系进行检测；

若虚拟IP的数量不为1，则将预先设定的初始主节点配置为新的主节点，并将其他节点配置为从节点后启动从节点的服务，以对各节点的主从关系进行检测。

本实施例中，在重新配置集群中节点的主从关系时，首先可以判断虚拟IP的数量，如果数量为1，则可以以该虚拟IP所在的节点为主节点，其他节点为从节点，实现节点的重新配置。而如果数量不为1，则可以将最初始的主节点配置为新的主节点，并将其他节点配置为从节点。由于一个集群中只能存在一个主节点，因此通过本实施例可以保证主节点的唯一性，避免出现集群脑裂的故障。

在一种可能的实现方式中，在实现上述对主节点和从节点进行检查的操作时，具体可以通过如下方式实现：

利用SSH登录至主节点，并尝试启动主节点的服务；

在主节点启动成功后检查集群间的网络状况；

在网络状况通畅时，重启各从节点的服务进程；

针对每一个从节点，在该从节点启动成功后，从主节点调用预设的方法查看当前从节点的主从关系是否正确。

本实施例中，当集群状态为集群故障时，可以利用SSH登录到主节点，并尝试启动主节点的服务。如果主节点的服务能够启动，则在集群网络通常的情况下重启各从节点的服务进程。如果从节点能够启动，则可以从主节点调用相应的方法对当前节点的主从关系进行检查。如此保证了每个节点主从关系的正确性。

比如，在根据集群的状态执行相应的处理策略时，具体可以包括：

①如果故障类型为vip异常(VIP_ABNORMAL)，则使用ifconfig命令主动将vip挂载至主节点eth0网卡。

②如果故障类型为从节点故障(STANDBY_DB_DOWN)，则SSH至从节点虚机检查服务运行情况，尝试重启服务。

③如果故障类型为集群宕机(ALL_DOWN)，则先利用SSH登录至主节点，尝试启动主节点服务，主节点成功启动后检查集群间网络状况，网络通畅时重启从节点服务进程。启动成功后分别在主从节点调用pg_is_in_recovery方法查看当前节点角色是否正确。

④如果故障类型为集群脑裂(POSTGRESQL_CLUSTER_SPLIT_BRAIN)，先判断集群间网络是否通畅，通畅时进行下一步，重新配置集群主从关系，以存在vip的节点为主，如果两个节点均不存在或均存在vip，则使用初始主节点作为新主节点。然后重新启动从节点服务，启动后分别在主从节点调用pg_is_in_recovery方法查看当前节点角色是否正确。

故障切换执行完毕后立即执行一遍心跳检测判断故障切换的结果并记录，同时根据心跳结果中的主从关系更新数据库对应数据。

由此可见，对于基于repmgr的分离式的postgresql数据库高可用系统，分别在虚机内和管理侧部署两套系统，虚机内使用repmgr搭建集群并提供基本故障转移功能，管理侧系统持续心跳检测，能够对集群脑裂与vip异常等repmgr无法解决的情况作相应处理。而且，两个系统互相补充，保证系统的高可靠性和数据安全。

如图2所示，提供了一种数据库的管理装置，包括：心跳检测模块201、信息读取模块202、节点状态确定模块203、集群状态确定模块204和策略执行模块205；

心跳检测模块201，配置为定时对数据库执行心跳检测任务；

信息读取模块202，配置为在心跳检测模块201执行心跳检测任务时，从数据库中读取集群节点的节点信息；其中，节点信息包括集群中各节点的主从关系；

节点状态确定模块203，配置为根据心跳检测任务的结果和信息读取模块202读取的节点信息，确定节点的健康状态；

集群状态确定模块204，配置为根据节点状态确定模块203确定的节点的健康状态，确定集群的状态；

策略执行模块205，配置为根据集群状态确定模块204确定的集群的状态，执行相应的处理策略。

在一种可能的实现方式中，述信息读取模块202在执行心跳检测任务并从数据库中读取集群节点的节点信息时，配置成执行如下操作：

查询预设的故障转移记录表中是否存在满足故障转移失败条件的记录；其中，故障转移失败条件包括：在预设时间内至少连续N次执行故障转移操作失败；

若存在满足故障转移失败条件的记录，则将当前实例的状态更改为故障状态，并向用户发出故障告警；

若不存在满足故障转移失败条件的记录，则从管理侧数据库中读取当前实例的各节点的连接信息和主从关系。

在一种可能的实现方式中，节点状态确定模块203在根据心跳检测任务的结果和节点信息确定节点的健康状态时，配置成针对每一个节点均执行如下操作：

判断利用远程连接工具SSH是否成功在当前节点登录数据库的系统；

若无法成功在当前节点登录数据库的系统，则确定当前节点的健康状态为SSH登录故障；

若成功在当前节点登录数据库的系统，则判断当前节点是否具有虚拟IP；

若当前节点具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点正常；

若当前节点具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点异常；

若当前节点不具有虚拟IP且该当前节点为主节点，则确定当前节点的健康状态为主节点异常；

若当前节点不具有虚拟IP且该当前节点为从节点，则确定当前节点的健康状态为从节点正常。

在一种可能的实现方式中，集群状态确定模块204在根据各个节点的健康状态确定集群的状态时，配置成执行如下操作：

判断所有节点中主节点的数量是否大于1；

若所有节点中主节点的数量大于1，则确定数据库的集群存在集群脑裂故障；

若所有节点中主节点的数量不大于1，则判断所有节点中主节点和从节点的健康状态；

若主节点的健康状态为主节点正常，且存在从节点的健康状态为从节点异常，则确定集群的状态为从节点故障；

若主节点的健康状态为主节点异常，且存在从节点的健康状态为从节点异常，则确定集群的状态为集群故障；

若主节点和从节点的服务均正常，且虚拟IP在从节点上，则确定集群的状态为虚拟IP异常。

在一种可能的实现方式中，策略执行模块205在根据集群的状态执行相应的处理策略时，配置成执行如下操作：

若集群的状态为虚拟IP异常，则将虚拟IP挂载至集群的主节点网卡；

若集群的状态为从节点故障，则利用SSH登录至从节点虚机检查服务运行情况，并重启服务；

若集群的状态为集群脑裂故障，则重新配置集群中节点的主从关系；

若集群的状态为集群故障，则对主节点和从节点进行检查。

在一种可能的实现方式中，策略执行模块205在重新配置集群中节点的主从关系时，配置成执行如下操作：

在集群间的网络正常时，判断虚拟IP的数量；

若虚拟IP的数量为1，则将该虚拟IP所在的节点配置为新的主节点，并将其他节点配置为从节点后启动从节点的服务，以对各节点的主从关系进行检测；

若虚拟IP的数量不为1，则将预先设定的初始主节点配置为新的主节点，并将其他节点配置为从节点后启动从节点的服务，以对各节点的主从关系进行检测。

在一种可能的实现方式中，策略执行模块205在对主节点和从节点进行检查时，配置成执行如下操作：

利用SSH登录至主节点，并尝试启动主节点的服务；

在主节点启动成功后检查集群间的网络状况；

在网络状况通畅时，重启各从节点的服务进程；

针对每一个从节点，在该从节点启动成功后，从主节点调用预设的方法查看当前从节点的主从关系是否正确。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行本方案中任一个实施例中的方法。

本说明书还提供了一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现本方案中任一个实施例中的方法。

可以理解的是，本方案实施例示意的结构并不构成对数据库的管理装置的具体限定。在说明书的另一些实施例中，数据库的管理装置可以包括比图示更多或者更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或者软件和硬件的组合来实现。

需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个······”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储在计算机可读取的存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质中。

上述装置内的各单元之间的信息交互、执行过程等内容，由于与本方案方法实施例基于同一构思，具体内容可参见本方案方法实施例中的叙述，此处不再赘述。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本方案所描述的功能可以用硬件、软件、挂件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本方案描述的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。