CN108762982A - 一种数据库恢复方法、装置及系统 - Google Patents

Abstract

本申请提供一种数据库恢复方法、装置及系统，方法应用于数据库恢复系统中主中心的灾备引擎设备，方法包括：基于灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从灾备服务器获取待恢复数据库的配置信息；利用获取的配置信息向中间件发送配置指令，以使中间件创建待恢复数据库的新实例；从灾备服务器获取待恢复数据库的业务数据表，基于分库分表策略将获取的业务数据表写入存储设备。整个数据库恢复过程通过灾备引擎设备完成，使得中间件可专门处理业务，因此相对现有技术，中间件对业务的处理性能可提升一倍。又由灾备引擎设备专门用于数据库恢复，因此可缩短恢复耗时。

Description

一种数据库恢复方法、装置及系统

技术领域

本申请涉及数据库技术领域，尤其涉及一种数据库恢复方法、装置及系统。

背景技术

随着数据量的高速增长，数据库的架构开始由集中式向分布式发展。目前所使用的分布式数据库系统通常包括分布式数据库的中间件、分布式数据库等。为了保证分布式数据库系统的安全性，通常需要进行数据库灾备以用于后续数恢复。

在相关技术中，在对某一业务的数据库进行恢复时，灾备管理设备先从灾备中心的灾备服务器获取待恢复数据库的配置信息，并将待恢复数据库的配置信息发送至主中心的中间件，以使中间件根据配置信息创建待恢复数据库的实例，并基于分库分表策略自动生成待恢复数据库的路由信息；然后灾备管理设备再从灾备中心的灾备服务器获取待恢复数据库的业务数据表，并将业务数据表发送至主中心的中间件，并由中间件根据待恢复数据库的路由信息，将业务数据表写入主中心的存储设备中，从而完成数据库的恢复。

然而，由于主中心的中间件除了需要处理待恢复数据库的数据写入过程，还需要处理业务对其他数据库的访问，因此主中心的中间件的处理压力比较大，进而影响到业务对数据库的访问性能，降低用户使用体验。

发明内容

有鉴于此，本申请提供一种数据库恢复方法、装置及系统，以解决现有恢复方式会影响业务对数据库的访问性能，降低用户使用体验的问题。

根据本申请实施例的第一方面，提供一种数据库恢复方法，所述方法应用于数据库恢复系统中主中心的灾备引擎设备，所述数据库恢复系统还包含灾备管理设备、灾备中心的灾备服务器，以及主中心的存储设备，所述方法包括：

步骤一、基于所述灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从所述灾备服务器获取待恢复数据库的配置信息；

步骤二、利用获取的配置信息向所述中间件发送配置指令，以使所述中间件创建待恢复数据库的新实例；

步骤三、从所述灾备服务器获取待恢复数据库的业务数据表，并基于分库分表策略将获取的业务数据表写入所述存储设备。

根据本申请实施例的第二方面，提供一种数据库恢复系统，所述系统包括：

灾备管理设备，用于向主中心的灾备引擎设备发送携带待恢复数据库的老实例的标识的恢复指令；

灾备中心的灾备服务器，用于存储待恢复数据库的配置信息和业务数据表；

主中心的灾备引擎设备，用于基于携带待恢复数据库的老实例的标识的恢复指令，从所述灾备服务器获取待恢复数据库的配置信息，并利用获取的配置信息向中间件发送配置指令；从所述灾备服务器获取待恢复数据库的业务数据表，并基于分库分表策略将获取的业务数据表写入主中心的存储设备；

主中心的中间件，用于基于所述配置指令，创建待恢复数据库的新实例；

主中心的存储设备，用于存储所述灾备引擎设备写入的业务数据表。

根据本申请实施例的第三方面，提供一种数据库恢复装置，所述装置应用于数据库恢复系统中主中心的灾备引擎设备，所述数据库恢复系统还包含灾备管理设备、灾备中心的灾备服务器，以及主中心的存储设备，所述装置包括：

第一获取模块，用于基于所述灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从所述灾备服务器获取待恢复数据库的配置信息；

第一发送模块，用于利用获取的配置信息向所述中间件发送配置指令，以使所述中间件创建待恢复数据库的新实例；

第二获取模块，用于从所述灾备服务器获取待恢复数据库的业务数据表；

写入模块，用于基于分库分表策略将获取的业务数据表写入所述存储设备。

应用本申请实施例，灾备引擎设备在接收到灾备管理设备发送的恢复指令之后，基于灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从灾备服务器获取待恢复数据库的配置信息，并利用获取的配置信息向中间件发送配置指令，以使中间件创建待恢复数据库的新实例；从灾备服务器获取待恢复数据库的业务数据表，并基于分库分表策略将获取的业务数据表写入存储设备，从而完成数据库恢复。基于上述描述可知，整个数据库的恢复过程都是通过灾备引擎设备完成，使得主中心的中间件可以专门处理其他业务对数据库的访问，因此本申请相对现有技术，主中心的中间件对其他业务的处理性能至少能够提升一倍，进而提升了用户的使用体验。同时，由于灾备引擎设备专门用于进行数据库恢复过程，不需要处理其他业务，因此可以很大程度缩短恢复耗时。

附图说明

图1为本申请根据一示例性实施例示出的现有的数据库恢复系统结构示意图；

图2为本申请根据一示例性实施例示出的一种数据库恢复系统结构示意图；

图3为本申请根据一示例性实施例示出的一种数据库恢复方法的实施例流程图；

图4为本申请根据一示例性实施例示出的另一种数据库恢复方法的实施例流程图；

图5为本申请根据一示例性实施例示出的一种灾备引擎设备的硬件结构图；

图6为本申请根据一示例性实施例示出的一种数据库恢复装置的实施例结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1为本申请根据一示例性实施例示出的现有的数据库恢复系统结构示意图，图1所示的恢复系统包括灾备管理设备、主中心的中间件和各存储设备(图1列举了3个存储设备)，以及灾备中心的灾备服务器。其中，灾备管理设备可以分别与主中心和灾备中心通过网络进行交互，用于从灾备服务器获取待恢复数据库的数据(如元数据和业务数据)，并发送至主中心的中间件中，并由中间件完成数据库恢复；主中心的中间件用于管理数据库，例如对数据库进行配置、监控、数据迁移、同步备份，以及处理各业务对数据库的访问(通过为各个数据库创建的实例实现)，记录有数据库的元数据(例如数据库的配置信息和分库分表的路由信息)。

对于数据库的恢复，可理解为数据灾备的逆向过程，即需要保证业务数据、元数据按照要求(如恢复至哪一时间点、哪些数据库需要恢复等)恢复，并保证恢复数据的一致性。

下面结合图1，详细介绍现有技术中灾备管理设备如何与主中心的中间件交互完成数据库的恢复：

当灾备管理设备接收到数据库恢复指令时，基于该指令中携带的时间点和待恢复数据库的实例标识，从灾备服务器中读取并解开该时间点对应的待恢复数据库的元数据文件，以提取待恢复数据库的配置信息，并将待恢复数据库的配置信息写入主中心的中间件，以使中间件根据配置信息创建待恢复数据库的新实例，并自动生成待恢复数据库的路由信息；然后灾备管理设备再从灾备服务器读取并解开待恢复数据库的业务数据文件，以提取业务数据表，并将业务数据表写入主中心的中间件，并由中间件根据生成的路由信息，将业务数据表写入主中心的存储设备中。

由于在数据库恢复过程中，元数据写入与业务数据写入需要顺序执行，并且各个待恢复数据库的业务数据也需要根据路由信息顺序写入，

在一示例性场景中，假设有10个数据库的实例需要恢复，对应的元数据文件大小有1M左右，平均每个数据库的实例对应的业务数据文件大小为50G，解开之后大小为100G，经过测试，对于元数据文件的读取、解开、写入，需要12秒-15秒，每个数据库的业务数据文件的读取、解开、写入，需要3.5小时，因此对于10个数据库的实例至少需要35个小时(一天多的时间)才能恢复完成。由此可知整个恢复过程相当耗时。

此外，主中心的中间件除了需要处理待恢复数据库的数据写入过程，还需要处理其他业务对数据库的访问，因此主中心的中间件的处理压力比较大，尤其在需要恢复的数据量大的情况下，会严重影响业务对数据库的访问性能，降低用户使用体验。

基于此，图2为本申请根据一示例性实施例示出的一种数据库恢复系统结构示意图，本申请在上述图1的基础上，在主中心中增加了灾备引擎设备，该灾备引擎设备可以与灾备管理设备，以及灾备中心的灾备服务器通过网络进行交互。在进行数据库恢复过程中，灾备引擎设备基于灾备管理设备发送的恢复指令的触发，从灾备服务器获取待恢复数据库的元数据和业务数据，并分别将元数据恢复至主中心的中间件，业务数据恢复至主中心的存储设备。

由此可知，整个恢复系统在完成数据库恢复过程中，由灾备引擎设备完成数据获取及恢复，主中心的中间件专门用于处理其他业务对数据库的访问，从而本申请通过业务数据流和恢复数据流的分离，确保了业务的稳定性、可靠性。另外，由于元数据需要恢复至中间件，业务数据需要恢复至存储设备，因此灾备引擎设备对于元数据的恢复和业务数据的恢复可以同步执行恢复，互不影响，从而可以缩短恢复耗时。

下面以具体实施例详细介绍本申请的技术方案：

图3为本申请根据一示例性实施例示出的一种数据库恢复方法的实施例流程图，结合上述图2所示的数据库恢复系统结构示意图，该数据库恢复方法可以应用在主中心的灾备引擎设备(如PC机)中。本申请实施例中所涉及的数据库可以是分布式数据库。如图3所示，该数据库恢复方法包括如下步骤：

步骤301：基于灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从灾备服务器获取待恢复数据库的配置信息。

在一实施例中，当某一业务运行异常时，可以对该业务涉及的数据库重新进行恢复，或者某用户的数据库遭到攻击破坏后，需要对该用户的数据库重新进行恢复，或者机房发生火灾，导致主中心中所有数据库的资源池烧毁，需要重新恢复该中心的所有数据库。基于此，通过向灾备管理设备输入待恢复数据库的老实例的标识，触发灾备管理设备生成恢复指令，并将生成的恢复指令发送至灾备引擎设备，从而灾备引擎设备可以接收到灾备管理设备发送的恢复指令。

其中，待恢复的数据库由一个实例构成，老实例指的是备份到灾备服务器中的数据库对应的实例。本领域技术人员可以理解的是，实例的标识既可以是数字或字母，也可以是数字与字母的结合，本申请在此不进行限定。

在一实施例中，针对从灾备服务器获取待恢复数据库的配置信息的过程，由于灾备服务器为了节省备份数据所占的存储空间，对于数据库的元数据的存储，通常是压缩为一个文件进行存储的，因此灾备引擎设备可以先从灾备服务器读取待恢复数据库的元数据文件，然后再解析并提取元数据文件中待恢复数据库的配置信息。

其中，待恢复数据库的配置信息指的是在创建数据库的实例时所需要的元数据，例如，数据库的实例规格、数据库包含的表、数据库生成时间，以及有访问权限的用户等信息。

步骤302：利用获取的配置信息向中间件发送配置指令，以使中间件创建待恢复数据库的新实例。

在一实施例中，由于用户在访问数据库数据时，是通过访问中间件中的数据库的实例完成的，因此灾备引擎设备在进行数据库恢复时，需要向中间件发送配置指令，中间件利用配置指令携带的配置信息为待恢复数据库新建一个新实例，从而完成元数据的恢复。其中，中间件创建的待恢复数据库的新实例的标识可以与上述步骤301所述的老实例的标识相同，也可以不相同。

需要说明的是，灾备引擎设备在利用获取的配置信息向中间件发送配置指令之后，还可以从元数据文件中提取中间数据表，所述中间数据表指的是在使用待恢复数据库过程中产生的数据表，并将提取的中间数据表发送至中间件创建的待恢复数据库的新实例中，从而可以确保恢复数据的一致性。

需要进一步说明的是，灾备引擎设备在利用获取的配置信息向中间件发送配置指令之后，还可以接收中间件返回的待恢复数据库的新实例的标识，并在从元数据文件中提取中间数据表之后，再利用新实例的标识更新中间数据表中记录的老实例的标识，从而在将中间数据表恢复至中间件创建的新实例中后，能够保证业务正常运行。

步骤303：从灾备服务器获取待恢复数据库的业务数据表，并基于分库分表策略将获取的业务数据表写入存储设备。

在一实施例中，由于每个数据库包含多个业务数据表，且每个业务数据表所占存储空间也比较大，因此灾备服务器在备份数据库时，通常是将数据库包含的业务数据表压缩为文件进行存储，因此灾备引擎设备可以先从灾备服务器度读取待恢复数据库的业务数据文件，然后再解析业务数据文件以提取业务数据表。其中，业务数据表中记录有业务数据。

在一实施例中，分库分表策略可以是哈希策略，也可以是权重策略，本申请在此不进行限定。由于灾备引擎设备相对中间件无需处理其他业务，可以专门处理业务数据的写入过程，因此恢复写入耗时短。针对基于分库分表策略将获取的业务数据表写入存储设备的详细描述，可以参见下述图4所示实施例的相关描述，在此暂不详述。

需要说明的是，上述步骤302和步骤303可以同步执行，以缩短数据库的恢复耗时。

针对上述步骤301至步骤303的过程，基于上述图1所示的示例性场景，10个数据库的实例需要恢复，对应1M左右的元数据文件，平均每个数据库的实例对应的业务数据文件大小为50G，解开之后大小为100G。由于元数据的恢复和业务数据的恢复可以同步执行恢复，且元数据的文件本身并不大，因此元数据的恢复耗时可以忽略不计，只考虑业务数据的恢复耗时，经过测试，对于1个包含50G大小的业务数据文件的数据库的实例，最终恢复至存储设备，需要的耗时仅为25分钟(与现有方案相比缩短了至少3小时)。

本实施例中，灾备引擎设备在接收到灾备管理设备发送的恢复指令之后，基于灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从灾备服务器获取待恢复数据库的配置信息，并利用获取的配置信息向中间件发送配置指令，以使中间件创建待恢复数据库的新实例；从灾备服务器获取待恢复数据库的业务数据表，并基于分库分表策略将获取的业务数据表写入存储设备，从而完成数据库恢复。基于上述描述可知，整个数据库的恢复过程都是通过灾备引擎设备完成，使得主中心的中间件可以专门处理其他业务对数据库的访问，因此本申请相对现有技术，主中心的中间件对其他业务的处理性能至少能够提升一倍，进而提升了用户的使用体验。同时，由于灾备引擎设备专门用于进行数据库恢复过程，不需要处理其他业务，因此可以很大程度缩短恢复耗时。

图4为本申请根据一示例性实施例示出的另一种数据库恢复方法的实施例流程图，基于上述图3所示实施例的基础上，本实施例以如何基于分库分表策略将获取的业务数据表写入存储设备为例进行示例性说明，如图4所示，该数据库恢复方法包括如下步骤：

步骤401：基于分库分表策略为各个业务数据表分配存储设备。

在一实施例中，由于主中心中存储设备的性能会受到业务访问量的影响，因此灾备引擎设备在将获取的业务数据表写入主中心的存储设备之前，需要基于分库分表策略为各个业务数据表分配存储设备，该分库分表策略能够综合各存储设备当前的处理能力，为其分配要写入的业务数据表。

步骤402：通过并行写入方式，将各个业务数据表写入对应的存储设备中。

在一实施例中，由于每个数据库通常包含多个业务数据表，而每个数据库之间无任何关联，因此灾备引擎设备可以通过并行写入方式，将待恢复数据库的各个业务数据表写入对应的存储设备中，以进一步缩短恢复耗时。

基于上述图1所示的示例性场景，10个待恢复数据库，对应1M左右的元数据文件，平均每个数据库的业务数据文件大小为50G，解开之后大小为100G。由于元数据的恢复和业务数据的恢复可以同步执行恢复，且元数据的文件本身并不大，因此元数据的恢复耗时可以忽略不计，只考虑业务数据的恢复耗时，经过测试，对于10个待恢复数据库，每个数据库对应有50G大小的业务数据文件，通过并行方式恢复至存储设备，需要的耗时为35-50分钟之间(不到1小时时间)。

步骤403：将各个业务数据表对应的存储设备的地址发送至中间件，以使中间件利用各个业务数据表对应的存储设备的地址更新本地的路由信息。

在一实施例中，中间件本地的路由信息指的是中间件在创建待恢复数据库的新实例之后，为待恢复数据库包含的业务数据表自动生成的路由信息。由于灾备引擎设备为各业务数据表分配的存储设备的地址，与中间件本地为业务数据表生成的路由信息很有可能不一致，而业务数据表的实际写入过程是根据灾备引擎设备分配的存储设备执行的，因此需要利用灾备引擎设备分配的存储设备的地址，去更新中间件中业务数据表的路由信息，以确保数据库恢复完成后，业务能够正常访问数据库。

需要说明的是，由于上述步骤402是灾备引擎设备与主中心的存储设备的交互，步骤403是灾备引擎设备与中间件的交互，两个步骤互不影响，既可以同步执行，也可以顺序执行，且对步骤402和步骤403的前后执行顺序不进行限定。

需要进一步说明的是，灾备引擎设备在完成数据库恢复之后，可以将恢复完成的通知消息发送至灾备管理设备，灾备管理设备可以向中间件发送数据库版本号升级指令，以使中间件更新数据库的版本号。

本实施例中，灾备引擎设备在为各个业务数据表分配存储设备后，通过并行写入方式，将业务数据表写入对应的存储设备中的，由于通常业务数据表的数据量很大，因此通过并行写入，可以进一步缩短恢复耗时。

与前述数据库恢复方法的实施例相对应，本申请还提供了数据库恢复装置的实施例。

本申请数据库恢复装置的实施例可以应用在主中心的灾备引擎设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请根据一实施例性实施例示出的一种灾备引擎设备的硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。

图6为本申请根据一示例性实施例示出的一种数据库恢复装置的实施例结构图，该数据库恢复装置可以应用于主中心的灾备引擎设备，如图6所示，所述数据库恢复装置包括：

第一获取模块610，用于基于所述灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从所述灾备服务器获取待恢复数据库的配置信息；

第一发送模块620，用于利用获取的配置信息向所述中间件发送配置指令，以使所述中间件创建待恢复数据库的新实例；

第二获取模块630，用于从所述灾备服务器获取待恢复数据库的业务数据表；

写入模块640，用于基于分库分表策略将获取的业务数据表写入所述存储设备。

在一可选的实现方式中，所述业务数据表包含多个数据表；所述写入模块640，具体用于基于分库分表策略为各个业务数据表分配存储设备；通过并行写入方式，将各个业务数据表写入对应的存储设备中。

在一可选的实现方式中，所述装置还包括(图6中未示出)：

第二发送模块，用于在所述写入模块640基于分库分表策略为各个业务数据表分配存储设备之后，将各个业务数据表对应的存储设备的地址发送至所述中间件，以使所述中间件利用各个业务数据表对应的存储设备的地址更新本地的路由信息，其中，所述本地的路由信息指的是所述中间件在创建待恢复数据库的新实例之后，为所述待恢复数据库包含的业务数据表自动生成的路由信息。

在一可选的实现方式中，所述第一发送模块620与所述第二获取模块630及写入模块同步执行。

在一可选的实现方式中，所述第一获取模块610，具体用于从所述灾备服务器读取待恢复数据库的元数据文件；解析并提取所述元数据文件中待恢复数据库的配置信息。

在一可选的实现方式中，所述装置还包括(图6中未示出)：

中间数据表恢复模块，用于在所述第一发送模块620利用获取的配置信息向所述中间件发送配置指令之后，从所述元数据文件中提取中间数据表，所述中间数据表指的是在使用所述待恢复数据库过程中产生的数据表；将提取的中间数据表发送至所述中间件创建的待恢复数据库的新实例中。

在一可选的实现方式中，所述装置还包括(图6中未示出)：

更新模块，用于在利用获取的配置信息向所述中间件发送配置指令之后，接收所述中间件返回的待恢复数据库的新实例的标识；在从所述元数据文件中提取中间数据表之后，利用新实例的标识更新所述中间数据表中记录的老实例的标识。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (15)

1.一种数据库恢复方法，其特征在于，所述方法应用于数据库恢复系统中主中心的灾备引擎设备，所述数据库恢复系统还包含灾备管理设备、灾备中心的灾备服务器，以及主中心的中间件、存储设备，所述方法包括：

步骤一、基于所述灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从所述灾备服务器获取待恢复数据库的配置信息；

步骤二、利用获取的配置信息向所述中间件发送配置指令，以使所述中间件创建待恢复数据库的新实例；

步骤三、从所述灾备服务器获取待恢复数据库的业务数据表，并基于分库分表策略将获取的业务数据表写入所述存储设备。

2.根据权利要求1所述的方法，其特征在于，所述业务数据表包含多个数据表，基于分库分表策略将获取的业务数据表写入所述存储设备，包括：

基于分库分表策略为各个业务数据表分配存储设备；

通过并行写入方式，将各个业务数据表写入对应的存储设备中。

3.根据权利要求2所述的方法，其特征在于，基于分库分表策略为各个业务数据表分配存储设备之后，所述方法还包括：

将各个业务数据表对应的存储设备的地址发送至所述中间件，以使所述中间件利用各个业务数据表对应的存储设备的地址更新本地的路由信息，其中，所述本地的路由信息指的是所述中间件在创建待恢复数据库的新实例之后，为所述待恢复数据库包含的业务数据表自动生成的路由信息。

4.根据权利要求1所述的方法，其特征在于，所述步骤二与所述步骤三同步执行。

5.根据权利要求1所述的方法，其特征在于，从所述灾备服务器获取待恢复数据库的配置信息，包括：

从所述灾备服务器读取待恢复数据库的元数据文件；

解析并提取所述元数据文件中待恢复数据库的配置信息。

6.根据权利要求5所述的方法，其特征在于，利用获取的配置信息向所述中间件发送配置指令之后，所述方法还包括：

从所述元数据文件中提取中间数据表，所述中间数据表指的是在使用所述待恢复数据库过程中产生的数据表；

将提取的中间数据表发送至所述中间件创建的待恢复数据库的新实例中。

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

在利用获取的配置信息向所述中间件发送配置指令之后，接收所述中间件返回的待恢复数据库的新实例的标识；

在从所述元数据文件中提取中间数据表之后，利用新实例的标识更新所述中间数据表中记录的老实例的标识。

8.一种数据库恢复系统，其特征在于，所述系统包括：

灾备管理设备，用于向主中心的灾备引擎设备发送携带待恢复数据库的老实例的标识的恢复指令；

灾备中心的灾备服务器，用于存储待恢复数据库的配置信息和业务数据表；

主中心的灾备引擎设备，用于基于携带待恢复数据库的老实例的标识的恢复指令，从所述灾备服务器获取待恢复数据库的配置信息，并利用获取的配置信息向中间件发送配置指令；从所述灾备服务器获取待恢复数据库的业务数据表，并基于分库分表策略将获取的业务数据表写入主中心的存储设备；

主中心的中间件，用于基于所述配置指令，创建待恢复数据库的新实例；

主中心的存储设备，用于存储所述灾备引擎设备写入的业务数据表。

9.一种数据库恢复装置，其特征在于，所述装置应用于数据库恢复系统中主中心的灾备引擎设备，所述数据库恢复系统还包含灾备管理设备、灾备中心的灾备服务器，以及主中心的存储设备，所述装置包括：

第一获取模块，用于基于所述灾备管理设备发送的携带待恢复数据库的老实例的标识的恢复指令，从所述灾备服务器获取待恢复数据库的配置信息；

第一发送模块，用于利用获取的配置信息向所述中间件发送配置指令，以使所述中间件创建待恢复数据库的新实例；

第二获取模块，用于从所述灾备服务器获取待恢复数据库的业务数据表；

写入模块，用于基于分库分表策略将获取的业务数据表写入所述存储设备。

10.根据权利要求9所述的装置，其特征在于，所述业务数据表包含多个数据表；

所述写入模块，具体用于基于分库分表策略为各个业务数据表分配存储设备；通过并行写入方式，将各个业务数据表写入对应的存储设备中。

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

第二发送模块，用于在所述写入模块基于分库分表策略为各个业务数据表分配存储设备之后，将各个业务数据表对应的存储设备的地址发送至所述中间件，以使所述中间件利用各个业务数据表对应的存储设备的地址更新本地的路由信息，其中，所述本地的路由信息指的是所述中间件在创建待恢复数据库的新实例之后，为所述待恢复数据库包含的业务数据表自动生成的路由信息。

12.根据权利要求9所述的装置，其特征在于，所述第一发送模块与所述第二获取模块及写入模块同步执行。

13.根据权利要求9所述的装置，其特征在于，所述第一获取模块，具体用于从所述灾备服务器读取待恢复数据库的元数据文件；解析并提取所述元数据文件中待恢复数据库的配置信息。

14.根据权利要求13所述的装置，其特征在于，所述装置还包括：

中间数据表恢复模块，用于在所述第一发送模块利用获取的配置信息向所述中间件发送配置指令之后，从所述元数据文件中提取中间数据表，所述中间数据表指的是在使用所述待恢复数据库过程中产生的数据表；将提取的中间数据表发送至所述中间件创建的待恢复数据库的新实例中。

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

更新模块，用于在利用获取的配置信息向所述中间件发送配置指令之后，接收所述中间件返回的待恢复数据库的新实例的标识；在从所述元数据文件中提取中间数据表之后，利用新实例的标识更新所述中间数据表中记录的老实例的标识。