CN108762982A - A database recovery method, device and system - Google Patents

Abstract

The application provides a database recovery method, a device and a system, wherein the method is applied to disaster recovery engine equipment of a main center in a database recovery system, and comprises the following steps: acquiring configuration information of a database to be recovered from a disaster recovery server based on a recovery instruction which is sent by disaster recovery management equipment and carries an identifier of an old instance of the database to be recovered; sending a configuration instruction to the middleware by using the acquired configuration information so that the middleware creates a new instance of the database to be recovered; and acquiring a service data table of the database to be recovered from the disaster recovery server, and writing the acquired service data table into the storage device based on a database-dividing and table-dividing strategy. The whole database recovery process is completed through the disaster recovery engine equipment, so that the middleware can specially process the service, and compared with the prior art, the service processing performance of the middleware can be doubled. And the disaster recovery engine device is specially used for database recovery, so that the recovery time can be shortened.

Description

A database recovery method, device and system

technical field

The present application relates to the technical field of databases, in particular to a method, device and system for restoring a database.

Background technique

With the rapid growth of data volume, the database architecture began to develop from centralized to distributed. Currently used distributed database systems usually include distributed database middleware, distributed databases, and the like. In order to ensure the security of the distributed database system, database disaster recovery is usually required for subsequent data recovery.

In the related technology, when restoring the database of a certain business, the disaster recovery management device first obtains the configuration information of the database to be recovered from the disaster recovery server in the disaster recovery center, and sends the configuration information of the database to be recovered to the server in the main center. Middleware, so that the middleware creates an instance of the database to be restored according to the configuration information, and automatically generates the routing information of the database to be restored based on the sub-database and table strategy; then the disaster recovery management device obtains the data to be recovered from the disaster recovery server in the disaster recovery center The business data table of the database is sent to the middleware of the main center, and the middleware writes the business data table into the storage device of the main center according to the routing information of the database to be restored, thereby completing the recovery of the database.

However, since the middleware of the main center not only needs to handle the data writing process of the database to be restored, but also needs to handle the business’s access to other databases, the processing pressure of the middleware of the main center is relatively high, which in turn affects the business’s access to the database performance and degrade user experience.

Contents of the invention

In view of this, the present application provides a database recovery method, device and system to solve the problem that existing recovery methods will affect the performance of business access to the database and reduce user experience.

According to the first aspect of the embodiment of the present application, a database recovery method is provided, the method is applied to the disaster recovery engine equipment of the main center in the database recovery system, and the database recovery system also includes the disaster recovery management equipment, the disaster recovery center The disaster recovery server, and the storage device of the main center, the method includes:

Step 1. Obtain configuration information of the database to be restored from the disaster recovery server based on the restoration command sent by the disaster recovery management device and carrying the identifier of the old instance of the database to be restored;

Step 2, using the obtained configuration information to send a configuration instruction to the middleware, so that the middleware creates a new instance of the database to be restored;

Step 3: Obtain the business data table of the database to be restored from the disaster recovery server, and write the obtained business data table into the storage device based on the strategy of sub-database and sub-table.

According to a second aspect of the embodiments of the present application, a database recovery system is provided, the system comprising:

The disaster recovery management device is used to send a recovery command carrying the identification of the old instance of the database to be recovered to the disaster recovery engine device in the main center;

The disaster recovery server in the disaster recovery center is used to store the configuration information and business data tables of the database to be recovered;

The disaster recovery engine device of the main center is used to obtain the configuration information of the database to be recovered from the disaster recovery server based on the recovery command carrying the identification of the old instance of the database to be recovered, and send the configuration command to the middleware by using the obtained configuration information Obtain the business data table of the database to be recovered from the disaster recovery server, and write the obtained business data table into the storage device of the main center based on the sub-database sub-table strategy;

The middleware of the main center is used to create a new instance of the database to be restored based on the configuration instruction;

The storage device of the main center is used to store the business data table written by the disaster recovery engine device.

According to the third aspect of the embodiment of the present application, a database recovery device is provided, the device is applied to the disaster recovery engine equipment of the main center in the database recovery system, and the database recovery system also includes the disaster recovery management equipment, the disaster recovery center The disaster recovery server, and the storage device of the main center, the device includes:

The first obtaining module is configured to obtain configuration information of the database to be restored from the disaster recovery server based on the restoration instruction sent by the disaster recovery management device and carrying the identifier of the old instance of the database to be restored;

A first sending module, configured to use the obtained configuration information to send a configuration instruction to the middleware, so that the middleware creates a new instance of the database to be restored;

The second obtaining module is used to obtain the business data table of the database to be restored from the disaster recovery server;

A writing module, configured to write the acquired business data table into the storage device based on the policy of sub-database and sub-table.

Applying the embodiment of this application, after receiving the recovery command sent by the disaster recovery management device, the disaster recovery engine device obtains the recovery command from the disaster recovery server based on the recovery command sent by the disaster recovery management device and carrying the identifier of the old instance of the database to be recovered. The configuration information of the database, and use the obtained configuration information to send configuration instructions to the middleware, so that the middleware creates a new instance of the database to be restored; obtain the business data table of the database to be restored from the disaster recovery server, and based on the sub-database sub-table strategy Write the obtained business data table into the storage device, so as to complete the database restoration. Based on the above description, it can be seen that the recovery process of the entire database is completed through the disaster recovery engine device, so that the middleware of the main center can specifically handle the access of other businesses to the database. The processing performance of the business can be at least doubled, thereby improving the user experience. At the same time, since the disaster recovery engine device is specially used for the database recovery process and does not need to deal with other businesses, it can greatly shorten the recovery time.

Description of drawings

FIG. 1 is a schematic structural diagram of an existing database recovery system according to an exemplary embodiment of the present application;

Fig. 2 is a schematic structural diagram of a database restoration system according to an exemplary embodiment of the present application;

FIG. 3 is a flow chart of an embodiment of a method for restoring a database according to an exemplary embodiment of the present application;

Fig. 4 is an embodiment flow chart of another database recovery method according to an exemplary embodiment of the present application;

FIG. 5 is a hardware structural diagram of a disaster recovery engine device according to an exemplary embodiment of the present application;

Fig. 6 is a structural diagram of an embodiment of a database recovery device according to an exemplary embodiment of the present application.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with aspects of the present application as recited in the appended claims.

The terminology used in this application is for the purpose of describing particular embodiments only, and is not intended to limit the application. As used in this application and the appended claims, the singular forms "a", "the", and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of the present application, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

Fig. 1 is a schematic structural diagram of an existing database restoration system shown in the present application according to an exemplary embodiment. The restoration system shown in Fig. 1 includes disaster recovery management equipment, middleware of the main center and various storage devices (Fig. 1 lists 3 storage device), and the disaster recovery server in the disaster recovery center. Among them, the disaster recovery management device can interact with the main center and the disaster recovery center through the network, and is used to obtain the data (such as metadata and business data) of the database to be restored from the disaster recovery server and send it to the middleware of the main center , and the database recovery is completed by the middleware; the middleware in the main center is used to manage the database, such as configuring, monitoring, data migration, synchronous backup of the database, and handling the access of various businesses to the database (realized by creating instances for each database ), records the metadata of the database (such as the configuration information of the database and the routing information of the sub-database and sub-table).

For database recovery, it can be understood as the reverse process of data disaster recovery, that is, it is necessary to ensure that business data and metadata are restored according to requirements (such as the point in time to restore, which databases need to be restored, etc.), and the consistency of restored data must be ensured.

The following describes in detail how the disaster recovery management device in the prior art interacts with the middleware of the main center to complete the recovery of the database in combination with Figure 1:

When the disaster recovery management device receives the database recovery command, based on the time point carried in the command and the instance identifier of the database to be recovered, it reads and unlocks the metadata file of the database to be recovered corresponding to the time point from the disaster recovery server , to extract the configuration information of the database to be restored, and write the configuration information of the database to be restored to the middleware of the main center, so that the middleware can create a new instance of the database to be restored according to the configuration information, and automatically generate the routing information of the database to be restored ; Then the disaster recovery management device reads from the disaster recovery server and untangles the business data file of the database to be recovered to extract the business data table, and writes the business data table into the middleware of the main center, and the middleware generates Routing information, write the business data table into the storage device of the main center.

Because during the database recovery process, metadata writing and business data writing need to be executed sequentially, and the business data of each database to be recovered also needs to be written sequentially according to the routing information.

In an exemplary scenario, suppose there are 10 database instances that need to be restored, and the corresponding metadata file size is about 1M. On average, the business data file size corresponding to each database instance is 50G, and the size is 100G after unlocking. In the test, it takes 12-15 seconds to read, unpack, and write metadata files, and 3.5 hours to read, unpack, and write business data files for each database. Therefore, for 10 databases It takes at least 35 hours (more than a day) for the instance to recover to complete. It can be seen that the entire recovery process is quite time-consuming.

In addition, the middleware of the main center not only needs to handle the data writing process of the database to be restored, but also needs to handle other business access to the database, so the processing pressure of the middleware of the main center is relatively high, especially in the case of a large amount of data to be restored. In this case, it will seriously affect the performance of business access to the database and reduce the user experience.

Based on this, FIG. 2 is a schematic structural diagram of a database recovery system according to an exemplary embodiment of the present application. On the basis of the above-mentioned FIG. 1, the present application adds a disaster recovery engine device in the main center, and the disaster recovery engine device It can interact with the disaster recovery management equipment and the disaster recovery server in the disaster recovery center through the network. In the process of database recovery, the disaster recovery engine device obtains the metadata and business data of the database to be recovered from the disaster recovery server based on the trigger of the recovery command sent by the disaster recovery management device, and restores the metadata to the middleware of the main center , business data is restored to the storage device in the main center.

It can be seen that in the process of completing the database recovery of the entire recovery system, the disaster recovery engine equipment completes data acquisition and recovery, and the middleware in the main center is specially used to handle other business access to the database. The separation of data streams ensures business stability and reliability. In addition, since the metadata needs to be restored to the middleware and the business data needs to be restored to the storage device, the disaster recovery engine device can restore the metadata and business data simultaneously without affecting each other, thus shortening the recovery time.

Introduce the technical scheme of the present application in detail below with specific embodiment:

Fig. 3 is a flow chart of an embodiment of a database recovery method shown in the present application according to an exemplary embodiment, combined with the structural diagram of the database recovery system shown in Fig. 2 above, the database recovery method can be applied to the disaster recovery engine of the main center device (such as a PC). The database involved in this embodiment of the present application may be a distributed database. As shown in Figure 3, the database recovery method includes the following steps:

Step 301: Obtain configuration information of the database to be restored from the disaster recovery server based on the restoration command sent by the disaster recovery management device and carrying the identifier of the old instance of the database to be restored.

In one embodiment, when a certain business is running abnormally, the database involved in the business can be restored again, or after a user's database is damaged by an attack, the user's database needs to be restored again, or a fire occurs in the computer room , causing the resource pools of all databases in the main center to be burned, and all databases in the center need to be restored. Based on this, by inputting the identifier of the old instance of the database to be restored to the disaster recovery management device, the disaster recovery management device is triggered to generate a recovery command, and the generated recovery command is sent to the disaster recovery engine device, so that the disaster recovery engine device can receive the disaster recovery command. recovery command sent by the backup management device.

Wherein, the database to be restored consists of one instance, and the old instance refers to the instance corresponding to the database backed up to the disaster recovery server. Those skilled in the art can understand that the identifiers of examples can be numbers or letters, or a combination of numbers and letters, which is not limited in this application.

In one embodiment, for the process of obtaining the configuration information of the database to be restored from the disaster recovery server, since the disaster recovery server saves the storage space occupied by the backup data, the metadata storage of the database is usually compressed into a file. Therefore, the disaster recovery engine device can first read the metadata file of the database to be restored from the disaster recovery server, and then parse and extract the configuration information of the database to be restored in the metadata file.

Among them, the configuration information of the database to be restored refers to the metadata required when creating the database instance, for example, the instance specification of the database, the tables contained in the database, the creation time of the database, and the users with access rights.

Step 302: Using the obtained configuration information, send a configuration instruction to the middleware, so that the middleware creates a new instance of the database to be restored.

In one embodiment, since the user accesses the database data through the instance of the database in the middleware, the disaster recovery engine device needs to send a configuration command to the middleware when restoring the database, and the middleware uses the configuration The configuration information carried in the command creates a new instance for the database to be restored, so as to complete the restoration of metadata. Wherein, the identifier of the new instance of the database to be restored created by the middleware may be the same as or different from the identifier of the old instance described in step 301 above.

It should be noted that after the disaster recovery engine device uses the obtained configuration information to send configuration instructions to the middleware, it can also extract the intermediate data table from the metadata file, and the intermediate data table refers to the process of using the database to be restored. The generated data table, and the extracted intermediate data table is sent to the new instance of the database to be restored created by the middleware, so as to ensure the consistency of the restored data.

It should be further explained that after the disaster recovery engine device uses the obtained configuration information to send configuration instructions to the middleware, it can also receive the identification of the new instance of the database to be restored returned by the middleware, and extract the intermediate data from the metadata file After the table is created, the identifier of the new instance is used to update the identifier of the old instance recorded in the intermediate data table, so that after the intermediate data table is restored to the new instance created by the middleware, the normal operation of the business can be guaranteed.

Step 303: Obtain the business data table of the database to be restored from the disaster recovery server, and write the obtained business data table into the storage device based on the sub-database and table sub-strategy.

In one embodiment, since each database contains multiple business data tables, and the storage space occupied by each business data table is relatively large, the disaster recovery server usually compresses the business data tables contained in the database when backing up the database. It is stored as a file, so the disaster recovery engine device can first read the business data file of the database to be restored from the disaster recovery server, and then parse the business data file to extract the business data table. Wherein, the service data is recorded in the service data table.

In an embodiment, the strategy for sub-database and table-splitting may be a hash strategy or a weight strategy, which is not limited in this application. Compared with the middleware, the disaster recovery engine device does not need to deal with other businesses, and can specifically handle the writing process of business data, so the recovery and writing time is short. For the detailed description of writing the acquired business data table into the storage device based on the sub-database sub-table strategy, refer to the related description of the embodiment shown in FIG. 4 below, which will not be described in detail here.

It should be noted that the above step 302 and step 303 can be executed synchronously, so as to shorten the time-consuming of restoring the database.

For the process from step 301 to step 303 above, based on the exemplary scenario shown in Figure 1 above, 10 database instances need to be restored, corresponding to metadata files of about 1M, and the average size of the business data files corresponding to each database instance is 50G, the size after unlocking is 100G. Since the restoration of metadata and business data can be restored simultaneously, and the metadata file itself is not large, the time-consuming of metadata restoration can be ignored. Only the time-consuming of business data restoration is considered. After testing, for 1 A database instance containing 50G business data files is finally restored to the storage device, which takes only 25 minutes (compared with the existing solution, which is shortened by at least 3 hours).

In this embodiment, after the disaster recovery engine device receives the recovery command sent by the disaster recovery management device, it obtains the database to be recovered from the disaster recovery server based on the recovery command sent by the disaster recovery management device and carrying the identifier of the old instance of the database to be recovered. configuration information, and use the obtained configuration information to send configuration instructions to the middleware, so that the middleware creates a new instance of the database to be restored; obtains the business data table of the database to be restored from the disaster recovery server, and based on the sub-database sub-table strategy The obtained business data table is written into the storage device, thereby completing the database restoration. Based on the above description, it can be seen that the recovery process of the entire database is completed through the disaster recovery engine device, so that the middleware of the main center can specifically handle the access of other businesses to the database. The processing performance of the business can be at least doubled, thereby improving the user experience. At the same time, since the disaster recovery engine device is specially used for the database recovery process and does not need to deal with other businesses, it can greatly shorten the recovery time.

Fig. 4 is an embodiment flow chart of another database restoration method shown in this application according to an exemplary embodiment. Based on the above-mentioned embodiment shown in Fig. 3, this embodiment uses how to obtain The business data table is written into the storage device as an example for illustration, as shown in Figure 4, the database recovery method includes the following steps:

Step 401: Allocate storage devices for each business data table based on the policy of sub-database and sub-table.

In one embodiment, since the performance of the storage device in the main center will be affected by the traffic of business visits, the disaster recovery engine device needs to use the sub-database and sub-table strategy before writing the acquired business data table into the storage device of the main center. Allocate storage devices for each business data table. The sub-database and table-splitting strategy can integrate the current processing capabilities of each storage device and allocate business data tables to be written.

Step 402: Write each business data table into a corresponding storage device by means of parallel writing.

In one embodiment, since each database usually contains a plurality of business data tables, and there is no relationship between each database, the disaster recovery engine device can write each business data table of the database to be restored through parallel writing. to the corresponding storage device to further shorten the recovery time.

Based on the exemplary scenario shown in Figure 1 above, 10 databases to be restored correspond to metadata files of about 1M, and the average size of business data files for each database is 50G, and the size after unlocking is 100G. Since metadata recovery and business data recovery can be performed simultaneously, and the metadata file itself is not large, the time-consuming metadata recovery can be ignored. Only the time-consuming business data recovery is considered. After testing, for 10 There are two databases to be restored, and each database corresponds to a business data file of 50G in size. It takes 35-50 minutes (less than 1 hour) to restore to the storage device in parallel.

Step 403: Send the address of the storage device corresponding to each service data table to the middleware, so that the middleware uses the address of the storage device corresponding to each service data table to update local routing information.

In an embodiment, the local routing information of the middleware refers to the routing information automatically generated by the middleware for the service data table included in the database to be restored after creating a new instance of the database to be restored. Because the address of the storage device assigned by the disaster recovery engine device to each business data table is likely to be inconsistent with the routing information locally generated by the middleware for the business data table, the actual writing process of the business data table is based on the distribution of the disaster recovery engine device. Therefore, it is necessary to use the address of the storage device assigned by the disaster recovery engine device to update the routing information of the business data table in the middleware to ensure that the business can access the database normally after the database recovery is completed.

It should be noted that since the above step 402 is the interaction between the disaster recovery engine device and the storage device of the main center, step 403 is the interaction between the disaster recovery engine device and the middleware. The two steps do not affect each other and can be executed synchronously or It is executed sequentially, and there is no limitation on the execution sequence of step 402 and step 403 .

It should be further explained that after the disaster recovery engine device completes the database recovery, it can send a recovery completion notification message to the disaster recovery management device, and the disaster recovery management device can send a database version number upgrade command to the middleware to update the middleware The version number of the database.

In this embodiment, after the disaster recovery engine device allocates a storage device for each business data table, the business data table is written into the corresponding storage device through a parallel writing method. Since the data volume of the business data table is generally large, Therefore, by writing in parallel, the recovery time can be further shortened.

Corresponding to the foregoing embodiments of the database recovery method, the present application also provides embodiments of a database recovery device.

The embodiment of the database recovery device of the present application can be applied to the disaster recovery engine equipment of the main center. The device embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the device where it is located. From the perspective of hardware, as shown in Figure 5, it is a hardware structure diagram of a disaster recovery engine device shown in an exemplary embodiment of the present application, except for the processor, memory, network interface, and In addition to the non-volatile memory, the device where the device in the embodiment is located usually may also include other hardware according to the actual function of the device, which will not be repeated here.

Fig. 6 is a structural diagram of an embodiment of a database recovery device according to an exemplary embodiment of the present application. The database recovery device can be applied to the disaster recovery engine equipment of the main center. As shown in Fig. 6, the database recovery device include:

The first acquiring module 610 is configured to acquire the configuration information of the database to be recovered from the disaster recovery server based on the recovery command sent by the disaster recovery management device and carrying the identifier of the old instance of the database to be recovered;

The first sending module 620 is configured to use the obtained configuration information to send a configuration instruction to the middleware, so that the middleware creates a new instance of the database to be restored;

The second obtaining module 630 is used to obtain the business data table of the database to be restored from the disaster recovery server;

The writing module 640 is configured to write the acquired business data table into the storage device based on the sub-database and sub-table policy.

In an optional implementation, the business data table includes a plurality of data tables; the writing module 640 is specifically configured to allocate storage devices for each business data table based on the sub-database and sub-table strategy; through parallel writing , and write each service data table into a corresponding storage device.

In an optional implementation, the device further includes (not shown in FIG. 6):

The second sending module is configured to send the address of the storage device corresponding to each business data table to the middleware after the writing module 640 allocates a storage device for each business data table based on the sub-database and sub-table strategy, so that The middleware uses the address of the storage device corresponding to each service data table to update the local routing information, wherein the local routing information means that after the middleware creates a new instance of the database to be restored, The routing information automatically generated by the business data table contained in the recovery database.

In an optional implementation manner, the first sending module 620 is executed synchronously with the second obtaining module 630 and the writing module.

In an optional implementation, the first obtaining module 610 is specifically configured to read the metadata file of the database to be restored from the disaster recovery server; parse and extract the configuration of the database to be restored in the metadata file information.

In an optional implementation, the device further includes (not shown in FIG. 6):

An intermediate data table recovery module, configured to extract an intermediate data table from the metadata file after the first sending module 620 uses the obtained configuration information to send a configuration instruction to the middleware, the intermediate data table refers to It is a data table generated during the process of using the database to be restored; the extracted intermediate data table is sent to the new instance of the database to be restored created by the middleware.

In an optional implementation, the device further includes (not shown in FIG. 6):

An update module, configured to receive the identifier of the new instance of the database to be restored returned by the middleware after using the obtained configuration information to send the configuration instruction to the middleware; after extracting the intermediate data table from the metadata file , using the identifier of the new instance to update the identifier of the old instance recorded in the intermediate data table.

For the implementation process of the functions and effects of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method for details, and will not be repeated here.

As for the device embodiment, since it basically corresponds to the method embodiment, for related parts, please refer to the part description of the method embodiment. The device embodiments described above are only illustrative, and the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in One place, or it can be distributed to multiple network elements. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application. It can be understood and implemented by those skilled in the art without creative effort.

Other embodiments of the present application will be readily apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any modification, use or adaptation of the application, these modifications, uses or adaptations follow the general principles of the application and include common knowledge or conventional technical means in the technical field not disclosed in the application . The specification and examples are to be considered exemplary only, with a true scope and spirit of the application indicated by the following claims.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The above is only a preferred embodiment of the application, and is not intended to limit the application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the application should be included in the application. within the scope of protection.

Claims (15)

1. a kind of database restoring method, which is characterized in that the method is applied to the calamity at main center in present in database recovery system Standby engine apparatus, the present in database recovery system also include calamity in management equipment, the backup & disaster recovery device of Disaster Preparation Center, and master The middleware of the heart, storage device, the method includes：

Step 1: the recovery of the mark of the honest example of the carrying database to be restored sent for management equipment based on the calamity is referred to It enables, the configuration information of database to be restored is obtained from the backup & disaster recovery device；

Step 2: using obtain configuration information to the middleware send configuration-direct so that the middleware establishment wait for it is extensive The new example in complex data library；

Step 3: obtaining the business datum table of database to be restored from the backup & disaster recovery device, and divide table strategy will based on a point library The storage device is written in the business datum table of acquisition.

2. according to the method described in claim 1, it is characterized in that, the business datum table include multiple tables of data, based on point Library divides table strategy that the storage device is written in the business datum table of acquisition, including：

Table strategy is divided to be that each business datum table distributes storage device based on a point library；

By concurrent writing, each business datum table is written in corresponding storage device.

3. according to the method described in claim 2, it is characterized in that, dividing table strategy to be distributed for each business datum table based on a point library After storage device, the method further includes：

The address of the corresponding storage device of each business datum table is sent to the middleware, so that the middleware is using respectively The local routing iinformation of the address update of the corresponding storage device of a business datum table, wherein the local routing iinformation refers to Be the middleware after the new example for creating database to be restored, the business datum for including for the database to be restored The routing iinformation that table automatically generates.

4. according to the method described in claim 1, it is characterized in that, step 2 execution synchronous with the step 3.

5. according to the method described in claim 1, it is characterized in that, obtaining matching for database to be restored from the backup & disaster recovery device Confidence ceases, including：

The meta data file of database to be restored is read from the backup & disaster recovery device；

Parse and extract the configuration information of database to be restored in the meta data file.

6. according to the method described in claim 5, it is characterized in that, the configuration information using acquisition is matched to middleware transmission After setting instruction, the method further includes：

Intermediate data table is extracted from the meta data file, the intermediate data table refers to using the data to be restored The tables of data generated during library；

The intermediate data table of extraction is sent in the new example for the database to be restored that the middleware creates.

7. according to the method described in claim 6, it is characterized in that, the method further includes：

After sending configuration-direct to the middleware using the configuration information obtained, waiting for of receiving that the middleware returns is extensive The mark of the new example in complex data library；

After extracting intermediate data table in the meta data file, the intermediate data table is updated using the mark of new example The mark of the honest example of middle record.

8. a kind of present in database recovery system, which is characterized in that the system comprises：

Calamity sends the mark for the honest example for carrying database to be restored for the calamity to main center for management equipment for engine apparatus Recovery instruction；

The backup & disaster recovery device of Disaster Preparation Center, the configuration information for storing database to be restored and business datum table；

For engine apparatus, the recovery for the mark based on the honest example for carrying database to be restored instructs the calamity at main center, from The backup & disaster recovery device obtains the configuration information of database to be restored, and is sent and configured to middleware using the configuration information obtained Instruction；The business datum table of database to be restored is obtained from the backup & disaster recovery device, and divides table strategy by acquisition based on a point library The storage device at main center is written in business datum table；

The middleware at main center creates the new example of database to be restored for being based on the configuration-direct；

The storage device at main center, the business datum table being written for engine apparatus for storing the calamity.

9. a kind of database recovery device, which is characterized in that described device is applied to the calamity at main center in present in database recovery system Standby engine apparatus, the present in database recovery system also include calamity in management equipment, the backup & disaster recovery device of Disaster Preparation Center, and master The storage device of the heart, described device include：

First acquisition module, the mark of the honest example for carrying database to be restored for being sent for management equipment based on the calamity Recovery instruction, the configuration information of database to be restored is obtained from the backup & disaster recovery device；

First sending module, for sending configuration-direct to the middleware using the configuration information obtained, so that the centre Part creates the new example of database to be restored；

Second acquisition module, the business datum table for obtaining database to be restored from the backup & disaster recovery device；

Writing module, for dividing table strategy that the storage device is written in the business datum table of acquisition based on point library.

10. device according to claim 9, which is characterized in that the business datum table includes multiple tables of data；

Said write module divides table strategy to be that each business datum table distributes storage device specifically for being based on a point library；By simultaneously Each business datum table is written in corresponding storage device row writing mode.

11. device according to claim 10, which is characterized in that described device further includes：

Second sending module, for dividing table strategy to be that the distribution storage of each business datum table is set based on a point library in said write module After standby, the address of the corresponding storage device of each business datum table is sent to the middleware, so that the middleware is sharp With the local routing iinformation of the address update of the corresponding storage device of each business datum table, wherein the local routing letter Breath refers to the middleware after the new example for creating database to be restored, the business for including for the database to be restored The routing iinformation that tables of data automatically generates.

12. device according to claim 9, which is characterized in that first sending module and second acquisition module And writing module is synchronized and is executed.

13. device according to claim 9, which is characterized in that first acquisition module is specifically used for standby from the calamity Server reads the meta data file of database to be restored；It parses and extracts matching for database to be restored in the meta data file Confidence ceases.

14. device according to claim 13, which is characterized in that described device further includes：

Intermediate data table recovery module, for being sent out to the middleware using the configuration information obtained in first sending module After sending configuration-direct, intermediate data table is extracted from the meta data file, the intermediate data table is referred to using institute State the tables of data generated in data base procedure to be restored；The intermediate data table of extraction waiting for of being sent to that the middleware creates is extensive In the new example in complex data library.

15. device according to claim 14, which is characterized in that described device further includes：

Update module, after sending configuration-direct to the middleware in the configuration information for utilizing acquisition, during reception is described Between part return database to be restored new example mark；From in the meta data file extract intermediate data table after, The mark of the honest example recorded in the intermediate data table is updated using the mark of new example.