CN114443341A - 宕机服务器的探测方法、数据库的高可用恢复方法及装置 - Google Patents

Abstract

本发明提供了一种宕机服务器的探测方法、数据库的高可用恢复方法及装置，该探测方法包括：获取服务器集群的多个服务器的服务器状态信息，服务器状态信息由部署在服务器上的探测客户端采集并上传到探测服务端；当服务器集群中的目标服务器对应的服务器状态信息满足预设异常条件时，判断目标服务器疑似宕机；由探测服务端的任意一个或多个探测服务端节点对疑似宕机的目标服务器上指定端口进行端口状态探测，根据端口状态探测的结果判定目标服务器是否宕机。利用上述方法，能够快速发现服务器集群中的宕机服务器。

Description

宕机服务器的探测方法、数据库的高可用恢复方法及装置

技术领域

本发明属于数据库领域，具体涉及一种宕机服务器的探测方法、数据库的高可用恢复方法及装置。

背景技术

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

随着现代计算机科学技术的发展,数据库已逐步成为计算机信息系统的基础和核心,被广泛应用于电信、金融、政府等行业。数据库应用的高可用性也越来越引起人们的关注。现有技术中，关系型数据库高可用模式有较多种类，常见的有一主多从、主从、MGR集群、冷备和共享存储等。上述高可用架构都有其优缺点，适用于不同的业务场景，但是无论是任何高可用架构，在服务器宕机的期间未恢复期间都会所有降低。

主从架构是其中最广泛的一种数据库高可用架构。这种架构有主库和备库共两个数据库实例组成。正常情况下，由主数据库(称为主库)对外服务。主库上如果有对数据的更改，则会在把更改写入数据库存储前，先写入到事务日志中。主数据库服务器产生的日志，不断通过网络连接，发送给从数据库服务器(称为备库)。从数据库服务器接收到日志后，将其进行回放，以使其数据跟主数据库服务器同步。在主数据库服务器发生宕机等无法对外服务时，需要切换到从数据库，由从数据库继续提供服务，从而实现高可用性。这种数据库架构因配置简单灵活、资源使用率较高、主备切换成功率高，被广泛接受并且用于生产环境。

主从架构的数据库在主库服务器故障后，使用原来的从库对外服务，在主库服务器恢复之前，数据库一直是单点对外服务，这个过程可能持续若干小时或者更长时间，这期间高可用完全失效，存在较大的隐患。

在规模较大的数据中心，每天都会出现服务器宕机或者硬件故障。在服务器故障后，能够快速识别出宕机服务器，并且快速恢复数据库原来的主从架构，降低数据库单点运行的时间，成为亟待解决的问题。

发明内容

针对上述现有技术中存在的问题，提出了一种宕机服务器的探测方法、数据库的高可用恢复方法、装置及计算机可读存储介质，利用这种方法、装置及计算机可读存储介质，能够解决上述问题。

本发明提供了以下方案。

第一方面，提供一种宕机服务器的探测方法，所述方法应用于探测服务端，所述探测服务端包括集群式的多个探测服务端节点，所述探测服务端连接至多个探测客户端，所述多个探测客户端分别部署在服务器集群中的多个服务器上，所述方法包括：获取所述服务器集群的多个服务器的服务器状态信息，所述服务器状态信息由部署在所述服务器上的所述探测客户端采集并上传到所述探测服务端；当所述服务器集群中的目标服务器对应的所述服务器状态信息满足预设异常条件时，判断所述目标服务器疑似宕机；由所述探测服务端的任意一个或多个探测服务端节点对疑似宕机的所述目标服务器上指定端口进行端口状态探测，根据所述端口状态探测的结果判定所述目标服务器是否宕机。

在一实施例中，所述判断所述目标服务器疑似宕机，还包括：当检测到所述目标服务器对应的所述服务器状态信息满足所述预设异常条件时，向所述探测服务端中的多个所述探测服务端节点发起异常判决请求，所述异常判决请求用于判断所述目标服务器的所述服务器状态是否异常；当所述探测服务端中超过预设比例的所述探测服务端节点均判定所述目标服务器的服务器状态异常时，判断所述目标服务器疑似宕机。

在一实施例中，所述端口状态探测，还包括：通过ICMP协议检测所述目标服务器上指定端口的端口状态。

在一实施例中，所述指定端口包括：SSH端口和/或docker端口。

在一实施例中，所述预设异常条件为：所述探测服务端中的任意一个探测服务端节点接收到所述目标服务器的服务器异常信息；和/或，所述探测服务端在超过预设次数的心跳周期内，未收到部署在所述目标服务器上的所述探测客户端上送的心跳。

在一实施例中，对疑似宕机的所述目标服务器上指定端口进行端口状态探测，还包括：按照设定频率对疑似宕机的所述目标服务器上的指定端口进行持续探测；当所述端口探测连续失败超过设定次数时，判定所述目标服务器宕机；当所述端口状态探测连续失败未超过设定次数时，判定所述目标服务器正常。

在一实施例中，当所述端口探测连续失败超过设定次数时，还包括：查询指定时间范围内所述目标服务器对应的宕机事件和/或恢复事件；在所述目标服务器不存在宕机事件的情况下，和/或，所述目标服务器对应的宕机事件与恢复事件的数量一致的情况下，生成对应于所述目标服务器的宕机事件。

在一实施例中，当所述端口探测连续失败未超过设定次数时，还包括：查询指定时间范围内所述目标服务器标识的宕机事件和/或恢复事件；在所述目标服务器对应的宕机事件与恢复事件的数量不一致的情况下，判定所述目标服务器对应的目标服务器从宕机恢复正常，并生成对应于所述目标服务器的恢复事件。

第二方面，提供一种宕机服务器的探测服务端，所述探测服务端被配置为执行如权利要求1-8中任一项所述的方法，其中，所述探测服务端包括多个探测服务端节点，所述探测服务端连接至多个探测客户端，所述多个探测客户端分别部署在服务器集群中的多个服务器上；所述探测服务端，被配置为用于：获取所述服务器集群的多个服务器的服务器状态信息，所述服务器状态信息由部署在所述服务器上的所述探测客户端采集并上传到所述探测服务端；当所述服务器集群中的目标服务器对应的所述服务器状态信息满足预设异常条件时，判断所述目标服务器疑似宕机；由所述探测服务端的任意一个探测服务端节点对疑似宕机的所述目标服务器上指定端口进行端口状态探测，根据所述端口状态探测的结果判定所述目标服务器是否宕机。

第三方面，提供一种数据库的高可用恢复方法，所述方法包括：确定宕机服务器，所述宕机服务器上部署有第一数据库容器；在所述宕机服务器所在服务器集群中寻找满足重建条件的迁移服务器；在所述迁移服务器上创建第二服务器容器，所述第二服务器容器与所述第一数据库容器具有相同的容器配置；获取所述第一数据库容器的数据库配置文件，解析获得数据库配置信息，将所述数据库配置信息持久化到所述第二服务器容器中，并在所述第一服务器容器中进行数据库初始化；获取所述第一数据库容器的备份镜像，根据所述备份镜像在所述第二数据库容器中进行数据库还原；搭建所述第二数据库容器到当前主库容器的复制关系以同步数据，其中，所述当前主库容器与所述第一数据库容器在所述宕机服务器宕机之前具有主备关系。

在一实施例中，所述方法包括：利用第一方面的方法从服务器集群中确定所述宕机服务器。

在一实施例中，确定发生宕机事件的宕机服务器，包括：周期性地查询数据库管理平台，以确定服务器范围；查询所述服务器范围内的服务器宕机事件，以确定所述宕机服务器。

在一实施例中，确定宕机的宕机服务器之后，还包括：在数据库管理平台中查询所述宕机服务器上部署的所述第一数据库容器的容器类型；根据所述容器类型判断是否允许对所述第一数据库容器进行重建。

在一实施例中，在所述宕机服务器所在服务器集群中寻找满足重建条件的迁移服务器，还包括：根据所述每个服务器的动态指标评价因子和/或静态指标评价因子，从所述服务器集群中确定满足重建条件的所述迁移服务器；其中，所述静态指标评价因子包括如下中的一种或多种：业务维度指标、软件维度指标、资源分配率；所述动态指标评价因子包括如下中的一种或多种：CPU使用率、CPU波动率、CPU单日内最大值、内存使用率、磁盘使用率、磁盘的每秒输入输出值、磁盘最大延迟、网卡流量。

在一实施例中，还包括：周期性获取所述服务器集群中每个服务器的所述静态评价因子；当检测所述服务器集群中发生服务器宕机时，实时获取所述服务器集群中每个服务器的所述动态指标评价因子。

在一实施例中，还包括：根据一种或多种所述静态指标评价因子和一种或多种所述动态指标评价因子的加权求和结果，从所述服务器集群中确定满足重建条件的所述迁移服务器。

在一实施例中，获取所述第一数据库容器的数据库配置文件，解析获得数据库配置信息，还包括：将查询到的所述数据库配置文件中的参数转换为多个键值对数据；按照数据库全量参数模板过滤所述多个键值对数据，以得到所述数据库配置信息；将所述键值对数据作为所述数据库配置信息存储在缓存数据库(REDIS)中；其中，所述按照数据库全量参数模板过滤所述多个键值对数据包括：当所述数据库全量参数模板不包含任一键值对数据中的键时，丢弃所述任一键值对。

在一实施例中，所述容器配置包括：镜像名称，容器名称，容器的CPU、内存、文件系统和IP地址中的一种或多种。

第四方面，提供一种数据库的高可用恢复装置，该装置被配置为执行如第三方面的方法，所述装置包括：宕机服务器确定模块，用于确定宕机服务器，所述宕机服务器上部署有第一数据库容器；迁移服务器确定模块，用于在所述目标服务器所在服务器集群中寻找满足重建条件的迁移服务器；容器创建模块，用于在所述迁移服务器上创建第二服务器容器，所述第二服务器容器与所述第一数据库容器具有相同的容器配置；数据库初始化模块，用于获取所述第一数据库容器的数据库配置文件，解析获得数据库配置信息，将所述数据库配置信息持久化到所述第二服务器容器中，并在所述第一服务器容器中进行数据库初始化；数据库还原模块，用于获取所述第一数据库容器的备份镜像，根据所述备份镜像在所述第二数据库容器中进行数据库还原；数据库同步模块，用于搭建所述第二数据库容器到当前主库容器的复制关系以同步数据，其中，所述当前主库容器与所述第一数据库容器在所述目标服务器宕机之前具有主备关系。

第五方面，提供一种宕机服务器的探测装置，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行：如第一方面的方法。

第六方面，提供一种数据库的高可用恢复装置，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行：如第三方面的方法。

第七方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有程序，当所述程序被多核处理器执行时，使得所述多核处理器执行如第一方面的方法或者第二方面的方法。

上述实施例的优点之一，通过上述宕机服务器的探测方法，能够可以提高较大规模服务器集群中进行宕机探测的效率以及降低误报率，可以理解，发现宕机服务器是进行高可用恢复的基础，因此本实施例能够提升高可用恢复的效率。通过上述数据库的高可用恢复方法，不用等待服务器从故障中恢复，就能够恢复数据库原来高可用架构，提升了数据库服务整体高可用能力。

本发明的其他优点将配合以下的说明和附图进行更详细的解说。

应当理解，上述说明仅是本发明技术方案的概述，以便能够更清楚地了解本发明的技术手段，从而可依照说明书的内容予以实施。为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举例说明本发明的具体实施方式。

附图说明

通过阅读下文的示例性实施例的详细描述，本领域普通技术人员将明白本文所述的优点和益处以及其他优点和益处。附图仅用于示出示例性实施例的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的标号表示相同的部件。在附图中：

图1为根据本发明一实施例的宕机服务器的探测系统的系统架构图；

图2为根据本发明一实施例的宕机服务器的探测方法的流程示意图；

图3为根据本发明另一实施例的宕机服务器的探测方法的流程示意图；

图4为根据本发明一实施例的数据库的高可用恢复方法的流程示意图；

图5为根据本发明一实施例的数据库主备关系的结构示意图；

图6为根据本发明一实施例的数据库的高可用恢复装置的结构示意图；

图7为根据本发明一实施例的数据库的宕机服务器的探测装置的结构示意图；

图8为根据本发明一实施例的数据库的高可用恢复装置的结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域技术人员。

在本申请实施例的描述中，应理解，诸如“包括”或“具有”等术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不旨在排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在的可能性。

除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”等的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本申请中的所有代码都是示例性的，本领域技术人员根据所使用的编程语言，具体的需求和个人习惯等因素会在不脱离本申请的思想的条件下想到各种变型。

另外还需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

图1示出了本申请一实施例的宕机服务器的探测系统的结构示意图，该探测系统包括：探测服务端20和多个探测客户端(31～36)，其中多个探测客户端分别部署在服务器集群10中的多个服务器上(11～16)，该探测组件用于从服务器集群10中的多个服务器中快速探测出可能发生宕机的服务器。

图2为根据本申请一实施例的宕机服务器的探测方法的流程示意图，用于快速从大规模的服务器集群找到宕机服务器，在该流程中，从设备角度而言，执行主体可以是一个或者多个电子设备；从程序角度而言，执行主体相应地可以是搭载于这些电子设备上的程序。在本实施例中，方法的执行主体可以是图1所示实施例中的探测服务端20。

如图2所示，本实施例提供的方法可以包括以下步骤：

S202、获取服务器集群的多个服务器的服务器状态信息。

参考图1，比如由多个探测客户端(31～36)定期采集所在服务器(11～16)的服务器状态信息，并上传至探测服务端20。该服务器状态信息比如可以是：服务器的状态、内存使用情况、心跳版本号等状态信息。

S204、当服务器集群中的目标服务器对应的服务器状态信息满足预设异常条件时，判断目标服务器疑似宕机。

参考图1，可在探测服务端20内部执行该S204。具体地，可以循环查询循环每个服务器的服务器状态信息。针对任意服务器，如果能够查询到该服务器的服务器状态信息为正常状态，则无需触发后续的探测，以提升效率。

在一实施例中，上述预设异常条件包括：探测服务端中的任意一个探测服务端节点接收到目标服务器的服务器异常信息；和/或，探测服务端的每个探测服务端节点在超过预设次数的心跳周期内，均未收到部署在目标服务器上的探测客户端上送的心跳。可以理解，这两种情况均能在一定程度上指示该目标服务器可能发生宕机。

S206、由探测服务端的任意一个或多个探测服务端节点对疑似宕机的目标服务器上指定端口进行端口状态探测，并根据端口状态探测的结果判定目标服务器是否宕机。

参考图1，比如，如探测服务端通过上述S204判断服务器13疑似宕机，可以每十秒钟一次，总共六次的对该服务器13上端口的探测。进而根据对端口的探测结果确定该服务器13是否为宕机服务器。

在一实施例中，可以通过ICMP协议检测目标服务器上指定端口的端口状态。可选地，指定端口可以包括：SSH端口和/或docker端口。

可以理解，探测客户端本身异常或者探测服务端和探测客户端之间的网络波动同样可能导致将正常服务器错判断为疑似宕机，针对这种情况，本实施例在探测服务端将某个服务器判定为疑似宕机的情况下，触发探测服务端通过ICMP协议对于疑似宕机的服务器上多个端口监听状态检测。比如，如果探测的端口没有处于监听状态，则判断该服务器宕机。相反，如果探测的这些端口正常监听，则认为服务器没有宕机。

图3是本发明另一示例性实施例示出的宕机服务器的探测方法的流程示意图，本实施例在图2所示实施例的基础上，对S204的过程进一步详细描述。

如图3所示，本实施例提供的方法可以包括以下步骤：

S2041、当检测到目标服务器对应的服务器状态信息满足预设异常条件时，向探测服务端中的多个探测服务端节点发起异常判决请求。

上述异常判决请求用于判断目标服务器的服务器状态是否异常。

S2042、当探测服务端中超过预设比例的探测服务端节点均判定目标服务器的服务器状态异常时，判断目标服务器疑似宕机。

具体地，由于探测服务端包括集群式的多个探测服务端节点，探测客户端采集到的服务器状态信息会随机或按规则分发给探测服务端的其中一个探测服务器节点，并由该探测服务器节点判断是否满足预设异常条件。然而，由于探测服务器节点本身同样可能产生故障，其检测到的异常情况有可能由其本身故障导致。针对这种情况，可以向探测服务端中的多个其它探测服务端节点发起异常判决请求，使得其他探测服务端节点均根据该目标服务器的服务器状态信息来判断该目标服务器是否正常。比如，可以在探测服务端中部署奇数个探测服务端节点，并且使得全部探测服务端节点对该目标服务器的服务器状态信息进行判断，并且当超过半数的探测服务端节点判定该服务器异常，将该目标服务器标识为疑似宕机。

通过采用本实施例的方案，可以解决较大规模服务器集群探测的性能问题、单个探测服务节点异常以及探测客户端自身异常导致的误报。经过生产环境长期实践，在规模超过2000台服务器集群中，可以实现每秒更新服务器的状态，服务器宕机的误报率不到千分之一，探测服务端和客户端的CPU，内存和网络资源消耗可以忽略不计。

图3是本发明另一示例性实施例示出的宕机服务器的探测方法的流程示意图，本实施例在图2所示实施例的基础上，对S206的过程进一步详细描述。

在一实施例中，上述S206中对疑似宕机的目标服务器上指定端口进行端口状态探测，还包括：按照设定频率对疑似宕机的目标服务器上的指定端口进行持续探测；当端口探测连续失败超过设定次数时，判定目标服务器宕机；相反，当端口状态探测连续失败未超过设定次数时，判定目标服务器正常。

比如，对目标服务器上的指定端口进行每十秒钟一次，总共六次的探测。探测完成之后，如果没有出现连续4次的探测失败，则认为该目标服务器当前处于正常状态。相同的话，如果出现连续4次及以上的探测失败，则认为该目标服务器当前处于宕机状态。

可以理解，当前处于宕机状态的目标服务器同样可能存在两种情况，1、该目标服务器一直处于宕机状态，2、该目标服务器从正常变成宕机状态。

针对上述情况，在一实施例中，当端口探测连续失败超过设定次数时，进一步查询指定时间范围内目标服务器对应的宕机事件和/或恢复事件；目标服务器不存在宕机事件的情况下，和/或，目标服务器对应的宕机事件与恢复事件的数量一致的情况下，可以看出，该目标服务器是从正常变成宕机状态，此时需要生成对应于目标服务器的宕机事件，以同步更新该目标服务器的状态。相反，在目标服务器对应的宕机事件与恢复事件的数量不一致的情况下，可以看出，该目标服务器一直处于宕机状态。

同样地，当前处于正常状态的目标服务器仍可能存在两种情况，1、该目标服务器一直处于正常状态，2、该目标服务器从宕机恢复成正常状态。

针对上述情况，在一实施例中，当端口探测连续失败未超过设定次数时，可以进一步查询指定时间范围内目标服务器标识的宕机事件和/或恢复事件。在目标服务器对应的宕机事件与恢复事件的数量不一致的情况下，判定该目标服务器是从宕机恢复正常，此时生成对应于目标服务器的恢复事件以更新目标服务器状态。

基于相同的技术构思，本发明实施例还提供一种宕机服务器的探测装置，用于执行上述任一实施例所提供的宕机服务器的探测方法。

参考图1，该探测装置包括探测服务端，其包括多个探测服务端节点，探测服务端连接至多个探测客户端，多个探测客户端分别部署在服务器集群中的多个服务器上；

探测服务端，被配置为用于：获取服务器集群的多个服务器的服务器状态信息，服务器状态信息由部署在服务器上的探测客户端采集并上传到探测服务端；当服务器集群中的目标服务器对应的服务器状态信息满足预设异常条件时，判断目标服务器疑似宕机；由探测服务端的任意一个探测服务端节点对疑似宕机的目标服务器上指定端口进行端口状态探测，根据端口状态探测的结果判定目标服务器是否宕机。

这样，根据本发明实施方式的方案，能够提高探测宕机服务器的效率，降低误报率。

需要说明的是，本申请实施例中的装置可以实现前述方法的实施例的各个过程，并达到相同的效果和功能，这里不再赘述。

本发明实施例还提供一种数据库的高可用恢复方法，用于在探测到服务器集群中的服务器宕机后进行服务器数据库重建。

服务器宕机是指服务器出现意外故障导致无法登陆、无法执行命令、无法提供服务。服务器宕机的原因有很多种，如硬件故障、系统资源不足、系统漏洞BUG等都可能导致服务器宕机。在服务器宕机场景下，需要尽快恢复宕机服务器上部署的数据库，影响数据库恢复高可用架构耗时的主要因素包括服务器恢复正常的时间、运维人员处理时间、数据库备份还原的时间以及其它时间。服务器恢复正常一般需要服务器厂商派工程师到现场更换或者维修硬件排除故障，根据服务级别不同，耗时一般在2个小时以上，并且不可控因素较多，甚至出现过超过24小时的情况，平均在4个小时左右。服务器恢复正常以后，数据库运维人员需要介入以后恢复数据库实例，检查数据库状态以及进行故障期间数据同步，平均耗时在1个小时左右。如果恢复过程中需要对数据库进行备份还原，那么备份还原的时间也是一个耗时较长的过程，以200G的数据为例，备份还原以及数据传输估计耗时1小时左右，如果一台服务器上存在多个数据库，那么需要对多个数据库进行备份还原，耗时还会有所增加。

图4示出了本申请一实施例的数据库的高可用恢复方法的流程示意图，用于为了解决上述问题，即快速将宕机服务器的上数据库重建到其他服务器，在该流程中，从设备角度而言，执行主体可以是一个或者多个电子设备；从程序角度而言，执行主体相应地可以是搭载于这些电子设备上的程序。

如图4所示，本实施例提供的方法可以包括以下步骤：

S402、确定宕机服务器，宕机服务器上部署有第一数据库容器；

可以利用上述宕机服务器的探测方法从服务器集群中确定宕机服务器。当然也可以采用其他方案。

具体来说，首先可以每个探测周期(周期可以定义，默认是1分钟一次)在数据库管理平台上查询服务器范围。可以理解，由于存在服务器入库、出库、停用等情况，可用的数据库服务器范围也是动态变化的。然后可以查询服务器宕机事件，比如，在上述宕机服务器的探测方法中，如果探测到服务器宕机会写入宕机事件。然后可以根据查询到的宕机事件的信息，匹配上述服务器范围，如果能匹配某一服务器，则说明在服务器范围内存在宕机服务器。

可选地，为了兼容服务器上存在部分不需要重建的数据库容器，在S402之后可以进一步在数据库管理平台中查询宕机服务器上部署的第一数据库容器的容器类型；根据容器类型判断是否允许对第一数据库容器进行重建。

容器类型是指根据容器内部署的软件类型进行的分类，由于不同类型的容器高可用方式处理方式可能存在不同，某些数据库容器无需进行重建，因此，如发现宕机服务器上部署的第一数据库容器的容器类型为上述无需进行重建的容器类，则停止重建流程。反之则继续进行重建。

S404、在宕机服务器所在服务器集群中寻找满足重建条件的迁移服务器。

可以理解，选择迁移服务器需要考虑因素较多，包括服务器资源分配率(CPU、内存和磁盘)，资源使用率(响应时间、吞吐量)，可用状态(硬件状态、运行状态)。

在一实施例中，为了确定最适宜迁移的服务器，可以根据每个服务器的动态指标评价因子和/或静态指标评价因子，从服务器集群中确定满足重建条件的迁移服务器。

实际应用中，可以根据一种或多种静态指标评价因子和一种或多种动态指标评价因子的加权求和结果，从服务器集群中确定满足重建条件的迁移服务器。

静态指标评价因子包括如下中的一种或多种：业务维度指标、软件维度指标、运行模块维度指标、资源分配率等。其中，业务维度指标主要是指由每个服务器承担的项目的重要程度、对高可用性能的依赖情况。实际运行中，可以根据评价因子的重要性不同，设置不同比例，如对于资源分配率较为敏感数据库服务器，可以设置相关评价因子占比为40％，因此设置静态指标值＝(业务维度指标*100*0.3)+(软件维度指标*100*0.1)+(运行模块维度*100*0.2)+(资源分配率*100*0.4)。

动态指标评价因子包括如下中的一种或多种：CPU(CPU使用率、CPU波动率、CPU单日内最大值)、内存使用率、磁盘(磁盘使用率、磁盘的IOPS(Input/Output Operations PerSecond)值和磁盘最大延迟)、网卡流量(流入最大值、流出最大值)等指标。实际运行中，可以根据评价因子的重要性不同，设置不同比例，如对于磁盘较为敏感数据库服务器，可以设置磁盘相关评价因子占比为60％，因此设置动态指标值＝[CPU使用率*0.6+CPU波动率*0.3+CPU单日内最大值*0.1)*100*0.3]+(内存使用率*1*100*0.1)+[(磁盘使用率*0.7+磁盘的IOPS值/200*0.2+磁盘最大延迟/100*0.1)*100*0.6]。

在较大规模服务器集群中，如果所有的指标都在服务器宕机以后触发获取，并且根据获取的信息判断服务器是否是本次迁移的目标服务器，会消耗的时间较长。因此，本实施例中，可以周期性获取服务器集群中每个服务器的静态指标评价因子。以及，当检测服务器集群中发生服务器宕机时，实时获取服务器集群中每个服务器的动态指标评价因子。

上述动态指标评价因子在宕机后获取最新数据并进行计算，静态指标评价因子因数据相对稳定，变化量极小，可以每小时计算一次。最终根据动态指标和静态指标，本发明会对集群中每台服务器进行一个综合评分，出现服务器宕机后，直接根据评分高低选择可用服务器，尽量建设宕机后信息获取数量和计算量，快速选择目标服务器用于数据库快速重建。

S406、在迁移服务器上创建第二服务器容器，第二服务器容器与第一数据库容器具有相同的容器配置；

在一实施例中，容器配置包括：镜像名称，容器名称，容器的CPU、内存、文件系统和IP地址中的一种或多种。

S408、获取第一数据库容器的数据库配置文件，解析获得数据库配置信息，将数据库配置信息持久化到第二服务器容器中，并在第一服务器容器中进行数据库初始化；

由于数据库配置文件就是普通的文本文件，没有较强的格式要求，经常会由于编辑不当或者其它原因，配置文件中出现乱码，导致配置文件实际不可用，并且难以发现，使用这种配置文件数据库无法正常启动，给规模化数据库运维带来不少难题。为了实现数据库快速异机重建，获取到数据库最新、正确的配置是关键，如果使用传统直接同步配置文件到配置中心的方式，会出现由于源库配置文件乱码等原因导致数据库重建到其它服务器后无法启动，需要运维人员介入，无法实现全程自动化，导致无法快速恢复。

为了解决上述问题，在一实施例中，S408可以具体包括：

将查询到的数据库配置文件中的参数转换为多个键值对(KEY/VALUE)数据；

按照数据库全量参数模板过滤多个键值对数据，以得到数据库配置信息；

将键值对数据作为数据库配置信息存储在缓存数据库(REDIS)中。

其中，按照数据库全量参数模板过滤多个键值对数据包括：当数据库全量参数模板不包含任一键值对数据中的键时，丢弃任一键值对。

本实施例中，将数据库配置文件里面的参数转换为键值对(KEY/VALUE)数据，并存储在缓存数据库(REDIS)中的方案，加载该版本的数据库全量参数模板，获取数据库配置参数的名称，如果遇到键(KEY)没有配置在参数模板的情况，则直接丢弃，这种方式能够有效过滤配置文件中的乱码或者无效参数的问题。

在重建时，通过缓存数据库(REDIS)获取键值对(KEY/VALUE)数据，生成数据库配置文件并持久化到新的容器内。缓存数据库(REDIS)有较好的查询和写入性能，可以实现较大规模数据库参数同时的查询和更新。

S410、获取第一数据库容器的备份镜像，根据备份镜像在第二数据库容器中进行数据库还原；

S412、搭建第二数据库容器到当前主库容器的复制关系以同步数据，其中，当前主库容器与第一数据库容器在宕机服务器宕机之前具有主备关系。

可以理解，参考图5，在高可用架构中，宕机服务器上的第一数据库容器至少在另一服务器上会存在具有主备关系的服务器容器。在宕机服务器发生宕机之前，宕机服务器上的第一数据库容器可以是主库容器，也可以是备库容器。在高可用架构下，当宕机服务器发生宕机之后，与其具有主备关系的另一服务器上的该服务器容器保持主库容器地位或者升级为主库容器。本申请利用上述S402—S410，在迁移服务器中部署第二数据库容器以替代该第一数据库容器，并搭建第二数据库容器到当前主库容器的复制关系以同步数据，此时，第二数据库容器作为主库容器的备库容器。

可以周期性检查主备库复制数据是否有延迟，一旦和主库容器的数据追平，新建数据库具备了对外提供服务能力，即开始恢复数据库原来的高可用架构。

本实施例提供的技术方案，在数据库服务器宕机情况下，能够快速恢复数据库原高可用架构，在主备架构数据库中一个服务器宕机未恢复的情况下，能够快速恢复原来的主备架构，解决数据库存在单点的问题。能够明显提升主备架构的数据库整体高可用，让主备架构数据库适用于高可用要求更高的场景。本实施例也适用于一主多从等架构的数据库高可用快速，不用等待服务器从故障中恢复，就能够恢复数据库原来高可用架构，提升了数据库服务整体高可用能力。

基于相同的技术构思，本发明实施例还提供一种数据库的高可用恢复装置，用于执行上述任一实施例所提供的数据库的高可用恢复方法。

如图6所示，该装置包括：

宕机服务器确定模块602，用于确定宕机服务器，宕机服务器上部署有第一数据库容器；

迁移服务器确定模块604，用于在目标服务器所在服务器集群中寻找满足重建条件的迁移服务器；

容器创建模块606，用于在迁移服务器上创建第二服务器容器，第二服务器容器与第一数据库容器具有相同的容器配置；

数据库初始化模块608，用于获取第一数据库容器的数据库配置文件，解析获得数据库配置信息，将数据库配置信息持久化到第二服务器容器中，并在第一服务器容器中进行数据库初始化；

数据库还原模块610，用于获取第一数据库容器的备份镜像，根据备份镜像在第二数据库容器中进行数据库还原；

数据库同步模块612，用于搭建第二数据库容器到当前主库容器的复制关系以同步数据，其中，当前主库容器与第一数据库容器在目标服务器宕机之前具有主备关系。

需要说明的是，本申请实施例中的装置可以实现前述方法的实施例的各个过程，并达到相同的效果和功能，这里不再赘述。

在本说明书的描述中，参考术语“一些可能的实施方式”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

关于本申请实施例的方法流程图，将某些操作描述为以一定顺序执行的不同的步骤。这样的流程图属于说明性的而非限制性的。可以将在本文中所描述的某些步骤分组在一起并且在单个操作中执行、可以将某些步骤分割成多个子步骤、并且可以以不同于在本文中所示出的顺序来执行某些步骤。可以由任何电路结构和/或有形机制(例如，由在计算机设备上运行的软件、硬件(例如，处理器或芯片实现的逻辑功能)等、和/或其任何组合)以任何方式来实现在流程图中所示出的各个步骤。

图7为根据本申请一实施例的宕机服务器的探测装置，用于执行图2所示出的宕机服务器的探测方法，该装置包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述实施例所述的方法。

图8为根据本申请一实施例的数据库的高可用恢复装置，用于执行图4所示出的数据库的高可用恢复方法，该装置包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述实施例所述的方法。

根据本申请的一些实施例，提供了数据库的高可用恢复方法的非易失性计算机存储介质，其上存储有计算机可执行指令，该计算机可执行指令设置为在由处理器运行时执行：上述实施例所述的宕机服务器的探测方法，或者，上述实施例所述的数据库的高可用恢复方法。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以其描述进行了简化，相关之处可参见方法实施例的部分说明即可。

本申请实施例提供的装置、设备和计算机可读存储介质与方法是一一对应的，因此，装置、设备和计算机可读存储介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述装置、设备和计算机可读存储介质的有益技术效果。

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

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (21)

1.一种宕机服务器的探测方法，其特征在于，所述方法应用于探测服务端，所述探测服务端包括集群式的多个探测服务端节点，所述探测服务端连接至多个探测客户端，所述多个探测客户端分别部署在服务器集群中的多个服务器上，所述方法包括：

获取所述服务器集群的多个服务器的服务器状态信息，所述服务器状态信息由部署在所述服务器上的所述探测客户端采集并上传到所述探测服务端；

当所述服务器集群中的目标服务器对应的所述服务器状态信息满足预设异常条件时，判断所述目标服务器疑似宕机；

由所述探测服务端的任意一个或多个探测服务端节点对疑似宕机的所述目标服务器上指定端口进行端口状态探测，根据所述端口状态探测的结果判定所述目标服务器是否宕机。

2.根据权利要求1所述的方法，其特征在于，所述判断所述目标服务器疑似宕机，还包括：

当检测到所述目标服务器对应的所述服务器状态信息满足所述预设异常条件时，向所述探测服务端中的多个所述探测服务端节点发起异常判决请求，所述异常判决请求用于判断所述目标服务器的所述服务器状态是否异常；

当所述探测服务端中超过预设比例的所述探测服务端节点均判定所述目标服务器的服务器状态异常时，判断所述目标服务器疑似宕机。

3.根据权利要求1所述的方法，其特征在于，所述端口状态探测，还包括：通过ICMP协议检测所述目标服务器上指定端口的端口状态。

4.根据权利要求1所述的方法，其特征在于，所述指定端口包括：SSH端口和/或docker端口。

5.根据权利要求1所述的方法，其特征在于，所述预设异常条件为：

所述探测服务端中的任意一个探测服务端节点接收到所述目标服务器的服务器异常信息；和/或，

所述探测服务端在超过预设次数的心跳周期内，未收到部署在所述目标服务器上的所述探测客户端上送的心跳。

6.根据权利要求1所述的方法，其特征在于，对疑似宕机的所述目标服务器上指定端口进行端口状态探测，还包括：

按照设定频率对疑似宕机的所述目标服务器上的指定端口进行持续探测；

当所述端口探测连续失败超过设定次数时，判定所述目标服务器宕机；

当所述端口状态探测连续失败未超过设定次数时，判定所述目标服务器正常。

7.根据权利要求6所述的方法，其特征在于，当所述端口探测连续失败超过设定次数时，还包括：

查询指定时间范围内所述目标服务器对应的宕机事件和/或恢复事件；

在所述目标服务器不存在宕机事件的情况下，和/或，所述目标服务器对应的宕机事件与恢复事件的数量一致的情况下，生成对应于所述目标服务器的宕机事件。

8.根据权利要求6所述的方法，其特征在于，当所述端口探测连续失败未超过设定次数时，还包括：

查询指定时间范围内所述目标服务器标识的宕机事件和/或恢复事件；

在所述目标服务器对应的宕机事件与恢复事件的数量不一致的情况下，判定所述目标服务器对应的目标服务器从宕机恢复正常，并生成对应于所述目标服务器的恢复事件。

9.一种宕机服务器的探测装置，其特征在于，所述装置被配置为执行如权利要求1-8中任一项所述的方法，其中，所述装置为包括多个探测服务端节点的探测服务端，所述探测服务端连接至多个探测客户端，所述多个探测客户端分别部署在服务器集群中的多个服务器上；

所述探测服务端，被配置为用于：

获取所述服务器集群的多个服务器的服务器状态信息，所述服务器状态信息由部署在所述服务器上的所述探测客户端采集并上传到所述探测服务端；

当所述服务器集群中的目标服务器对应的所述服务器状态信息满足预设异常条件时，判断所述目标服务器疑似宕机；

由所述探测服务端的任意一个探测服务端节点对疑似宕机的所述目标服务器上指定端口进行端口状态探测，根据所述端口状态探测的结果判定所述目标服务器是否宕机。

10.一种数据库的高可用恢复方法，其特征在于，所述方法包括：

确定宕机服务器，所述宕机服务器上部署有第一数据库容器；

在所述宕机服务器所在服务器集群中寻找满足重建条件的迁移服务器；

在所述迁移服务器上创建第二服务器容器，所述第二服务器容器与所述第一数据库容器具有相同的容器配置；

获取所述第一数据库容器的数据库配置文件，解析获得数据库配置信息，将所述数据库配置信息持久化到所述第二服务器容器中，并在所述第一服务器容器中进行数据库初始化；

获取所述第一数据库容器的备份镜像，根据所述备份镜像在所述第二数据库容器中进行数据库还原；

搭建所述第二数据库容器到当前主库容器的复制关系以同步数据，其中，所述当前主库容器与所述第一数据库容器在所述宕机服务器宕机之前具有主备关系。

11.根据权利要求10所述的方法，其特征在于，所述方法包括：

利用如权利要求1-8中任一项所述的方法从服务器集群中确定所述宕机服务器。

12.根据权利要求10所述的方法，其特征在于，确定发生宕机事件的宕机服务器，包括：

周期性地查询数据库管理平台，以确定服务器范围；

查询所述服务器范围内的服务器宕机事件，以确定所述宕机服务器。

13.根据权利要求10所述的方法，其特征在于，确定宕机的宕机服务器之后，还包括：

在数据库管理平台中查询所述宕机服务器上部署的所述第一数据库容器的容器类型；

根据所述容器类型判断是否允许对所述第一数据库容器进行重建。

14.根据权利要求10所述的方法，其特征在于，在所述宕机服务器所在服务器集群中寻找满足重建条件的迁移服务器，还包括：

根据所述每个服务器的动态指标评价因子和/或静态指标评价因子，从所述服务器集群中确定满足重建条件的所述迁移服务器；

其中，所述静态指标评价因子包括如下中的一种或多种：业务维度指标、软件维度指标、资源分配率；所述动态指标评价因子包括如下中的一种或多种：CPU使用率、CPU波动率、CPU单日内最大值、内存使用率、磁盘使用率、磁盘的每秒输入输出值、磁盘最大延迟、网卡流量。

15.根据权利要求14所述的方法，其特征在于，还包括：

周期性获取所述服务器集群中每个服务器的所述静态评价因子；

当检测所述服务器集群中发生服务器宕机时，实时获取所述服务器集群中每个服务器的所述动态指标评价因子。

16.根据权利要求14所述的方法，其特征在于，还包括：

根据一种或多种所述静态指标评价因子和一种或多种所述动态指标评价因子的加权求和结果，从所述服务器集群中确定满足重建条件的所述迁移服务器。

17.根据权利要求10所述的方法，其特征在于，获取所述第一数据库容器的数据库配置文件，解析获得数据库配置信息，还包括：

将查询到的所述数据库配置文件中的参数转换为多个键值对数据；

按照数据库全量参数模板过滤所述多个键值对数据，以得到所述数据库配置信息；

将所述键值对数据作为所述数据库配置信息存储在缓存数据库(REDIS)中；

其中，所述按照数据库全量参数模板过滤所述多个键值对数据包括：当所述数据库全量参数模板不包含任一键值对数据中的键时，丢弃所述任一键值对。

18.根据权利要求10所述的方法，其特征在于，所述容器配置包括：镜像名称，容器名称，容器的CPU、内存、文件系统和IP地址中的一种或多种。

19.一种数据库的高可用恢复装置，其特征在于，所述装置被配置为执行如权利要求10-19中任一项所述的方法，所述装置包括：

宕机服务器确定模块，用于确定宕机服务器，所述宕机服务器上部署有第一数据库容器；

迁移服务器确定模块，用于在所述目标服务器所在服务器集群中寻找满足重建条件的迁移服务器；

容器创建模块，用于在所述迁移服务器上创建第二服务器容器，所述第二服务器容器与所述第一数据库容器具有相同的容器配置；

数据库初始化模块，用于获取所述第一数据库容器的数据库配置文件，解析获得数据库配置信息，将所述数据库配置信息持久化到所述第二服务器容器中，并在所述第一服务器容器中进行数据库初始化；

数据库还原模块，用于获取所述第一数据库容器的备份镜像，根据所述备份镜像在所述第二数据库容器中进行数据库还原；

数据库同步模块，用于搭建所述第二数据库容器到当前主库容器的复制关系以同步数据，其中，所述当前主库容器与所述第一数据库容器在所述目标服务器宕机之前具有主备关系。

20.一种数据库的高可用恢复装置，其特征在于，包括：

至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行：如权利要求8-17中任一项所述的方法。

21.一种计算机可读存储介质，所述计算机可读存储介质存储有程序，当所述程序被多核处理器执行时，使得所述多核处理器执行如权利要求1-7中任一项的方法或者所述如权利要求8-17中任一项所述的方法。

Images