CN112231150A - 数据库集群中故障数据库恢复方法和装置 - Google Patents

Abstract

本申请提供一种数据库集群中故障数据库恢复方法和装置，其中方法包括：查找故障数据库中的第一重做日志；在所述第一重做日志不是所述故障数据库中最后重做日志的情况下：修改所述故障数据库，至所述故障数据库中的各个数据文件与所述正常数据库中对应的数据文件大小相同；定位所述第一重做日志后重做日志对应的可能问题数据块，采用所述正常数据库中相同位置的数据块覆盖所述可能问题数据块；以及，采用所述第二重做日志后至当前重做日志的所有重做日志，替换所述故障数据库中第一重做日志后的重做日志。这种恢复方法能够在网络资源和磁盘I/O资源占用较小的情况下，实现故障数据库的快速恢复。

Description

数据库集群中故障数据库恢复方法和装置

技术领域

本申请涉及数据库技术领域，尤其涉及一种数据库集群中故障数据库的恢复方法。

背景技术

数据库集群具有数据备份和故障切换能力，保证数据的安全性和数据库持续服务的稳定性。

为实现数据备份功能，数据库集群多包括一个主数据库和至少一个备数据库；主数据库提供读写(Read-Write)服务器，备数据库提供只读(Read-Only)服务；主数据库和备数据库间通过数据同步保证数据的一致性。为了避免主数据库发生故障(包括硬件故障和软件故障)而无法更新数据，数据库集群引入了故障切换能力；当主数据库发生故障时，自动地由集群选择备数据库切换为主数据库，而原主数据库被认定为故障数据库。在某一备数据库发生故障时，此备用数据也被认定为故障数据库。

为了保证数据库集群的安全可靠性，在数据库集群中的某一数据库被认定为故障数据库，需要尽快地使故障数据库恢复并重新加入到数据库集群；但是故障数据库自动恢复采用将主数据库的数据文件、控制文件拷贝至故障节点的数据库下而实现简单的数据恢复；这一恢复方式具有如下的缺点：因为需要考虑主数据库中的大量数据，导致恢复效率过低并占用大量的主数据库磁盘I/O和网络通信资源，造成数据库集群的可用性能降低；(2)数据库集群在恢复数据过程中，主数据库仍然对外提供服务而持续地写入，已经拷贝至故障数据库的数据被改写而造成主数据库和待恢复故障数据库的数据并不一致。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请提供了一种数据库集群中故障数据库恢复方法和装置。

一方面，本申请提供一种数据库集群中故障数据库恢复方法，包括：

查找故障数据库中的第一重做日志；所述第一重做日志为与正常数据库中重做日志相同的重做日志中，最新的重做日志；

在所述第一重做日志不是所述故障数据库中最后重做日志的情况下：

修改所述故障数据库，至所述故障数据库中的各个数据文件与所述正常数据库中对应的数据文件大小相同；

定位所述第一重做日志后重做日志对应的可能问题数据块，采用所述正常数据库中相同位置的数据块覆盖所述可能问题数据块；以及，

采用所述第二重做日志后至当前重做日志的所有重做日志，替换所述故障数据库中第一重做日志后的重做日志；所述第二重做日志为所述正常数据库中与所述第一重做日志相同的日志；所述当前重做日志为开始对故障数据库进行恢复时，正常数据库最新的重做日志。

可选地，所述正常数据库为在所述故障数据库恢复时提供数据服务的数据库；所述方法还包括：

获取所述正常数据库中第三重做日志；所述第三重做日志为所述当前重做日志后的重做日志；

复制所述第三重做日志至所述故障数据库；所述第三重做日志用于在所述故障数据库修复并启动后，修改数据库数据。

可选地，查找故障数据库中的第一重做日志，包括：

以所述最后重做日志开始，倒序地获取所述故障数据库的重做日志，并将获取的重做日志与所述正常数据库中的重做日志比较，直至查找到所述第一重做日志。

可选地，所述故障数据库和所述正常数据库均包括检查点日志；

以所述最后重做日志开始，倒序地获取所述故障数据库的重做日志，具体为：以所述最后重做日志开始，倒叙地获取所述故障数据库的检查点日志。

可选地，修改所述故障数据库，包括：

删除所述正常数据库没有但所述故障数据库具有的数据文件；和/或，

将所述正常数据库具有但所述故障数据库没有的数据文件复制到所述故障数据库；和/或，

删除所述故障数据库数据文件相对于所述正常数据库对应数据文件多余的部分；和/或，

将所述正常数据库数据文件相对于所述故障数据库对应数据文件中多出的部分，填充至所述故障数据库对应数据文件的尾部。

另一方面，本申请提供一种数据库集群中故障数据库恢复装置，包括：

查找单元，用于查找故障数据库中的第一重做日志；所述第一重做日志为与正常数据库中重做日志相同的重做日志中，最新的重做日志；

判断单元，用于判断所述第一重做日志是否为所述故障数据库中最后重做日志；

文件修改单元，用于修改所述故障数据库，至所述故障数据库中的各个数据文件与所述正常数据库中对应的数据文件大小相同；

数据块替换单元，用于定位所述第一重做日志后重做日志对应的可能问题数据块，采用所述正常数据库中相同位置的数据块覆盖所述可能问题数据块；

重做日志复制单元，用于采用所述第二重做日志后至当前重做日志的所有重做日志，替换所述故障数据库中第一重做日志后的重做日志；所述第二重做日志为所述正常数据库中与所述第一重做日志相同的日志；所述当前重做日志为开始对故障数据库进行恢复时，正常数据库最新的重做日志。

可选地，所述查找单元以所述最后重做日志开始，倒序地获取所述故障数据库的重做日志，并将获取的重做日志与所述正常数据库中的重做日志比较，直至查找到所述第一重做日志。

可选地，所述文件修改单元修改所述故障数据库，包括：

删除所述正常数据库没有但所述故障数据库具有的数据文件；和/或，

将所述正常数据库具有但所述故障数据库没有的数据文件复制到所述故障数据库；和/或，

删除所述故障数据库数据文件相对于所述正常数据库对应数据文件多余的部分；和/或，

将所述正常数据库数据文件相对于所述故障数据库对应数据文件中多出的部分，填充至所述故障数据库对应数据文件的尾部。

本申请提供的故障数据库恢复方法和装置，快速地根据正常数据库的重做日志、故障数据库的重做日志确定故障数据库数据与主数据的差异状态，并在二者具有差异的情况依据正常数据库文件修复故障数据库的数据，使其数据与正常数据库一致；具体应用中，这种恢复方法能够在网络资源和磁盘I/O资源占用较小的情况下，实现故障数据库的快速恢复。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

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

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

图2是本申请实施例提供的故障数据库的恢复方法流程图；

图3是本申请实施例提供的一种确定第一重做日志的方法流程图；

图4是本申请实施例提供的一种修复故障数据库的示意图；

图5是本申请实施例提供的故障数据库恢复装置结构示意图；

图6是本申请实施例提供的数据库服务器的结构示意图；

其中：11-查找单元，12-判断单元，13-文件修改单元，14-数据块替换单元，15-重做日志复制单元，21-处理器，22-存储器，23-通信接口，24-总线系统。

具体实施方式

为了能够更清楚地理解本申请的上述目的、特征和优点，下面将对本申请的方案进行进一步描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本申请，但本申请还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本申请的一部分实施例，而不是全部的实施例。

本申请实施例中，数据库集群中故障数据库的恢复过程为：在确定数据库集群中故障数据库后，以正常数据库作为修复的依据，使得故障数据库的数据修复与正常数据库的数据保持一致(或者保持某个时间节点一致，并可以通过修复后的数据同步实现一致)，并对故障数据库的其他故障进行识别，使得故障数据库修复为正常的数据库，而能够重新加入到数据库集群中提供数据库服务。

正常数据库可以是数据库集群中的主数据库，也可以是一备数据库，本申请实施例并不做特别地限定；考虑到实际应用中，主数据库执行数据的读写(Read-Write)服务，优选将主数据库作为正常数据库使用。

根据逻辑分析，故障数据库和正常数据库的数据对比情况包括如下情况。

1.故障数据库的数据量和正常数据库的数据量相同，并且数据一致。

2.故障数据库的数据量和正常数据库的数据量相同，但数据不一致。

3.故障数据库的数据量与正常数据库的数据量不同；具体又分为：(1)故障数据库的数据量小于正常数据库的数据量，故障数据库的全部数据和正常数据库的部分数据一致；(2)故障数据库的数据量少于正常数据库的数据量，故障数据库的部分数据和正常数据库对应部分的数据不一致；(3)故障数据库的数据量多于主数据的数据量，正常数据库的全部数据和故障数据库的部分数据一致；(4)故障数据库的数据量多于正常数据库的数据量，正常数据库的部分数据和故障数据库对应部分的数据不一致。

前述1-3情况中：情况1无数据差异而无需对故障数据库的数据进行修改；针对情况2和情况3，可以通过比较正常数据库和故障数据的数据量，确定差异情况，再根据差异情况对故障数据库的数据进行修改。

本申请实施例中，为了解决情况2和情况3中的问题，使得故障数据库的数据与正常数据库数据一致的方法包括：首先使得故障数据库和正常数据库的数据量达到一致；数据量达到一致的情况下再定位二者的差异数据，并利用正常数据库中的数据替换差异数据，以实现故障数据库中数据的恢复。

基于这样思路实现故障数据库中数据恢复的方法，需要考虑如何确定故障数据库的正常数据库是否具有差异，以及怎样在确定差异的情况下进行数据的替换。

图1是本申请实施例提供的数据库集群的架构示意图。如图1所示，本申请实施例中的数据库集群包括集群管理节点和数据库节点；为了实现对各个数据库节点数据库状态的监控，各个数据库节点除了配置数据库外，还配置有HA(High Availability)软件。

在在各个节点启动后，集群管理节点指定一节点的数据库为主数据库，其他节点的数据库为备数据库而建构其集群数据库；在各个节点数据库提供服务的过程中，部署在某一节点上的HA软件对此节点上的数据库状态进行探测，确定对应的数据库数据服务是否正常，以及与主数据库数据同步是否正常(针对备数据库节点)。

如果HA软件确定数据库服务不正常，或者与主数据库数据同步不正常，则确定此数据库故障，通知集群管理节点并启动数据库恢复。如果故障数据库为主数据库，集群管理节点为数据库集群重新指定另外一数据库节点作为主数据库节点。

图2是本申请实施例提供的故障数据库的恢复方法流程图。如图2所示，HA软件实现的故障数据库的恢复方法包括步骤S101-S106。

应当注意的是，实际应用中，HA软件可能还需要做一些准备性的工作，以保证故障数据库恢复过程中的数据传输的正常，避免故障数据库仍然向外提供服务，准备性工作包括：(1)确定故障数据库所在服务器的网络正常，以保证后续恢复过程中故障数据库所在的服务器能够与正常数据库所在的服务器、集群控制节点正常通信，实现信息和数据的传输；(2)确定故障数据库的服务已经关闭。随后，开始执行步骤S101-S106。

S101：查找故障数据库中的第一重做日志。

为了便于后续说明的理解，此处对本申请实施例中出现的几个术语先做解释。

第一重做日志：故障数据库中的重做日志中，与正常数据库中的某些重做日志相同重做日志中，最新的重做日志。

最后重做日志：故障数据库中所有重做日志中的最后一重做日志。

当前重做日志：在开始对故障数据库进行恢复时，正常数据库最新的一重做日志。

第二重做日志：正常数据库中与故障数据库中的第一重做日志相同的日志。

重做日志是数据库运行过程中产生的日志，其具有连续性和唯一性的特点，每一条重做日志都依赖于上一条重做日志，并且所有的重做日志都是唯一的。

基于前述特性，故障数据库中，在第一重做日志中之前的所有重做日志均与正常数据库中在第二重做日志之前的重做日志相同，相应的重做日志对应的数据库数据也相同。

而故障数据库中第一重做日志之后的重做日志，以及正常数据库的第二重做日志后的重做日志，可能为对应故障数据库中的数据与正常数据库中的不相同数据的重做日志。因此查找第一重做日志可以确定故障数据库与正常数据库中数据可能出现不同的起点。

本申请实施例具体应用中，查找故障数据库中的第一重做日志的方法可以为：以最后重做日志开始，倒叙地获取故障数据库的重做日志，并将获取的重做日志与正常数据库的重做日志比较，直至查找到第一重做日志。

图3是本申请实施例提供的一种确定第一重做日志的方法流程图。如图3所示，在本申请实施例一个具体应用中，查找第一重做日志的方法可以为S1011-S1016。

S1011：获取故障数据库的最后重做日志S_1，将最后重做日志S_1作为临时重做日志S_N。

S1012：获取临时重做日志S_N的标识符，将标识符发送给正常数据库所在节点。

为了实现本申请实施例中比较的功能，正常数据库提供一日志比较接口，用于根据故障数据库节点发送的信息，查找其内部中对应的重做日志，并将重做日志信息返回给故障数据库节点。

正常数据库所在的节点接收到临时重做日志的标识符后，根据标识符查找正常数据库是否有对应的重做日志；如果查找到正常数据库具有对应的重做日志P_N，计算对应的重做日志P_N的哈希值，并将哈希值作为返回值发送给故障数据库所在节点；如果没有对应的重做日志P_N，则生成-1作为返回值发送给故障数据库所在节点。

S1013：计算临时重做日志S_N的哈希值。

故障数据库所在节点在接收到返回值，并计算临时重做日志S_N的哈希值后，执行步骤S1014-S1016。

S1014：比较临时重做日志S_N的哈希值与返回值是否相同，如果相同，执行S1015；如果不同，执行S1016。

S1015：将临时重做日志S_N作为第一重做日志。

S1016：将临时重做日志S_N之前的重做日志S_N->prev作为新的临时重做日志S_N，并再次执行S1012。

前述步骤S1011-S1016中，通过计算对应重做日志P_N的哈希值作为返回值，与故障数据库节点中临时重做日志S_N哈希值进行比较，确定临时重做日志S_N是否为第一重做日志。因为重做日志P_N的哈希值相对于对应的重做日志P_N的长度短很多，仅传递哈希值可以减小对传输带宽的占用；此外采用哈希值，使得步骤S1014执行比较操作的效率较高。

在本申请实施例其他应用中，正常数据库所在节点生成的返回值也可以是重做日志P_N(在没有对应重做日志P_N的情况下，直接生成-1等特定值作为返回值)；对应的步骤S1014直接比较临时重做日志和接收到的返回值(为对应重做日志P_N或者其他特定的返回值)。

在其他实施例中，故障数据库所在节点也可以将临时重做日志S_N、其标识符或者哈希值发送给正常数据库所在节点，由正常数据库所在节点确定是否有相同的对应重做日志P_N，并在确定某一临时重做日志S_N具有对应重做日志P_N后，生成日志确定消息返回给故障数据库所在节点，以使得故障数据库所在节点确定临时重做日志S_N为第一重做日志。

数据库提供服务时会产生大量的重做日志，如果依次倒叙地获取故障数据库的各种重做日志，并将其与正常数据库的重做日志进行比较，直至查找到第一重做日志会消耗大量的资源，耗时也较长。

实际应用中，重做日志包括数据变更日志、检查点日志和事务日志等日志；其中检查点日志专门用于表示在此日志之前的数据均达到了一致性状态，并且相应的数据已经持久化到磁盘。

为减少查找第一重做日志时的资源消耗，在本申请实施例一个具体应用中，可以从最后重做日志开始，倒叙地获取故障数据库的检查点日志，并将检查点日志与正常数据库的重做日志比较而确定第一重做日志。基于此项操作，对应的第一重做日志和第二重做日志均为检查点日志。

S102：判断第一重做日志是否为故障数据库的最后重做日志；若否，执行S103；若是，执行S106。

如果第一重做日志是故障数据库的最后重做日志，则确定故障数据库恢复操作开始时，故障数据库的数据与正常数据库的某一时间点的数据一致，仅可能是二者并没有完全同步(例如在正常数据库为主数据库的情况下，主数据库的某些较新的重做日志没有同步至故障数据库)。此时无需对故障数据库的数据进行修改，仅需要执行步骤S106。

而如果第一重做日志并不是故障数据库的最后重做日志，则确定故障数据库恢复操作开始时，故障数据库与正常数据库的数据可能并不一致。此时，需要基于正常数据库对故障数据库进行修改，此时执行步骤S103。

S103：修改故障数据库，至故障数据库中的各个数据文件与正常数据库对应的数据文件大小相同。

步骤S103具体实施中，可以获取正常数据库和故障数据库的文件列表，正常数据库和故障数据库的文件列表均包括文件名和文件长度信息。通过比较正常数据库和故障数据的文件列表，可以确定正常数据库文件和故障数据库的差异，随后基于差异修改故障数据库中的文件，至故障数据库与主数据库对应的数据文件大小相同。

为了实现步骤S103和后续步骤S104的功能，正常数据库应当提供一数据查询传输接口，以能够向故障数据库提供其请求复制的数据文件或者数据块。

本申请实施例中，基于文件列表差异修改故障数据库中的数据文件可能包括如下中的一种或多种。

(1)删除正常数据库没有但故障数据库具有的数据文件。

(2)删除故障数据库数据文件相对于正常数据库对应数据文件多余的部分。具体应用中，如果数据文件较大，可以采用截短(Truncate)方法，删除文件多余部分。

(3)将正常数据库具有但是故障数据库没有的数据文件复制到故障数据库。

(4)将正常数据库数据文件相对于故障数据库对应数据文件中多余的部分，填充至故障数据库对应数据文件的尾部。

通过步骤S103后，故障数据库中数据文件的大小和主数据文件大小被调整为一致，为后续步骤S104提供基础。

S104：定位第一重做日志后重做日志对应的可能问题数据块，采用正常数据库中相同位置的数据块覆盖可能问题数据块。

步骤S103中仅是将故障数据库和主数据的数据文件大小调整到一致，也就是让故障数据库和正常数据库数据文件中的大多数数据维持至一致。

但是，单独执行步骤S103并不能使得故障数据库和正常数据库的数据保证一致为了使得故障数据库中数据文件与正常数据库数据文件数据一致，即需要在步骤S103的基础上，查找到数据块中的可能问题数据块，并修改此类数据块。

根据数据库原理可知，故障数据库中第一重做日志后的重做日志对应对故障数据库数据文件的修改，因此利用这些重做日志可以确定可能问题数据块。在确定可能问题数据块后，采用正常数据库相同位置的数据块覆盖可能问题数据块，即可以使得故障数据块的数据和主数据完全一致。

应当注意的是，因为前述步骤的S103以及相应重做日志的操作类型，第一重做日志至后重做日志对应的可能问题数据块可能存在，也可能并不存在。

通过前述的步骤S103-S104，故障数据库的数据文件被同步至正常数据库一致。

图4是本申请实施例提供的一种修复故障数据库的示意图。如图4所示，用于参照的正常数据库为主数据库。在对故障数据库修复过程中，采用步骤S103确定故障数据库相比于主数据库具有多余的数据块0x78和0xFA，缺少数据块0X0F，因此删除两个多余的数据块并增加缺失的数据块，使得故障数据库和主数据库的数据量一致；采用S104步骤后，根据第一重做日志后的重做日志确定故障数据库相比于主数据库具有可能问题数据块0xDF，因此查找到主数据块对应位置的数据块0xA9替换问题数据块；最后，故障数据库的数据和主数据库的数据一致。

以下对本申请前述步骤S102-S104的出发点和有益效果做分析。

根据数据库数据的操作思路，针对故障数据库的数据恢复，可以从最后重做日志至第一重做日志，采用undo操作回退数据，回退至第一重做日志对应的数据状态；随后再从第一重做日志(也就是从第二重做日志开始)开始，采用正常数据库中在第二重做日志后的重做日志，将故障数据库的数据修改至与正常数据库一致的状态。

但是，这样的操作需要保证故障数据库处在开启的状态，能够进行undo操作和redo操作。但是，实际情况是，在进行数据库恢复的过程中，并不能使得数据库处在开启状态，而HA软件并没有数据库操作的功能。因为undo操作和redo操作对应的数据是随机分布的，采用前述操作思路磁盘的随机写性能较低，会消耗大量的I/O资源。此外，当前并没有undo日志。

为了克服前述的问题，本申请实施例考虑对故障数据库进行undo操作和redo操作，最终效果是更改数据库的数据文件或者数据块，因此可以直接以主数据的数据文件为基础，查找故障数据库数据文件与正常数据库数据文件不同之处，再修改这些不同之处而使得故障数据库与正常数据库一致。

本申请实施例中，步骤S103通过文件对比对故障数据库进行修改，删除故障数据库多余的文件块，添加主数据多出的文件块，使得故障数据库与正常数据库的数据文件保持相同大小。因为数据库中的文件是连续的，对应的数据块也是连续的，通过文件的比对可快速地使得数据大小恢复至一致。

随后步骤S104利用故障数据库中第一重做日志后的重做日志定位可能问题数据块，并将正常数据库对应位置的数据块替换可能问题数据块，实现可能问题数据块的快速覆盖，而实现了故障数据库数据与正常数据库数据的同步。

采用本申请实施例提供的方法，无需获取故障数据库的undo日志，也无需启动数据库实现undo操作和redo操作，即可以实现对故障数据库数据的同步。

采用本申请实施例提供的方法，对数据库数据文件的操作仅需要定位数据文件或数据块，再实现对数据块的复制和删除，其处理效率较高。此外，因为步骤S103和S104的复制修改操作，仅是复制了正常数据库少量数据，无需复制正常数据库的全部数据，不会占用正常数据库磁盘的I/O资源，也不会占用大量的网络资源。

完成步骤S104后，即可以执行步骤S105。

S105：采用第二重做日志至所述当前重做日志，替换故障数据库中的第一重做日志至最后重做日志。

在执行步骤S104后，故障数据库中在第一重做日志不能再使用，此类重做日志需要删除。另外，为了使得正常数据库与故障数据库一致同步，还需要将正常数据库中第二重做日志至当前重做日志之间添加至第一重做日志后；此时，也可以直接使用第二重做日志至当前重做日志，替换故障数据库中的第一重做日志后的重做日志。

S106：故障数据库中的数据恢复结束。

在故障数据库中的数据恢复结束后，并且故障数据库其他故障被接触后，故障数据库即被恢复至一正常数据库；随后可以将修复后的数据库加入到数据集群中。

结合前述的分析，本申请实施例提供的故障数据库恢复方法，能够在识别出故障数据库后，快速地根据正常数据库的重做日志、故障数据库的重做日志确定故障数据库数据与主数据的差异状态，并在二者具有差异的情况依据正常数据库文件修复故障数据库的数据，使其数据与正常数据库一致；具体应用中，这种恢复方法能够在网络资源和磁盘I/O资源占用较小的情况下，实现故障数据库的快速恢复。

本申请实施例具体应用中，正常数据库可以是在执行前述恢复操作过程中向外提供数据服务的数据库，也可以是一暂停服务的数据库。如果正常数据库为一暂停提供数据服务的数据库，则在执行前述恢复操作过程中，正常数据库并不会生成(此时正常数据库为主数据库)或者获取到(此时正常数据库为备数据库)第三重做日志；而在正常数据库为仍提供数据服务的数据库，则正常数据库在当前重做日志后还可能会生成或者获得第三重做日志。

对应正常数据库为在执行恢复操作过程中向外提供数据服务的数据库，本申请实施例提供的方法在前述的S105后，还可以包括S107-S108。

S107：获取正常数据库的第三重做日志。

第三重做日志是正常数据库中在当前重做日志之后的重做日志；也就是在开始对故障数据库进行恢复后，正常数据库向外提供数据服务时、新生成的重做日志或者与主数据库同步的重做日志。当然，在一些应用中，如果在故障数据库进行恢复过程中，如果没有触发正常数据库提供数据服务，也可能就没有第三重做日志。

S108：复制第三重做日志至故障数据库。

复制第三重做日志至故障数据库，是将第三重做日志复制到故障数据库的重做日志文件中，并放置在前述的当前重做日志之后。第三重做日志用于在故障数据库修复并启动后，修改数据库数据；即故障数据库在重新启动并恢复后，根据第三重做日志修改数据库数据，使数其数据与正常数据库一致。

为了实现故障数据库重新启动并恢复后，利用第三重做日志修改数据库数，还需要生成数据库恢复控制文件；数据库恢复控制文件中记录恢复开始的第三重做日志和恢复结束的第三重做日志。在故障数据库启动后，可以根据数据库恢复控制文件，调用第三重做日志对数据库数据执行redo操作，以使得数据库同步至与正常数据库一致。

经过前述的步骤S101-S106后，并且故障数据库的其他故障被恢复后，即可以启动数据库并确定故障数据库是否正常；具体的，可以通过执行数据库查询语句判断数据库服务是否成功启动，以及判断故障数据库与正常数据库的同步是否正常确定故障数据库是否正常。

如果数据库服务成功启动并且数据库同步正常，则可以认定故障数据库为修复数据库，通知集群管理节点将此数据库加入到数据库集群中提供服务。

本申请实施例除了提供前述的故障数据库恢复方法外，还提供一种故障数据库恢复装置。

图5是本申请实施例提供的故障数据库恢复装置结构示意图。如图5所示，故障数据库恢复装置包括查找单元11、判断单元12、文件修改单元13、数据块替换单元14和重做日志复制单元15。

查找单元11用于查找故障数据库中的第一重做日志；第一重做日志为与正常数据库中重做日志相同的重做日志中，最新的重做日志。

在一个具体应用中，查找单元11可以以最后重做日志开始，倒序地获取故障数据库的重做日志，并将获取的重做日志与正常数据库中的重做日志比较，直至查找到第一重做日志。具体的倒序查找方法可以参见前文方法步骤S1011-S1016。

判断单元12用于判断第一重做日志是否为故障数据库中最后重做日志。

如果第一重做日志是故障数据库的最后重做日志，则确定故障数据库恢复操作开始时，故障数据库的数据与正常数据库的某一时间点的数据一致，仅可能是二者并没有完全同步(例如在正常数据库为主数据库的情况下，主数据库的某些较新的重做日志没有同步至故障数据库)。此时无需对故障数据库的数据进行修改。而如果第一重做日志并不是故障数据库的最后重做日志，则确定故障数据库恢复操作开始时，故障数据库与正常数据库的数据可能并不一致

文件修改单元13用于修改故障数据库，至故障数据库中的各个数据文件与正常数据库中对应的数据文件大小相同。

在具体应用中，文件修改单元13修改故障数据库可能包括：

(1)删除正常数据库没有但故障数据库具有的数据文件；

(2)删除故障数据库数据文件相对于正常数据库对应数据文件多余的部分。具体应用中，如果数据文件较大，可以采用截短(Truncate)方法，删除文件多余部分；

(3)将正常数据库具有但是故障数据库没有的数据文件复制到故障数据库；

(4)将正常数据库数据文件相对于故障数据库对应数据文件中多余的部分，填充至故障数据库对应数据文件的尾部。

数据块替换单元14用于定位第一重做日志后重做日志对应的可能问题数据块，采用正常数据库中相同位置的数据块覆盖可能问题数据块。

重做日志恢复单元用于采用第二重做日志后至当前重做日志的所有重做日志，替换故障数据库中第一重做日志后的重做日志；第二重做日志为正常数据库中与第一重做日志相同的日志；当前重做日志为开始对故障数据库进行恢复时，正常数据库最新的重做日志。

在一个具体应用中，重做日志会单元还可以获取正常数据库中的第三重做日志并复制至故障数据库中。第三重做日志用于在故障数据库修复并启动后修改数据库数据。

本申请实施例提供的故障数据库恢复装置，能够在识别出故障数据库后，快速地根据正常数据库的重做日志、故障数据库的重做日志确定故障数据库数据与主数据的差异状态，并在二者具有差异的情况依据正常数据库文件修复故障数据库的数据，使其数据与正常数据库一致；具体应用中，这种恢复方法能够在网络资源和磁盘I/O资源占用较小的情况下，实现故障数据库的快速恢复。

本申请实施例还提供一种实现前述方法的数据库服务器；多个数据库服务器组成了数据库集群，以向外提供数据服务。

图6是本申请实施例提供的数据库服务器的结构示意图。如图6所示，数据库服务器包括至少一个处理器21、至少一个存储器22、至少一个通信接口23和总线系统24。

数据库服务器中的各个组件通过总线系统24耦合在一起，总线系统24用于实现这些组件之间的连接通信。总线系统24除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。

可以理解，本实施例中的存储器22可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。

在一些实施方式中，存储器22存储了如下的元素，可执行单元或者数据结构，或者他们的子集，或者他们的扩展集：操作系统和应用程序。

其中，操作系统包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础任务以及处理基于硬件的任务。应用程序，包含各种应用程序，例如数据库程序和HA软件程序。实现本公开实施例提供的故障数据库恢复方法可以包含在HA软件程序中。

在本公开实施例中，处理器21通过调用存储器22存储的程序或指令，执行本申请提供的故障数据库恢复方法的各个步骤。

本公开实施例提供的故障数据库恢复方法步骤也可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器22，处理器21读取存储器22中的信息，结合其硬件完成方法的步骤。

本公开实施例还提出一种非暂态计算机可读存储介质，非暂态计算机可读存储介质存储程序或指令，程序或指令使计算机执行如前故障数据库恢复方法各实施例的步骤，为避免重复描述，在此不再赘述。

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

以上所述仅是本申请的具体实施方式，使本领域技术人员能够理解或实现本申请。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种数据库集群中故障数据库恢复方法，其特征在于，包括：

查找故障数据库中的第一重做日志；所述第一重做日志为与正常数据库中重做日志相同的重做日志中，最新的重做日志；

在所述第一重做日志不是所述故障数据库中最后重做日志的情况下：

修改所述故障数据库，至所述故障数据库中的各个数据文件与所述正常数据库中对应的数据文件大小相同；

定位所述第一重做日志后重做日志对应的可能问题数据块，采用所述正常数据库中相同位置的数据块覆盖所述可能问题数据块；以及，

采用所述第二重做日志后至当前重做日志的所有重做日志，替换所述故障数据库中第一重做日志后的重做日志；所述第二重做日志为所述正常数据库中与所述第一重做日志相同的日志；所述当前重做日志为开始对故障数据库进行恢复时，正常数据库最新的重做日志。

2.根据权利要求1所述的故障数据库的恢复方法，其特征在于，所述正常数据库为在所述故障数据库恢复时提供数据服务的数据库；所述方法还包括：

获取所述正常数据库中第三重做日志；所述第三重做日志为所述当前重做日志后的重做日志；

复制所述第三重做日志至所述故障数据库；所述第三重做日志用于在所述故障数据库修复并启动后，修改数据库数据。

3.根据权利要求1或2所述的故障数据库恢复方法，其特征在于，查找故障数据库中的第一重做日志，包括：

以所述最后重做日志开始，倒序地获取所述故障数据库的重做日志，并将获取的重做日志与所述正常数据库中的重做日志比较，直至查找到所述第一重做日志。

4.根据权利要求3所述的故障数据库恢复方法，其特征在于，

所述故障数据库和所述正常数据库均包括检查点日志；

以所述最后重做日志开始，倒序地获取所述故障数据库的重做日志，具体为：以所述最后重做日志开始，倒叙地获取所述故障数据库的检查点日志。

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

删除所述正常数据库没有但所述故障数据库具有的数据文件；和/或，

将所述正常数据库具有但所述故障数据库没有的数据文件复制到所述故障数据库；和/或，

删除所述故障数据库数据文件相对于所述正常数据库对应数据文件多余的部分；和/或，

将所述正常数据库数据文件相对于所述故障数据库对应数据文件中多出的部分，填充至所述故障数据库对应数据文件的尾部。

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

查找单元，用于查找故障数据库中的第一重做日志；所述第一重做日志为与正常数据库中重做日志相同的重做日志中，最新的重做日志；

判断单元，用于判断所述第一重做日志是否为所述故障数据库中最后重做日志；

文件修改单元，用于修改所述故障数据库，至所述故障数据库中的各个数据文件与所述正常数据库中对应的数据文件大小相同；

数据块替换单元，用于定位所述第一重做日志后重做日志对应的可能问题数据块，采用所述正常数据库中相同位置的数据块覆盖所述可能问题数据块；

重做日志复制单元，用于采用所述第二重做日志后至当前重做日志的所有重做日志，替换所述故障数据库中第一重做日志后的重做日志；所述第二重做日志为所述正常数据库中与所述第一重做日志相同的日志；所述当前重做日志为开始对故障数据库进行恢复时，正常数据库最新的重做日志。

7.根据权利要求6所述的故障数据库恢复装置，其特征在于，

所述查找单元以所述最后重做日志开始，倒序地获取所述故障数据库的重做日志，并将获取的重做日志与所述正常数据库中的重做日志比较，直至查找到所述第一重做日志。

8.根据权利要求6所述的故障数据库恢复装置，其特征在于，所述文件修改单元修改所述故障数据库，包括：

删除所述正常数据库没有但所述故障数据库具有的数据文件；和/或，

将所述正常数据库具有但所述故障数据库没有的数据文件复制到所述故障数据库；和/或，

删除所述故障数据库数据文件相对于所述正常数据库对应数据文件多余的部分；和/或，

将所述正常数据库数据文件相对于所述故障数据库对应数据文件中多出的部分，填充至所述故障数据库对应数据文件的尾部。

9.一种数据库服务器，其特征在于，包括处理器和存储器；

所述处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至5任一项所述方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至5任一项所述方法的步骤。

Images