CN112363865A - 数据库故障恢复方法、装置及人脸图像搜索系统 - Google Patents

Abstract

本申请适用于计算机技术领域，提供了一种数据库故障恢复方法、装置及人脸图像搜索系统，其中该方法包括：检测业务数据库的状态，其中，所述服务器配置有用于响应业务查询请求的业务数据库和用于对所述业务数据库中的数据进行备份的备份数据库；当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份。由此，在检测到提供查询服务的业务数据库存在故障时，服务器可以自动切换至备份数据库来提供数据库查询服务，可以保障业务的可靠性。

Description

数据库故障恢复方法、装置及人脸图像搜索系统

技术领域

本申请属于计算机技术领域，尤其涉及一种数据库故障恢复方法、装置及人脸图像搜索系统。

背景技术

数据库是众多互联网应用的基础，并随着互联网业务的不断发展，数据库的安全可靠性越来越被应用运营商重视。

在数据库实际使用过程中，由于用户的误操作、系统故障以及其它意料之外的因素，导致数据安全事故频有发生，例如搜索系统崩溃、数据库状态异常、数据被损坏等。

为了保障数据的安全性，除了构建正常的主数据库以用于正常存储以及查询服务之外，一般还需要专门创建一个数据库，以用于对搜索系统中数据的进行全量备份。当主数据库出现不可恢复的故障时，可以人工将备份的数据迁移到发生故障的数据库下进行数据修复，以恢复数据查询服务。

然而，这种人工备份恢复方式，在实际业务处理的过程中，暴露出来了一些缺点，例如，从业务数据库出现故障到执行数据恢复过程中需要人工操作干预，如果用户或运维人员没有及时干预可能会导致服务长时间中断；并且,数据库的数据量巨大(例如，高达几百G甚至几十T)，导致数据迁移及恢复效率低下和长时间业务中断；此外，人工手动操作容易导致操作错误，可维护性差。

发明内容

有鉴于此，本申请实施例提供了一种数据库故障恢复方法、装置及人脸图像搜索系统，以至少解决现有技术中人工备份恢复数据库所导致的业务中断时间长和可维护性差的问题。

本申请实施例的第一方面提供了一种数据库故障恢复方法，应用于服务器，所述方法包括：检测业务数据库的状态，其中，所述服务器配置有用于响应业务查询请求的业务数据库和用于对所述业务数据库中的数据进行备份的备份数据库；当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份。

本申请实施例的第二方面提供了一种数据库故障恢复装置，包括：数据库状态检测单元，被配置为检测业务数据库的状态，其中，服务器配置有用于响应业务查询请求的业务数据库和用于对所述业务数据库中的数据进行备份的备份数据库；数据服务恢复单元，被配置为当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份。

本申请实施例的第三方面提供了一种人脸图像搜索系统，包括人脸图像搜索控制及分发中心、第一节点和第二节点，其中所述人脸图像搜索控制及分发中心包括业务控制模块和数据安全控制模块，以及所述第一节点绑定有用于响应业务查询请求的业务数据库，所述第二节点绑定有用于对所述业务数据库中的数据进行备份的备份数据库，所述数据安全控制模块，被配置为获取所述业务数据库的状态；所述业务控制模块，被配置为当所述业务数据库处于数据库故障状态时，向所述第一节点和所述第二节点分别发送相应的节点类型配置指令，使得基于所述节点类型配置指令，所述第二节点使用所述备份数据库来响应业务查询请求，以及所述第一节点使用所述业务数据库来对所述备份数据库中的数据进行备份。

本申请实施例的第四方面提供了一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述方法的步骤。

本申请实施例的第五方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述方法的步骤。

本申请实施例的第六方面提供了一种计算机程序产品，当计算机程序产品在服务器上运行时，使得服务器实现如上述方法的步骤。

本申请实施例与现有技术相比存在的有益效果是：

服务器可以自主地检测数据库是否处于数据库故障状态，并在数据库处于故障状态时，转换备份数据库和业务数据库的操作功能，即由备份数据库来提供业务查询服务，并由业务数据库来完成备份功能。由此，在服务器检测到提供查询服务的业务数据库存在故障时，可以自动切换至备份数据库来提供查询服务，可以避免业务服务中断(或长时间中断)，有利于保障业务服务的可靠性，能够满足当前应用环境下对数据库的大数据量、高容错性、高可靠性和易维护性的需求。

附图说明

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

图1示出了根据本申请实施例的数据库故障恢复方法的一示例的流程图；

图2示出了根据本申请实施例的检测业务数据库的状态的一示例的流程图；

图3示出了根据本申请实施例的根据业务数据库的工作异常的持续时间来检测数据库故障状态的一示例的流程图；

图4示出了根据本申请实施例的数据库故障恢复方法的一示例的流程图；

图5示出了根据本申请实施例的设置在服务器中的数据库故障恢复系统的一示例的结构框图；

图6示出适于应用本申请实施例的数据库故障恢复方法的搭载在服务器中的人脸图像搜索系统的一示例的架构示意图；

图7示出了利用图6中的人脸图像搜索系统进行数据库检索流程的一示例的流程图；

图8示出了根据如图7中的人脸图像搜索系统的开机初始化流程的一示例的流程图；

图9示出了根据如图7中的人脸图像搜索系统的异常监测及上报流程的一示例的流程图；

图10示出了根据如图7中的人脸图像搜索系统的数据恢复流程的一示例的流程图；

图11示出了根据本申请实施例的数据库故障恢复装置的一示例的结构框图；

图12示出了根据本申请实施例的服务器的一示例的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

具体实现中，本申请实施例中描述的移动终端包括但不限于诸如具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的移动电话、膝上型计算机或平板计算机之类的其它便携式设备。还应当理解的是，在某些实施例中，上述设备并非便携式通信设备，而是具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的台式计算机。

在接下来的讨论中，描述了包括显示器和触摸敏感表面的移动终端。然而，应当理解的是，移动终端可以包括诸如物理键盘、鼠标和/或控制杆的一个或多个其它物理用户接口设备。

可以在移动终端上执行的各种应用程序可以使用诸如触摸敏感表面的至少一个公共物理用户接口设备。可以在应用程序之间和/或相应应用程序内调整和/或改变触摸敏感表面的一个或多个功能以及终端上显示的相应信息。这样，终端的公共物理架构(例如，触摸敏感表面)可以支持具有对用户而言直观且透明的用户界面的各种应用程序。

另外，在本申请的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

图1示出了根据本申请实施例的数据库故障恢复方法的一示例的流程图。

如图1所示，在步骤110中，检测业务数据库的状态，并可以判断业务数据库是否处于数据库故障状态。这里，服务器配置有用于响应业务查询请求的业务数据库和用于对业务数据库中的数据进行备份的备份数据库。

需说明的是，于此所描述的业务数据库和备份数据库在结构或类型上可以是相同的，例如可以表示数据库的两种工作模式，并且在特定条件下可以切换工作模式(例如，由业务模式转换为备份模式)。

在一些应用场景下，备份数据库可以是业务数据库在功能上的子集，例如在备份数据上可以实现与业务数据库同步地新增或删除数据，然而备份数据库不需要响应业务查询请求。应理解的是，服务器在接收业务查询请求时需要在业务数据库中执行各种向量查询、属性查询功能等，反馈相应的查询结果，而且经常需要处理并发的业务请求，导致业务数据库相比于备份数据库更容易出现故障。

如果步骤110中的检测结果指示业务数据库处于数据库故障状态，则跳转至步骤121。如果步骤110中的检测结果指示业务数据库处于数据库正常状态，则跳转至步骤123。

在步骤121中，使用备份数据库来响应业务查询请求，并使用业务数据库来对备份数据库中的数据进行备份。

在步骤123中，使用业务数据库来响应业务查询请求，并使用备份数据库对业务数据库中的数据进行备份。

通过本申请实施例，服务器可以自主地检测数据库是否存在故障(例如，数据库状态异常或不可恢复的数据损坏)，并在检测到数据库存在故障时自适应地触发数据恢复过程，利用备份数据库来提供业务查询服务，激活备份数据库的业务功能，将搜索业务请求无缝切换至激活后的备份数据库。由此，无需人工干预，实现了全程自动化监测，可以大大缩短故障判断以及数据恢复的时间，使得业务服务不会因数据库故障而中断(或长期中断)，有效减小了由于数据库故障造成的业务中断以及经济损失，可以保障业务应用的安全性、可靠性以及维护管理的便利性，提高了业务服务的用户体验。

在本申请实施例的一些示例中，在检测用于响应业务查询请求的业务数据库是否处于数据库故障状态之后，服务器还可以获取业务请求所对应的数据库操作类型。这里，数据库操作类型可以被分为业务查询类型、数据删除类型和数据新增类型。具体地，当数据库操作类型为业务查询类型时，调用用于响应业务查询请求的业务数据库或备份数据库来执行业务请求(或，业务查询请求)，例如当业务数据库处于数据库故障状态时，调用备份数据库来响应业务请求以提供服务查询服务。此外，当数据库操作类型为数据删除类型或数据新增类型时，服务器可以调用业务数据库和备份数据库分别来执行业务请求，以在业务数据库和备份数据库中同步地新增数据或删除数据，由此保障备份数据库与业务数据库中所存储的数据的一致性。

图2示出了根据本申请实施例的检测业务数据库的状态的一示例的流程图。

如图2所示，在步骤210中，检测业务数据库是否工作异常。这里，可以采用各种检测方式来检测业务数据库是否工作异常，并可以不作限制。

如果步骤210中的检测结果表示业务数据库存在工作异常，则跳转至步骤221。如果步骤210中的检测结果表示业务数据库不存在工作异常，则跳转至步骤223。

在步骤223中，确定业务数据库为数据库正常状态。

在步骤221中，统计业务数据库工作异常的持续时间。

接着，在步骤230中，根据工作异常的持续时间，确定业务数据库的状态。示例性地，当业务数据库工作异常的持续时间超过设定阈值时，确定业务数据库的状态为数据库故障状态。由此，在业务数据库短期异常而快速恢复正常之后或者在运维人员干预操作的情况下，不需要将数据的状态认定为故障，可以避免冗余的数据库切换操作，节约资源消耗。

关于上述步骤210的具体实施过程，在一些实施方式中，可以监测业务数据库是否丢失连接和响应业务查询请求的查询时延。进而，根据关于丢失连接和查询时延的监测结果，可以确定业务数据库工作异常。具体地，当业务数据库丢失连接且持续超过预设的正常时间阈值时，或者当业务数据库响应业务查询请求的查询时延超过预设的正常时延阈值时，可以确定业务数据库工作异常。由此，可以通过监测数据库的连接和工作状态来确定业务数据库是否工作异常。

图3示出了根据本申请实施例的根据业务数据库的工作异常的持续时间来检测数据库故障状态的一示例的流程图。

如图3所示，在步骤310中，当业务数据库工作异常的持续时间超过第一设定时间阈值时，执行数据故障恢复提示操作。示例性地，服务器可以将数据故障恢复通知发送至显示器，以通过显示故障恢复通知的方式来提醒用户当前的业务数据库可能存在故障，并询问运营用户是否进行相应的数据恢复操作。

在步骤320中，在执行数据故障恢复提示操作之后的设定时间段内，检测业务数据库是否持续工作异常以及是否存在数据恢复操作终止指令。这里，设定时间段可以表示人工干预数据恢复过程的时间窗口，其可以是根据用户需求或应用场景而相应设定的。

在步骤330中，若在设定时间段内所述业务数据库持续工作异常且不存在数据恢复操作终止指令时，则判定业务数据库处于数据库故障状态。

此外，在服务器执行数据故障恢复提示操作后的设定时间段内，如果检测到业务数据库恢复正常或者因存在用户中断数据恢复的干预操作，则可以确定数据库仍不处于数据库故障状态，相应地也无需进行数据库功能切换操作。

通过本申请实施例，在业务数据库存在工作异常时，用户可以进行干预操作以确定数据库的状态，以及是否进行相应的数据库故障恢复操作，可以满足数据库故障恢复应用场景下的个性化需求。

图4示出了根据本申请实施例的数据库故障恢复方法的一示例的流程图。

如图4所示，在步骤410中，检测用于响应业务查询请求的业务数据库是否处于数据库故障状态。这里，服务器还配置有用于对所述业务数据库中的数据进行备份的备份数据库。

如果步骤410中的检测结果指示数据库处于数据库故障状态，则跳转至步骤421。如果步骤410中的检测结果指示第一数据库状态是正常状态，则跳转至步骤423。

在步骤423中，使用业务数据库来响应业务查询请求，并使用备份数据库对业务数据库中的数据进行备份。

在步骤421中，检测备份数据库的状态，以确定备份数据库是否处于数据库故障状态。

如果步骤421中的检测结果指示备份数据库处于数据库故障状态，则跳转至步骤440。如果步骤421中的检测结果指示备份数据库不处于数据库故障状态，则跳转回步骤430。

在步骤430中，使用备份数据库来响应业务查询请求，并使用业务数据库来对备份数据库中的数据进行备份。

在步骤440中，执行数据恢复失败提示操作。示例性地，可以在与服务器连接的显示器显示数据恢复失败通知，或者服务器可以将数据恢复失败通知发送至预设终端，以及时地通知运维人员来进行相应的维护操作。

通过本申请实施例，实现了检测数据库的故障恢复结果，并在数据库恢复失败时发送数据恢复失败通知，使得运维人员能够及时对数据库进行维护，保障业务服务的可靠性。

图5示出了根据本申请实施例的设置在服务器中的数据库故障恢复系统的一示例的结构框图。

如图5所示，数据库故障恢复系统500包括数据库故障恢复模块510、用于对业务数据库A进行管理的第一管理节点模块520和用于对备份数据库B进行管理的第二管理节点模块530。

具体地，在业务数据库处于数据库故障状态时，数据库故障恢复模块510可以发送数据库切换指令至第一管理节点模块520和第二管理节点模块530。进而，第二管理节点模块530基于数据库切换指令可以控制备份数据库B来响应业务查询请求，以及第一管理节点模块520基于数据库切换指令可以控制由业务数据库A来对备份数据库B中的数据进行备份。由此，通过服务器中不同功能模块之间的信息交互过程，实现了在业务数据库出现故障时及时调用备份数据库来提供业务查询服务，保障了数据安全性和业务服务的可靠性。

图6示出适于应用本申请实施例的数据库故障恢复方法的搭载在服务器中的人脸图像搜索系统的一示例的架构示意图。

近几年，是AI(Artificial Intelligence,人工智能)技术从兴起到落地、再到发展的关键时期，尤其是基于视觉的AI及应用纷纷落地、商用。AI的发展离不开大数据的支持，无论是模型训练，还是具体的应用实现，都离不开基于大数据的存储、搜索等技术的支撑。所以，无论是对于AI设备提供商，还是AI产品的用户，数据库的数据安全都是头等重要的大事。

通过本申请实施例所提供的人脸图像检索系统，可以实现对人脸图像数据库中的数据进行自适应备份，并能够有效保障数据库的数据安全，保障业务服务能持续地提供服务。但应理解的是，本申请实施例中的数据库可以是对应各种应用场景或应用领域下的数据库，而可以并不局限于人脸图像应用(或，其他AI应用产品)所对应的数据库中。

在本申请实施例中，在搜索系统内部采用了合理的备份恢复架构，并可以智能化、自适应地实时监测搜索系统当前主业务数据库的状态，可以解决人像的搜索系统的数据安全问题。

如图6所示，搜索系统600在架构上可以划分为三个部分：人脸图像搜索控制及分发中心(search-center)610、业务计算节点(service-node，也可以被称为第一管理节点模块)620，以及数据备份节点(backup-node，也可以被称为第二管理节点模块)630。无论是人脸图像搜索控制及分发中心还是业务计算节点，其主要功能都是承担搜索业务的具体实现过程，为了简化描述，与搜索业务有关的功能模块均统称为业务模块。此外，搜索系统600还可以与用户界面连接，以提供实现在数据库检索操作过程中的用户交互功能。

在本申请实施例的一些示例中，人脸图像搜索控制及分发中心610内部又可以被划分为业务控制(service-ctrl)模块611和数据安全控制(secure-ctrl)模块(其也可以被称为，数据库故障恢复模块)613。此外，业务计算节点620和数据备份节点630可以是节点的两个不同的运行模式，故在下文的描述中如果不特指是业务计算节点或数据备份节点，则用node代替，每一个node可以绑定相应的一个数据库，例如业务计算节点620与相应的数据库641绑定，数据备份节点630与相应的数据库643绑定。

具体地，人脸图像搜索控制及分发中心610可以是搜索系统的控制中心和业务请求及数据的分发中心。

在本申请实施例的一些示例中，业务控制模块611，主要负责搜索系统的业务请求处理和搜索服务响应，包括对业务计算节点和数据备份节点的配置、数据及业务请求的分发、查询结果的汇总和上报。业务控制模块611可以响应节点的初始化请求，配置对应节点的运行模式(业务计算节点或数据备份节点)以及基本参数配置。此外，业务控制模块611可以执行业务数据分发操作，将前端采集或提取的人脸数据同步分发给业务计算节点和数据备份节点，例如可采用第三方组件来保证分发给业务计算节点和数据备份节点数据的一致性。另外，业务控制模块611还可以执行业务请求分发功能，例如需要将数据删除请求同步分发到业务计算节点和数据备份节点，而搜索请求(或，业务查询请求)只需要转发给业务计算节点，而不需要转发给数据备份节点。

在本申请实施例的一些示例中，数据安全控制模块613可以收集每个节点对应的DB(database,数据库)状态，并判断数据库是否存在故障，并决策是否触发数据恢复处理流程。

在本申请实施例的一些示例中，业务计算节点620和数据备份节点630是节点两个不同的工作模式，也就是说，对于一个节点来说，模式是可配置的。在一些应用场景下，在服务器启动初始化的过程中根据人脸图像搜索控制及分发中心下发的节点类型(nodeType)配置指令，分别配置为业务计算节点模式或数据备份节点模式。

在业务计算节点620中配置有服务相关(Service-union)模块621，在数据备份节点630中配置有服务相关模块631，服务相关模块所执行的是与搜索业务相关的功能操作，并且服务相关模块621和服务相关模块631所支持的功能操作也是不一样的。具体地，服务相关模块621可以响应查询请求而执行各种向量查询、属性查询等操作，并反馈相应的查询结果，此外，服务相关模块621还可以支持数据录入功能操作和数据删除功能操作。相比之下，服务相关模块631可以不响应各种查询请求，只支持数据录入操作和删除操作，以保障备份数据库与业务数据库中的数据一致。

需说明的是，在本申请实施例中，数据库可以采用各种类型的数据库，例如目前主流的关系型数据库。在业务计算节点模式下节点绑定的DB(即，数据库641)可以提供各种复杂场景的查询功能、数据写入、删除，由于业务场景复杂、并发程度高，导致出现数据安全故障的可能性较高。在数据备份节点模式下节点绑定的DB(即，数据库643)，不支持数据查询业务，并可以只支持简单的数据写入、删除功能操作，出现数据安全故障的可能性较低，可以提供全量数据备份。

此外，在node中可以配置相应的数据库监视(DB-watch)模块(例如数据库监视模块623和633)，基于数据库监视模块623和633所进行的数据库监视操作可以是相同的。具体地，基于数据库监视模块可以(例如，通过关系型数据库postgresql提供的接口)周期性地监测数据库的运行和连接状态。示例性地，如果监测到数据库持续丢失连接超过某个时长，或查询时延超过预设的最大时长，则可以向人脸图像搜索控制及分发中心上报数据库异常状态。另外，数据库监视模块还可以响应人脸图像搜索控制及分发中心的重启指令对数据库进行重启操作。

图7示出了利用图6中的人脸图像搜索系统进行数据库检索流程的一示例的流程图。

如图7所示，数据库检索流程700包括开机初始化流程710、异常监测及上报流程720和数据恢复流程730。应理解的是，如图7所描述的数据库检索流程700主要所描述的是数据库自适应数据安全机制，因此针对搜索业务过程的描述可以仅作简略描述。

图8示出了根据如图7中的搜索系统的开机初始化流程的一示例的流程图。

如图8所示，在步骤810中，在搜索系统启动时，初始化人脸图像搜索控制及分发中心。

在步骤820中，在完成初始化人脸图像搜索控制及分发中心之后才启动节点，在节点启动时，会通过接口向人脸图像搜索控制及分发中心发送初始化请求。

在步骤830中，在人脸图像搜索控制及分发中心收到初始化请求后，根据节点状态表(nodeStatList)将该节点对应的节点类型下发给对应的节点，并下发其它的业务配置信息。如下表1所示，其示出了根据本申请实施例的一示例的节点模式状态表。

节点名称	节点类型	数据库状态(DBStat)
			node-1	业务节点	正常(normal)
node-2	备份节点	正常(normal)

表1节点模式状态表

结合如表1中的示例，当node-1和node-2分别收到人脸图像搜索控制及分发中心下发的初始化响应消息后，可以分别被激活为业务计算节点和数据备份节点模式。在节点模式状态表中，主要是保存对应两个node的运行模式节点类型(业务计算节点或数据备份节点)，以及各自对应数据库的运行状态DBStat。具体地，该数据库状态参数可以共有3个值正常状态(Normal)、监测状态(Monitor)和故障状态(故障状态)，正常状态可以表示该节点及其数据库状态正常，监测状态可以表示该节点及相应的数据库存在短期异常并正在监测异常是否不可恢复，故障状态可以表示该节点及其数据库存在不可恢复的故障并需要进行修复。在初始化时，可以默认均设为正常状态。

在步骤840中，初始化数据库监视模块。具体地，可以读取参数-监测计时器(monitorTimer)的周期(例如，可以是30s)，以定时通过接口监测DB的连接以及状态。此外，还可以读取参数-最大连续监测异常次数，或监测异常时间阈值(maxInvalidTimes)，如果达到则上报给人脸图像搜索控制及分发中心，例如可以设为6次，即连续3分钟监测异常时上报人脸图像搜索控制及分发中心。

在步骤850中，初始化监测计时器(monitorCounter)和上报等待计时器(waitCounter)。具体地，监测计时器可以表示针对每个node分别配置的计时器，可以用于监测在监测状态下的节点再次上报异常的有效时间(例如，可设为10分钟，其时长可配置)。此外，等待计时器可以表示上报等待计时器，例如在数据安全控制模块向用户界面上报数据故障恢复通知，等待用户取消恢复操作的时间(例如，可设为5分钟，其时长可配置)。

图9示出了根据如图7中的搜索系统的异常监测及上报流程的一示例的流程图。具体地，异常监测及上报流程主要包括节点的定时监测过程、异常判断过程以及上报过程，人脸图像搜索控制及分发中心对异常报告的处理，以及与用户的交互过程等。

如图9所示，在步骤910中，数据库监视模块的监测计时器根据配置的检测周期，定时去检测对应DB的连接及状态。

在步骤920中，数据库监视模块可以判断检测返回结果是数据库异常状态还是数据库正常状态。

如果步骤920中的检测返回结果为数据库异常状态，则跳转至步骤931，如果步骤920中的检测返回结果为数据库正常状态，则跳转至步骤933。

在步骤933中，数据库监视模块可以设置连续监测异常次数为零(即，invalidTimesCnt＝0)。

在步骤931中，数据库监视模块可以递增连续监测异常次数(即，invalidTimesCnt++)。

接着，在步骤940中，数据库监视模块可以判断连续监测异常次数是否大于或等于监测异常次数阈值(即，invalidTimesCnt>＝maxInvalidTimes？)。

如果步骤940中的判断结果为连续监测异常次数是大于或等于监测异常次数阈值，则跳转至步骤950。如果步骤940中的判断结果为连续监测异常次数是小于监测异常次数阈值，则跳转至步骤933。

在步骤950中，数据库监视模块可以通过对应节点向人脸图像搜索控制及分发中心上报数据库异常状态，并重置连续监测异常次数为零。进而，人脸图像搜索控制及分发中心中的数据安全控制模块在收到节点上报异常，可以根据节点状态表来读取该节点对应的数据库状态。这里，数据安全控制模块可以从业务计算节点和数据备份节点获知相应的数据库的状态，并对所上报的数据库异常状态进行处理。

在步骤960中，数据安全控制模块判断该节点所对应的数据库状态是否为正常状态。

如果步骤960中的检测结果为数据库处于正常状态，则跳转至步骤970。如果步骤960中的检测结果为数据库不处于正常状态，则继续检测数据库是否处于监测状态。

在步骤970中，数据安全控制模块向该节点下发重启指令以重启该节点和相应的DB，重置对应的数据库状态为监测状态，同时启动一个计时器监测计时器。这里，计时器监测计时器与节点对应，其计时时长是可以配置的，例如包含节点重启时长的10分钟。

接着，在步骤980中，数据安全控制模块检测在计时器监测计时器计时到期之前，数据安全控制模块是否持续收到该节点所上报的数据库异常状态。

如果在步骤980中的检测结果表示数据安全控制模块在计时到期之前没有再收到该节点所上报的数据库异常状态，则可以重置数据库的状态为正常状态，并停止计时器监测计时器。如果在步骤980中的检测结果表示数据安全控制模块在计时到期之前持续收到该节点所上报的数据库异常状态(例如，在计时期间一直收到数据库异常状态的监测结果)，则跳转至步骤990。

在步骤990中，数据安全控制模块重置数据库的状态为监测状态(即，DBStat＝Monitor)，并停止计时器监测计时器。

在步骤9100中，在数据库的状态为监测状态时，数据安全控制模块从节点状态表读取该节点对应的节点类型，并判断该节点的节点类型是否为业务节点(业务计算节点)。

如果在步骤9100中的判断结果指示节点类型是业务节点时，则跳转至步骤9110。如果在步骤9100中的判断结果指示节点类型不是业务节点时，则跳转至步骤9120。

在步骤9110中，数据安全控制模块可以向用户界面(user-interface)推送数据故障恢复通知“业务计算节点严重故障，请求进行数据恢复”，同时重置对应的数据库状态为故障状态(DBStat＝Breakdown)。

在步骤9120中，数据安全控制模块可以向用户界面(user-interface)推送数据故障恢复通知“数据备份节点严重故障，需要进行手动修复”，同时重置对应的数据库状态为故障状态(DBStat＝Breakdown)。

在步骤9130中，数据安全控制模块在推送数据故障恢复通知之后，数据安全控制模块启动等待计时器计时器，并检测在等待计时器计时期间是否收到数据恢复操作终止指令。

如果步骤9130中的检测结果表示在等待计时器计时期间收到数据恢复操作终止指令，则跳转至步骤9140。如果步骤9130中的检测结果表示在等待计时器计时期间没有收到数据恢复操作终止指令，则跳转至步骤9150。

在步骤9140中，数据安全控制模块忽略本次告警，重置对应的DBStat＝Monitor，并停止等待计时器。

在步骤9150中，数据安全控制模块触发数据恢复流程。

图10示出了根据如图7中的搜索系统的数据恢复流程的一示例的流程图。

如图10所示，当数据安全控制模块检测到等待计时器计时器超时，且当前业务计算节点所对应的数据库状态为故障状态(DBStat＝Breakdown)，则可以生成数据库切换指令，以触发数据恢复流程。

在步骤1010中，数据安全控制模块从节点状态表读取数据备份节点的数据库状态。

在步骤1020中，数据安全控制模块判断对应的数据库状态是否为故障状态。

如果步骤1020中的判断结果指示数据库状态是故障状态，则跳转至步骤1033。如果步骤1020中的判断结果指示数据库状态不是故障状态，则跳转至步骤1031。

在步骤1033中，数据安全控制模块确定数据恢复操作失败，可以执行数据恢复失败警示操作，例如发送数据恢复失败通知。示例性地，可以向用户界面推送告警信息“主、备数据库均严重故障，数据恢复失败！！！”。

在步骤1031中，数据安全控制模块修改节点状态表中节点的模式配置，将原业务计算节点和数据备份节点的模式互换。结合如表1中的示例，可以将node-2的节点类型重置为业务计算节点、数据库状态重置为正常状态，将node-1的节点类型重置为数据备份节点、数据库状态重置为监测状态。

在步骤1040中，重置业务计算节点的状态为正常状态，数据备份节点的状态为监测状态。

在步骤1050中，业务控制模块同时向业务计算节点和数据备份节点下发重启指令(或，节点类型配置指令)。

在步骤1060中，在节点重启成功后，激活数据备份节点的业务计算节点模式，即业务成功地切换到原备份节点上，从而完成数据恢复操作。由此，可以避免在节点运行状态下进行模式切换操作时的冲突或故障，并可以保障模式切换操作的可靠性。

通过本申请实施例，在搜索系统内部提供了备份恢复系统架构，可以智能化、自适应的机制来实时监测搜索系统当前主业务数据库的状态，并在数据库出现不可恢复的数据损坏后，可自适应地触发数据恢复过程，激活备份数据库的业务功能，将搜索业务请求无缝切换至激活后的备份数据库。

图11示出了根据本申请实施例的数据库故障恢复装置的一示例的结构框图。

如图11所示，数据库故障恢复装置1100包括数据库故障状态检测单元1110和数据服务恢复单元1120。

数据库状态检测单元1110被配置为检测业务数据库的状态，其中，所述服务器配置有用于响应业务查询请求的业务数据库和用于对所述业务数据库中的数据进行备份的备份数据库。

数据服务恢复单元1120被配置为当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

图12是本申请实施例的服务器的一示例的示意图。如图12所示，该实施例的服务器1200包括：处理器1210、存储器1220以及存储在所述存储器1220中并可在所述处理器1210上运行的计算机程序1230。所述处理器1210执行所述计算机程序1230时实现上述数据库故障恢复方法实施例中的步骤，例如图1所示的步骤110至123。或者，所述处理器1210执行所述计算机程序1230时实现上述各装置实施例中各模块/单元的功能，例如图11所示单元1110至1120的功能。

示例性的，所述计算机程序1230可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器1220中，并由所述处理器1210执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序1230在所述服务器1200中的执行过程。例如，所述计算机程序1230可以被分割成数据库状态检测模块和数据服务恢复模块，各模块具体功能如下：

数据库状态检测模块，被配置为检测业务数据库的状态，其中，所述服务器配置有用于响应业务查询请求的业务数据库和用于对所述业务数据库中的数据进行备份的备份数据库。

数据服务恢复模块，被配置为当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份。

所述服务器1200可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述服务器可包括，但不仅限于，处理器1210、存储器1220。本领域技术人员可以理解，图12仅是服务器1200的示例，并不构成对服务器1200的限定，可以包括比图示更多或少的部件，或组合某些部件，或不同的部件，例如所述服务器还可以包括输入输出设备、网络接入设备、总线等。

所称处理器1210可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器1220可以是所述服务器1200的内部存储单元，例如服务器1200的硬盘或内存。所述存储器1220也可以是所述服务器1200的外部存储设备，例如所述服务器1200上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器1220还可以既包括所述服务器1200的内部存储单元也包括外部存储设备。所述存储器1220用于存储所述计算机程序以及所述服务器所需的其他程序和数据。所述存储器1220还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/服务器和方法，可以通过其它的方式实现。例如，以上所描述的装置/服务器实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述单元既可以采用硬件的形式实现，也可以采用软件的形式实现。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (16)

1.一种数据库故障恢复方法，其特征在于，应用于服务器，所述方法包括：

检测业务数据库的状态，其中，所述服务器配置有用于响应业务查询请求的业务数据库和用于对所述业务数据库中的数据进行备份的备份数据库；

当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份。

2.如权利要求1所述的数据库故障恢复方法，其特征在于，所述检测业务数据库的状态，包括：

检测所述业务数据库是否工作异常；

在检测到所述业务数据库工作异常时，统计所述业务数据库工作异常的持续时间；

根据所述工作异常的持续时间，确定所述业务数据库的状态。

3.如权利要求2所述的数据库故障恢复方法，其特征在于，所述根据所述工作异常的持续时间，确定所述业务数据库的状态，包括：

当所述业务数据库工作异常的持续时间超过第一设定时间阈值时，执行数据故障恢复提示操作；

在执行数据故障恢复提示操作之后的设定时间段内，检测所述业务数据库是否持续工作异常以及是否存在数据恢复操作终止指令；

若在所述设定时间段内所述业务数据库持续工作异常且不存在所述数据恢复操作终止指令，则判定所述业务数据库处于数据库故障状态。

4.如权利要求1所述的数据库故障恢复方法，其特征在于，当所述业务数据库处于数据库故障状态时，所述方法还包括：

检测所述备份数据库的状态；

当所述备份数据库处于数据库故障状态时，执行数据恢复失败提示操作。

5.如权利要求1所述的数据库故障恢复方法，其特征在于，所述方法还包括：

获取业务请求所对应的数据库操作类型；

当所述数据库操作类型为业务查询类型时，调用用于响应业务查询请求的业务数据库或备份数据库来执行所述业务请求；

当所述数据库操作类型为数据删除类型或数据新增类型时，调用所述业务数据库和所述备份数据库分别来执行所述业务请求。

6.如权利要求2所述的数据库故障恢复方法，其特征在于，所述检测所述业务数据库是否工作异常，包括：

监测所述业务数据库是否丢失连接和响应业务查询请求的查询时延；

当所述业务数据库丢失连接且持续超过预设的正常时间阈值时，或者当所述业务数据库的所述查询时延超过预设的正常时延阈值时，确定所述业务数据库工作异常。

7.如权利要求1-6中任一项所述的数据库故障恢复方法，其特征在于，所述服务器中设置有数据库故障恢复模块、用于对所述业务数据库进行管理的第一管理节点模块和用于对所述备份数据库进行管理的第二管理节点模块，

其中，所述当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份，包括：

当所述业务数据库处于数据库故障状态时，所述数据库故障恢复模块发送数据库切换指令至所述第一管理节点模块和所述第二管理节点模块；

基于所述数据库切换指令，所述第二管理节点模块控制所述备份数据库来响应业务查询请求；以及

基于所述数据库切换指令，所述第一管理节点模块控制由所述业务数据库来对所述备份数据库中的数据进行备份。

8.一种数据库故障恢复装置，其特征在于，包括：

数据库状态检测单元，被配置为检测业务数据库的状态，其中，服务器配置有用于响应业务查询请求的业务数据库和用于对所述业务数据库中的数据进行备份的备份数据库；

数据服务恢复单元，被配置为当所述业务数据库处于数据库故障状态时，使用所述备份数据库来响应业务查询请求，并使用所述业务数据库来对所述备份数据库中的数据进行备份。

9.一种人脸图像搜索系统，其特征在于，包括人脸图像搜索控制及分发中心、第一节点和第二节点，其中所述人脸图像搜索控制及分发中心包括业务控制模块和数据安全控制模块，以及所述第一节点绑定有用于响应业务查询请求的业务数据库，所述第二节点绑定有用于对所述业务数据库中的数据进行备份的备份数据库，

所述数据安全控制模块，被配置为获取所述业务数据库的状态；

所述业务控制模块，被配置为当所述业务数据库处于数据库故障状态时，向所述第一节点和所述第二节点分别发送相应的节点类型配置指令，使得基于所述节点类型配置指令，所述第二节点使用所述备份数据库来响应业务查询请求，以及所述第一节点使用所述业务数据库来对所述备份数据库中的数据进行备份。

10.如权利要求9所述的人脸图像搜索系统，其特征在于，所述第一节点配置有数据库监视模块，被配置为监测所述业务数据库的状态；

相应地，所述数据安全控制模块被配置为从所述第一节点接收所述业务数据库的状态。

11.如权利要求10所述的人脸图像搜索系统，其特征在于，所述数据库监视模块还被配置为：

监测所述业务数据库是否丢失连接和响应业务查询请求的查询时延，以及当所述业务数据库丢失连接且持续超过预设的正常时间阈值时，或者当所述业务数据库的所述查询时延超过预设的正常时延阈值时，确定所述业务数据库处于数据库异常状态；

根据所述数据库异常状态，向所述数据安全控制模块发送所述业务数据库的状态。

12.如权利要求11所述的人脸图像搜索系统，其特征在于，所述数据库监视模块还被配置为：

根据预设的检测周期持续检测所述业务数据库的状态；

当检测到所述业务数据库处于数据库异常状态时，统计所述业务数据库出现数据库异常状态的对应所述检测周期的连续周期数；

根据所述连续周期数，确定相应的连续监测异常次数；

当所述连续监测异常次数超过预设的监测异常次数阈值时，向所述数据安全控制模块发送对应所述业务数据库的数据库故障状态。

13.如权利要求9所述的人脸图像搜索系统，其特征在于，所述业务控制模块被配置为：

当所述业务数据库处于数据库故障状态时，获取所述备份数据库的状态；

如果所述备份数据库处于数据库故障状态，则执行数据恢复失败警示操作；

如果所述备份数据库处于数据库正常状态，则向所述第一节点和所述第二节点分别发送相应的节点类型配置指令，使得基于所述节点类型配置指令，所述第二节点使用所述备份数据库来响应业务查询请求，以及所述第一节点使用所述业务数据库来对所述备份数据库中的数据进行备份。

14.如权利要求9所述的人脸图像搜索系统，其特征在于，所述第一节点和所述第二节点基于所述节点类型配置指令重启，以及重启成功后的所述第二节点使用所述备份数据库来响应业务查询请求，以及重启成功后的第一节点使用所述业务数据库来对所述备份数据库中的数据进行备份。

15.一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述方法的步骤。

16.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述方法的步骤。

Images