CN116126599A

CN116126599A - Disaster recovery method, system and related equipment for data center

Info

Publication number: CN116126599A
Application number: CN202211011295.3A
Authority: CN
Inventors: 殷亚龙; 蒋宁; 吴海英; 曾琳铖曦; 左邓鹏
Original assignee: Mashang Consumer Finance Co Ltd
Current assignee: Mashang Consumer Finance Co Ltd
Priority date: 2022-08-23
Filing date: 2022-08-23
Publication date: 2023-05-16

Abstract

The application discloses a disaster recovery method, a disaster recovery system and related equipment for a data center. The method comprises the following steps: synchronizing data of a source database to a destination database through a data transmission tool of the destination data center, wherein the source database is a database deployed in the source data center, and the destination database is a database deployed in the destination data center; synchronizing a log file of the source database to a log server of the destination data center, wherein the log file records a change transaction for changing the source database; if the source data center fails, updating the destination database to a state of the source database under the condition that the source data center fails based on the log file synchronized by the log server through the data transmission tool; and switching the access flow of the source end database to the updated destination end database.

Description

Disaster recovery method, system and related equipment for data center

Technical Field

The present disclosure relates to the field of database technologies, and in particular, to a disaster recovery method and system for a data center, and related devices.

Background

The deployment of database systems in a single data center (Internet Data Center, IDC) always results in some unpredictable factors that render the entire data center unusable, for which multiple data center multi-active deployment schemes are required to extend the failover capability from the single data center to the multiple data centers to achieve data center disaster recovery.

The existing disaster recovery scheme of the data center generally synchronizes the database data of the source data center to the database of the destination data center, so that the database of the destination data center continues to provide data services. However, when data synchronization is performed between multiple active data centers, if the database of the source data center is processing a large amount of transactions, the delay time for synchronizing the database data of the source data center to the database of the destination data center will be increased, and if the delay time exceeds RTO, the source data center will fail when the delay time happens, and the data of the destination data center will not meet the disaster recovery requirement.

Disclosure of Invention

An objective of the embodiments of the present application is to provide a disaster recovery method, system and related devices for a data center, which are used for solving the problem that the data of a target data center cannot meet the disaster recovery requirement due to delay in data synchronization between multiple active data centers in the existing disaster recovery scheme for the data center.

In order to achieve the above purpose, the embodiment of the present application adopts the following technical scheme:

in a first aspect of the present invention, the embodiment of the application provides a disaster recovery method for a data center, which comprises the following steps:

synchronizing data of the source database to the destination database through a data transmission tool of the destination data center, wherein, the source end database is a database deployed in a source data center, and the destination end database is a database deployed in a destination data center;

synchronizing a log file of the source database to a log server of the destination data center, wherein the log file records a change transaction for changing the source database;

if the source data center fails, updating the destination database to a state of the source database under the condition that the source data center fails based on the log file synchronized by the log server through the data transmission tool;

and switching the access flow of the source end database to the updated destination end database.

In a second aspect of the present invention, the embodiment of the application provides a disaster recovery system of a data center, which comprises the following components: the system comprises a data transmission tool, a log server and a database server, wherein the data transmission tool, the log server and the database server are all deployed in a target data center;

The data transmission means may be a data transmission device, for synchronizing data of a source database to a destination database, wherein, the source end database is a database deployed in a source data center, and the destination end database is a database deployed in a destination data center;

the log server is used for synchronizing log files of the source database, and the log files are recorded with change transactions for changing the source database;

the data transmission tool is also used for transmitting the data to the source data center if the source data center fails, based on the log file synchronized by the log server through the data transmission tool, updating the destination database to a state of the source database under the condition that the source data center fails;

the database server is used for switching the access flow of the source end database to the updated destination end database.

In a third aspect, an embodiment of the present application provides a disaster recovery device for a data center, including:

a first synchronization unit for synchronizing data of the source database to the destination database through a data transmission tool of the destination data center, wherein, the source end database is a database deployed in a source data center, and the destination end database is a database deployed in a destination data center;

A second synchronization unit is provided for synchronizing the first synchronization unit with the second synchronization unit, a log server for synchronizing the log files of the source database to the destination data center, the log file records a change transaction for changing the source database;

an updating unit, configured to, if the source data center fails, then, by the data transfer means, based on the log file synchronized by the log server, updating the destination database to a state of the source database under the condition that the source data center fails;

handover the unit is provided with a plurality of units, and the access flow of the source end database is switched to the updated destination end database.

In a fourth aspect, embodiments of the present application provide an electronic device, including:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the method according to the first aspect.

In a fifth aspect, embodiments of the present application provide a computer-readable storage medium, which when executed by a processor of an electronic device, enables the electronic device to perform the method according to the first aspect.

The above-mentioned at least one technical scheme that this application embodiment adopted can reach following beneficial effect:

because the current database adopts a log advance strategy, namely when a change transaction of the database is received, the change transaction is generally written into a log file, and then the database is changed based on the change transaction, the change transaction recorded by the change log of the source database is more comprehensive than the change transaction already executed by the source database, and the data which cannot be synchronized to the destination database due to synchronization delay in the source database can be obtained based on the change log of the source database. Based on the data, a data transmission tool and a log server are deployed in the target data center, the data of a source database of the source data center is synchronized to a target database of the target data center through the data transmission tool, and log files of the source database are synchronously stored in the target data center through the log server; under the condition that the source data center fails, updating the destination database to a state of the source database under the condition that the source data center fails through a data transmission tool of the destination data center based on a log file synchronized by a log server of the destination data center, so that missing data of the destination database caused by data synchronization delay between the source database and the destination database can be made up, and the data of the destination database can meet disaster tolerance requirements; further, the access flow of the source end database is switched to the updated destination end database, and the destination end database replaces the source end database to continue to provide data service, so that disaster recovery and recovery time efficiency of the data center can be improved, and RTO time efficiency of the disaster recovery of the data center can be ensured.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:

FIG. 1 is a schematic diagram of an implementation environment to which a disaster recovery method of a data center is applicable according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a disaster recovery method for a data center according to an embodiment of the present application;

FIG. 3A is a schematic diagram of a log file storage according to one embodiment of the present application;

FIG. 3B is a schematic diagram of a log file storage according to another embodiment of the present application;

FIG. 4 is a schematic diagram of a log file synchronization process according to an embodiment of the present application;

FIG. 5 is a schematic flow chart of a disaster recovery method for a data center according to another embodiment of the present application;

FIG. 6 is a schematic diagram of a log server according to an embodiment of the present application;

FIG. 7 is a schematic structural diagram of a disaster recovery device for a data center according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

For the purposes, technical solutions and advantages of the present application, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

The terms first, second and the like in the description and in the claims, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application may be implemented in sequences other than those illustrated or described herein. Furthermore, in the present specification and claims, "and/or" means at least one of the connected objects, and the character "/" generally means a relationship in which the associated object is an "or" before and after.

Partial conceptual description:

RTO: recovery Time Objective, the time objective is restored. RTO is the length of time that a data center can tolerate service interruption, i.e., the period of time between when the data center is down and the application is stopped after a fault occurs, and when the data center is restored to support the application operation. RTO is a timeliness index reflecting service recovery of a data center, and the smaller RTO is, the stronger service recovery capability of the data center is indicated.

RPO: recovery Point Objective, restoring the point target. RPO is the maximum amount of data loss that a data center can tolerate. RPO is an indicator that reflects the recovery of data integrity by a data center. The time corresponding to the last data backup after the database of the data center loses the data is the RPO.

MySQL: a popular, open-source relational database management system.

DTS tool: data Transmission, data transmission means. The DTS tool is mainly used for synchronization and migration of databases. OTTER is an open source, mySQL synchronized DTS tool.

GTID: global Transaction Identifier, global transaction identifier. GTID is a feature introduced by MySQL5.6, which ensures that every transaction of MySQL has a globally unique identifier that ensures global uniqueness in database instances even master-slave replication environments.

As described above, in the conventional disaster recovery scheme for a data center, the database data of the source data center is generally synchronized with the database of the destination data center, so that the database of the destination data center continues to provide data services. However, when data synchronization is performed between multiple active data centers, if the database of the source data center is processing a large amount of transactions, the delay time for synchronizing the database data of the source data center to the database of the destination data center will be increased, and if the delay time exceeds RTO, the source data center will fail when the delay time happens, and the data of the destination data center will not meet the disaster recovery requirement.

Because the prior databases all adopt a strategy of log advance, namely when a change transaction of the database is received, the change transaction is generally written into a log file, and then the database is changed based on the change transaction, so that the change transaction recorded by the change log of the source database is more comprehensive than the change transaction already executed by the source database, the data which cannot be synchronized to the destination database due to synchronization delay in the source database can be obtained based on the change log of the source database, and based on the data, in order to solve the problem that the data of the destination data center cannot meet the disaster tolerance requirement due to the delay of the data synchronization among multiple active data centers in the prior disaster tolerance scheme of the data center, the embodiment of the application aims to provide a disaster tolerance scheme of the data center. Under the condition that the source data center fails, updating the destination database to a state of the source database under the condition that the source data center fails through a data transmission tool of the destination data center based on a log file synchronized by a log server of the destination data center, so that missing data of the destination database caused by data synchronization delay between the source database and the destination database can be made up, and the data of the destination database can meet disaster tolerance requirements; further, the access flow of the source end database is switched to the updated destination end database, and the destination end database replaces the source end database to continue to provide data service, so that disaster recovery and recovery time efficiency of the data center can be improved, and RTO time efficiency of the disaster recovery of the data center can be ensured.

The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.

For ease of understanding, an implementation environment to which a disaster recovery method for a data center according to an embodiment of the present application is applicable will be described with reference to fig. 1. The implementation environment applicable to the disaster recovery method of the data center of the embodiment of the application may include a data transmission tool, a log server and a plurality of data centers, where each data center is operated with a plurality of databases, and the data transmission tool and the log server are deployed in the destination data centers of the plurality of data centers. It should be noted that, the number of data transmission tools and the number of log servers may be determined according to the number of destination data centers.

Illustratively, as shown in fig. 1, the above-mentioned plurality of data centers includes a data center a in which a database a and a database B 'are operated and a data center B in which a database B and a database a' are operated. In order to improve disaster recovery capability of the data center, the data center A and the data center B can be in a primary-backup relationship, specifically, the data center A can be used as a source data center, the data center B is used as a target data center, and the database A of the data center A is synchronized into the database A' of the data center B; meanwhile, the data center B can also be used as a source data center, the data center A is used as a target data center, and the database B of the data center B is synchronized into the database B' of the data center A. In this way, when the data center a fails, the access flow of the database a of the data center a can be switched to the database a 'of the data center B, and the database a' takes over the database a to continue providing data services; likewise, in the event of a failure of data center B, the access traffic of database B of data center B may be switched to database B 'of data center a, with database B' taking over from database B to continue providing data services.

In this case, the data transmission tool a and the log server a may be deployed at the data center a, and the data transmission tool B and the log server B may be deployed at the data center B. When the data center A works normally, the data transmission tool A can synchronize the data of the database A to the database A', and the log server A can synchronize the log files of the database A; under the condition that the data center A fails, the data transmission tool A can acquire the log file of the database A from the log server A, update the database A ' to the state of the database A under the condition that the data center A fails based on the log file of the database A, switch the access flow of the database A to the database A ', and take over the database A by the database A ' to continue to provide data service.

Similarly, when the data center B works normally, the data transmission tool B can synchronize the data of the database B to the database B', and the log server B can synchronize the B log files of the database; under the condition that the data center B fails, the data transmission tool B can acquire the log file of the database B from the log server B, update the database B ' to the state of the database B under the condition that the data center B fails based on the log file of the database B, switch the access flow of the database B to the database B ', and take over the database B by the database B ' to continue to provide data service.

In practical applications, the data transmission tool in the above implementation environment may be any tool having a data transmission function, such as oter, rsync, etc., and may be specifically selected according to actual needs, which is not limited in the embodiments of the present application. The log server in the implementation environment may be a server deployed in the destination data center for log synchronization, where the server does not provide online service. The data disaster recovery method provided by the embodiment of the application describes the interaction process among the database, the data transmission server and the log server of the data center in detail, achieves disaster recovery of the multi-activity data center, improves disaster recovery and aging of the data center, and ensures RTO aging of the disaster recovery of the data center.

Based on the above implementation environment, the disaster recovery method of the data center provided in the embodiment of the present application is described below.

Referring to fig. 2, a flow chart of a disaster recovery method for a data center according to an embodiment of the present application is provided, and the method can be applied to a database server to which a destination database belongs. As shown in fig. 2, the method may include the steps of:

s202, synchronizing the data of the source database to the destination database through a data transmission tool of the destination data center.

The source database is a database deployed in the source data center, and the destination database is a database deployed in the destination data center. Specifically, the destination database is a database disposed in the destination data center and corresponding to the source database. For example, as shown in fig. 1, if the source database is database a, then the destination database is database a'; if the source database is database B, then the destination database is database B'.

Specifically, a synchronization time interval may be configured in advance for a data transmission tool of the destination data center, and the data transmission tool may be triggered to periodically acquire data of the source database and send the data to the destination database according to the preconfigured synchronization time interval. The synchronization time interval may be set according to actual needs, which is not limited in the embodiment of the present application.

By synchronizing the data of the source database to the destination database, the destination database can take over the source database to continue providing data service when the source database fails to provide data service due to the failure of the source data center.

S204, synchronizing the log file of the source database to a log server of the destination data center.

The log file records a change transaction for changing the source database. Specifically, the change transaction in the embodiment of the present application may include, for example, but not limited to, an add data add transaction, a delete data transaction, and a modify data transaction, where the add data transaction is used to add data to the source database, the delete data transaction is used to delete data from the source database, and the modify data transaction is used to modify data in the source database.

By synchronizing the log files of the source database to the log server, the log files of the source database can be prevented from being lost due to the failure of the source data center, and the log files of the source database can be ensured to be acquired by related equipment of the target data center.

Specifically, the log server of the target data center may use the com_binlog_dump or com_binlog_dump_gtid command to connect to the source database, acquire the log file pushed by the source database in real time, and store the log file in the log server locally, where the log file of the source database is generated by the source database based on the currently executed change transaction and is pushed to the log server.

In the embodiment of the application, the log server is provided with a local disk and a memory. In an alternative implementation manner, S204 may be specifically implemented as: and receiving the log file pushed by the source database through the log server, and synchronizing the log file pushed by the source database to a local disk of the log server. Correspondingly, under the condition that the source data center fails, the log server can acquire the log file of the source database from the local disk and send the log file to the data transmission tool of the destination data center for the data transmission tool to use.

In another alternative implementation, considering that the time consumed for reading the data from the disk is greater than the time consumed for reading the data from the memory, in order to improve the reading efficiency of the log file and further improve the RTO and RPO accommodated in the data center, S204 may be specifically implemented as follows: and receiving the log file pushed by the source database through the log server, and synchronizing the log file pushed by the source database to the memory of the log server. Correspondingly, under the condition that the source data center fails, the log server can acquire the log file of the source database from the memory and send the log file to the data transmission tool of the destination data center so as to be used by the data transmission tool.

For example, as shown in fig. 3A, each time the log server receives a log file pushed by the source database, the log file is cached to the memory, and then the log files in the memory are sequentially written to the local disk according to the caching order of the log files in the memory. Thus, only the log file currently received by the log server, such as the log file with GTID 6 (hereinafter referred to as log file 6) shown in fig. 3A, is retained in the memory of the log server, and the log file of the source database received by the log server, such as the log file with GTID 1 (hereinafter referred to as log file 1) to the log file with GTID 5 (hereinafter referred to as log file 5), is stored in the local disk of the log server.

Optionally, considering that the local disk has the characteristic of data persistence, too many log files cached in the memory affect the data reading speed of the memory, thereby affecting the RTO and RPO of the data center disaster tolerance, in order to avoid the loss of the log files of the source database and ensure the data reading speed of the memory, after synchronizing the log files pushed by the source database to the content of the log server through the log server, in S204, the log files in the memory are synchronized to the disk of the server, and based on the request time information of the change transaction recorded by the log files in the memory, the cache validity period of the log files in the memory is determined, if the current retention time of the log files in the memory exceeds the cache validity period of the log files in the memory, the log files in the memory are deleted from the memory, wherein the current retention time of the log files refers to the time interval between the current time point and the time point when the log files are synchronized to the memory.

Specifically, the log file of the source database records the request time information of the change transaction and the change transaction which are requested to be executed on the source database, and the request time information of the change transaction recorded by the log file can be obtained by analyzing the log file of the source database; further, for each log file in the memory of the log server, determining the cache validity period of the log file based on the request time information of the change transaction recorded by the log file and a preset corresponding relation between the request time information and the cache validity period.

The preset correspondence relationship may be set according to actual needs, which is not limited in the embodiment of the present application. For example, in consideration of service peak time, the data synchronization delay time between the source database and the destination database is longer, so that log files meeting recovery timeliness can be stored in the memory for a longer time, so that the data transmission tool can directly obtain the log files from the memory, thereby providing the update speed of the destination database, and if the request time belongs to the service peak time, the buffer validity period corresponding to the request time can be set to a larger value; if the request time belongs to the non-service peak period, the buffer validity period corresponding to the request time can be set to a smaller value.

It should be noted that the service peak period and the non-service peak period may be fixed periods set in advance, or the service peak period and the non-service peak period may be dynamically determined based on a history access record of the source database before the current time point. For example, the historical access traffic of the source database before the current time period is concentrated at 20:00-22:00 a day, then 20:00-22:00 a day may be determined as the service peak period, and other time periods than 20:00-22:00 a day may be determined as the non-service peak period.

For example, as shown in fig. 3B, each time the log server receives a log file pushed by the source database, the log file is first cached to the memory, then the log file in the memory is synchronized to the local disk, at this time, log files 1 to 6 are cached in the memory, and log files 1 to 5 are stored in the local disk; because the current preservation time of the log file 1 exceeds the corresponding cache validity period, the log server deletes the log file 1 from the memory, and at this time, the log files cached in the memory comprise the log files 2 to 6.

Optionally, in order to achieve strong synchronization of log files between the source database and the log server, so as to ensure that the destination database can be accurately updated to a state of the source database in the event of a failure of the source data center, so as to ensure that data of the destination database can meet disaster recovery requirements, after synchronizing the log files pushed by the source database to a memory of the log server, the data center disaster recovery method provided by the embodiment of the present application may further include: and returning a confirmation message to the source database, wherein the confirmation message is used for the source database to execute the commit operation on the pushed change transaction of the log file record.

Illustratively, as shown in FIG. 4, after receiving a change request from a client, the source database overwrites and caches the log file based on the change transaction requested by the client; then, the source database pushes the log file to the log server of the destination data center, and the log server backs up the log file. After synchronizing the log file pushed by the source database to the memory, the log server returns an acknowledgement message (such as an ACK message) to the source server; and after receiving the confirmation message, the source database submits the change transaction recorded by the log file to an engine layer, namely refreshing the log file to a local disk of the source database, and after the log file is successfully dropped, returning a successful submitting message to the client, so that the source database can respond to the next change request from the client.

It can be understood that, after the log server synchronizes the log file pushed by the source database to the memory, the log server does not need to wait for the log file to be saved to a local disk of the log server, that is, the log server sends a confirmation message to the source database, and the source database submits the confirmation message after receiving the confirmation message from the log server, so that strong consistency between the log file of the source database and the log file stored by the log server can be ensured, and the destination database can be ensured to be accurately updated to the state of the source database under the condition that the source data center fails, thereby ensuring that the data of the destination database can meet disaster tolerance requirements.

The embodiment of the application herein shows some specific implementations of S204 described above. Of course, it should be understood that S204 may be implemented in other manners, which are not limited in this embodiment of the present application.

S206, if the source data center fails, updating the destination database to the state of the source database under the condition that the source data center fails based on the log file synchronized by the log server through the data transmission tool.

Specifically, the log file of the source database can be obtained from the log server through the data transmission tool, and the destination database is updated to the state of the source database under the condition that the source data center fails based on the log file of the source database.

Because there may be a delay in data synchronization between the source database and the destination database, especially when the source database is processing a large number of transactions, if the source data center happens to fail at this time, the destination database lacks a certain amount of data compared with the source database, so that the disaster tolerance requirement cannot be met, and the change transaction recorded in the change log of the source database is more comprehensive than the change transaction already executed by the source database. Based on the method, the log file of the source database is obtained from the log server through the data transmission tool, the data which cannot be synchronized to the destination database due to the synchronization delay in the source database can be obtained based on the change log of the source database, and then the destination database is updated to the state of the source database under the condition that the source data center fails, so that the missing data of the destination database caused by the data synchronization delay between the source database and the destination database is made up, and the data of the destination database can be ensured to meet disaster tolerance requirements.

In order to accurately update the destination database to the state of the source database in the case of the source data center failure, in an alternative implementation manner, S206 may be specifically implemented as: determining missing data of a destination database based on the log file synchronized by the log server and the current data of the destination data, and synchronizing the missing data to the destination database, wherein the missing data is data which is not synchronized to the destination database in the source database under the condition that a source data center fails.

For example, the log file of the source database records a change transaction for requesting execution of the source database and request time information of the change transaction, and the change transaction describes a change operation performed on the source database, such as adding which data to the source database, deleting which data from the source database, and what modification is performed on which data of the source database, so that the data of the source database in the case of the source data center failure can be determined based on the time information of the source data center failure and the request time information of the change transaction recorded by the log file synchronized by the log server, and further the missing data of the destination database can be determined based on the data of the source data center in the case of the source data center failure and the current data of the destination data; further, the missing data is added in the destination database, so that the destination database can be updated to the state of the source database under the condition that the source data center fails.

The embodiment of the present application herein shows a specific implementation of S206 described above. Of course, it should be understood that S206 may be implemented in other manners, which are not limited in this embodiment of the present application.

S208, switching the access flow of the source end database to the updated destination end database.

The access flow of the source end database is switched to the updated destination end database, so that the updated destination end database can take over the source end database to continue to provide data service, thereby ensuring the continuity and stability of the data service, improving the disaster recovery and aging of the data center, and ensuring the RTO aging of the disaster recovery of the data center.

Optionally, considering that the destination database cannot continuously bear higher access traffic due to the influence of various factors such as possible performance of the destination database, or the destination database may also bear other additional tasks, in order to avoid the normal operation of the tasks borne by the destination database, as shown in fig. 5, after S208, the data center disaster recovery method provided in the embodiment of the present application may further include:

s210, if the source data center is recovered to be normal, synchronizing the data of the destination database to the source database through a data transmission tool of the destination data center.

The specific implementation manner of S210 is similar to the specific implementation manner of S202, and the embodiments of the present application are not repeated here.

In practical application, the data transmission tool of the target data center can detect whether the source data center is recovered to be normal or not through various detection technologies, and the specifically adopted detection technology can be selected according to practical needs, so that the embodiment of the application is not limited. For example, the data transmission tool of the destination data center may periodically send a probe message to the source database, and if a probe response message returned from the source database is received within a predetermined time period from sending the probe message, determine that the source data center is restored to normal.

S212, under the condition that the current time point is the same as the preset time point, consistency detection is carried out on the source end database and the destination end database.

Specifically, the data of the source database and the data of the destination database can be subjected to consistency comparison, and if the difference between the data of the source database and the data of the destination database is within a preset range, the source database and the destination database can be determined to be consistent.

The embodiment of the present application herein shows a specific implementation of S212 described above. Of course, it should be understood that S212 may be implemented by other consistency detection techniques, which is not limited in the embodiments of the present application.

Alternatively, the preset time point may be a fixed time point set in advance, such as 24:00 a day, or the like.

Alternatively, the preset time point may be a time point dynamically determined based on the actual working condition of the destination data before S212. Specifically, before S212, the method for disaster recovery of a data center provided in the embodiment of the present application may further include: acquiring service related information of a destination database and replication delay time between the destination database and a source database, and determining a preset time point based on the service related information of the destination database and the replication delay time.

The service related information of the destination database refers to information for reflecting a service in which the destination data is running, and may specifically include, for example, but not limited to, at least one of the following information: the service type, resource consumption condition, access flow size and the like of the service running in the destination database.

For example, the service related information of the destination database at the current time point and the copy delay time between the destination database and the source database may be obtained according to a preset time interval, and if the service running at the current time point of the destination database does not belong to the preset core service, the access flow of the destination database at the current time point is smaller, and the copy delay time between the destination database and the source database is smaller, the current time point may be determined as the preset time point.

For another example, service related information of the destination database in each historical time period before the current time point and copy delay time between the destination database and the source database can be obtained, further based on the information, a historical time period meeting a preset switching condition is selected from each historical time period, and any time point in the selected historical time period is taken as a preset time point. The preset switching conditions may include: the service operated by the destination database is deployed in a preset core service, the access flow of the destination database is smaller than a preset flow threshold, and the replication delay time between the destination database and the source database is smaller than a preset time threshold.

It can be understood that, based on the service related information of the destination database and the copy delay time between the destination database and the source database, the preset time point for switching the database is determined, so that the time for switching the database can be ensured to adapt to the actual working condition of the destination database, and the problems that the service running in the destination database is affected due to unsuitable switching time of the database, the data of the source database is lost due to overlong copy delay time between the destination database and the source database, and further the service requirement cannot be met are avoided.

S214, if the source end database is consistent with the destination end database, switching the access flow of the destination end database to the source end database.

The implementation manner of S214 is similar to that of S208, and the description of S208 is specifically referred to above, which is not repeated here in the embodiments of the present application.

According to the disaster recovery method for the data center, the current database adopts the strategy of log advance, namely when the change transaction of the database is received, the change transaction is generally written into the log file, and then the database is changed based on the change transaction, so that the change transaction recorded by the change log of the source database is more comprehensive than the change transaction already executed by the source database, and further the data which cannot be synchronized to the destination database due to synchronization delay in the source database can be obtained based on the change log of the source database. Based on the data, a data transmission tool and a log server are deployed in the target data center, the data of a source database of the source data center is synchronized to a target database of the target data center through the data transmission tool, and log files of the source database are synchronously stored in the target data center through the log server; under the condition that the source data center fails, updating the destination database to a state of the source database under the condition that the source data center fails through a data transmission tool of the destination data center based on a log file synchronized by a log server of the destination data center, so that missing data of the destination database caused by data synchronization delay between the source database and the destination database can be made up, and the data of the destination database can meet disaster tolerance requirements; further, the access flow of the source end database is switched to the updated destination end database, and the destination end database replaces the source end database to continue to provide data service, so that disaster recovery and recovery time efficiency of the data center can be improved, and RTO time efficiency of the disaster recovery of the data center can be ensured.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

In addition, corresponding to the database disaster recovery method shown in fig. 2, the embodiment of the present application further provides a data center disaster recovery system, where the system may include: the system comprises a data transmission tool, a log server and a database server, wherein the data transmission tool, the log server and the database server are all deployed in a target data center;

the data transmission tool is used for synchronizing data of a source end database to a destination end database, wherein the source end database is a database deployed in a source data center, and the destination end database is a database deployed in the destination data center;

the data transmission tool is further configured to update, through the data transmission tool, the destination database to a state of the source database in the case of a failure of the source data center based on the log file synchronized by the log server if the source data center fails;

Optionally, as shown in fig. 6, the log server includes a log synchronization unit, a storage unit, and a service unit;

the log synchronizing unit is used for receiving the log files pushed by the source database and synchronizing the log files pushed by the source database to the storage unit;

and the service unit is used for responding to the query request from the data transmission tool, acquiring the log file of the source database from the storage unit and returning the log file to the data transmission tool.

Optionally, the storage unit includes a memory;

The log synchronizing unit is used for receiving the log files pushed by the source database and synchronizing the log files pushed by the source database to the memory;

the data transmission tool is configured to obtain a log file of the source database from a memory of the log server, and update the destination database to a state of the source database in the case of a failure of the source data center based on the log file of the source database.

Optionally, the storage unit further includes a local disk;

the log synchronization unit is further configured to synchronize the log file in the memory to a disk of the log server after synchronizing the log file pushed by the source database to the memory, determine a cache validity period of the log file in the memory based on the request time information of the change transaction recorded by the log file in the memory, and if the current save time of the log file in the memory exceeds the cache validity period of the log file in the memory, delete the log file in the memory from the memory, where the current save time of the log file refers to a time interval between a current time point and a time point when the log file is synchronized to the memory.

Optionally, the log synchronization unit is further configured to, after synchronizing the log file pushed by the source database to the memory of the log server, return a confirmation message to the source database, where the confirmation message is used for the source database to execute a commit operation on a change transaction recorded by the pushed log file.

Optionally, the data transmission tool updates the destination database to a state of the source database in the event of a failure of the source data center based on the log file synchronized by the log server, including:

determining missing data of the destination database based on the log file synchronized by the log server and the current data of the destination database, wherein the missing data is data which is not synchronized to the destination database in the source database under the condition that the source data center fails;

and synchronizing the missing data to the destination database.

Optionally, the log synchronizing unit is further configured to:

after synchronizing the log files pushed by the source database to the memory of the log server, synchronizing the log files in the memory to the disk of the log server;

Determining the cache validity period of the log file in the memory based on the request time information of the change transaction recorded by the log file in the memory;

and if the current preservation time of the log files in the memory exceeds the cache validity period of the log files in the memory, deleting the log files in the memory from the memory, wherein the current preservation time of the log files refers to the time interval between the current time point and the time point of synchronizing the log files to the memory.

Optionally, the data transmission tool is further configured to synchronize data of the destination database to the source database if the source data center is restored to be normal after the database server switches access traffic of the source database to the updated destination database;

the database server is further configured to perform consistency detection on the source database and the destination database when the current time point is the same as the preset time point, and if the source database is the same as the destination database, switch the access flow of the destination database to the source database.

Optionally, the database server is further configured to obtain service related information of the destination database and a replication delay time between the destination database and the source database before performing consistency detection on the source database and the destination database under a condition that a current time point is the same as a preset time point, and determine the preset time point based on the service related information and the replication delay time, where the service related information is information for reflecting a service that is running in the destination database.

It should be noted that, the specific implementation manner of each component in the disaster recovery system of the data center provided in the embodiment of the present application may refer to the specific implementation manner of the corresponding steps in the disaster recovery method of the data center, and since the principles are the same, the description will not be repeated here.

In addition, corresponding to the data center disaster recovery method shown in fig. 2, the embodiment of the present application further provides a data center disaster recovery device 700, where the device 700 can be applied to a database server to which the destination database belongs. As shown in fig. 7, the apparatus 700 may include:

the first synchronization unit 710 is configured to synchronize, by using a data transmission tool of a destination data center, data of a source database to a destination database, where the source database is a database deployed in the source data center, and the destination database is a database deployed in the destination data center;

A second synchronization unit 720, configured to synchronize a log file of the source database to a log server of the destination data center, where the log file records a change transaction for changing the source database;

an updating unit 730, configured to update, if the source data center fails, the destination database to a state of the source database in the event of the source data center failure based on the log file synchronized by the log server through the data transmission tool;

and a switching unit 740, configured to switch the access flow of the source database to the updated destination database.

Optionally, the updating unit updates the destination database to a state of the source database in the case of a failure of the source data center based on the log file synchronized by the log server, including:

And synchronizing the missing data to the destination database.

Optionally, the second synchronization unit synchronizes the log file of the source database to a log server of the destination data center, including:

receiving a log file pushed by the source database through the log server, and synchronizing the log file pushed by the source database to a memory of the log server, wherein the log file is generated by the source database based on a currently executed change transaction and is pushed to the log server;

the updating unit, through the data transmission tool, updates the destination database to a state of the source database in the case of a failure of the source data center based on the log file synchronized by the log server, including:

and acquiring the log file of the source database from the memory of the log server through the data transmission tool, and updating the destination database to the state of the source database under the condition that the source data center fails based on the log file of the source database.

Optionally, the second synchronization unit synchronizes the log file of the source database to the log server of the destination data center, and further includes:

Optionally, the synchronization unit is further configured to, after synchronizing the log file pushed by the source database to the memory of the log server, return a confirmation message to the source database, where the confirmation message is used for the source database to execute a commit operation on a change transaction recorded by the pushed log file.

Optionally, the apparatus 700 further includes:

the third synchronization unit is configured to synchronize, after the switching unit switches the access flow of the source database to the updated destination database, data of the destination database to the source database through the data transmission tool if the source data center is restored to be normal;

The detection unit is used for carrying out consistency detection on the source end database and the destination end database under the condition that the current time point is the same as the preset time point;

the switching unit is further configured to switch the access flow of the destination database to the source database if the source database is consistent with the destination database.

Optionally, the apparatus 700 further includes:

the acquisition unit is used for acquiring service related information of the destination database and replication delay time between the destination database and the source database before the detection unit performs consistency detection on the source database and the destination database under the condition that the current time point is the same as a preset time point, wherein the service related information is information for reflecting the running service of the destination database;

and a time point determining unit configured to determine the preset time point based on the service related information and the replication delay time.

Obviously, the data center disaster recovery device provided in the embodiment of the present application can be used as an execution body of the data center disaster recovery method shown in fig. 2, for example, step S202 in the data center disaster recovery method shown in fig. 2 may be executed by the first synchronization unit in the data center disaster recovery device shown in fig. 7, step S204 may be executed by the second synchronization unit in the data center disaster recovery device, step S206 may be executed by the update unit in the data center disaster recovery device, and step S208 may be executed by the switching unit in the data center disaster recovery device.

According to another embodiment of the present application, each unit in the disaster recovery device of the data center shown in fig. 7 may be combined into one or several other units separately or all, or some (some) of the units may be further split into a plurality of units with smaller functions to form a unit, which may achieve the same operation without affecting the implementation of the technical effects of the embodiments of the present application. The above units are divided based on logic functions, and in practical applications, the functions of one unit may be implemented by a plurality of units, or the functions of a plurality of units may be implemented by one unit. In other embodiments of the present application, the disaster recovery device of the data center may also include other units, and in practical applications, these functions may also be implemented with assistance of other units, and may be implemented by cooperation of multiple units.

According to another embodiment of the present application, a data center disaster recovery device as shown in fig. 7 may be constructed by running a computer program (including program code) capable of executing steps involved in the corresponding method as shown in fig. 2 on a general-purpose computing device such as a computer including a processing element such as a central processing unit (Central Processing Unit, CPU), a random access storage medium (Random Access Memory, RAM), a Read-Only Memory (ROM), and a storage element, and implementing the data center disaster recovery method of the present application. The computer program may be recorded on, for example, a computer readable storage medium, transferred to, and run in, an electronic device via the computer readable storage medium.

According to the disaster recovery device for the data center, the current database adopts the strategy of log advance, namely when the change transaction of the database is received, the change transaction is generally written into the log file, and then the database is changed based on the change transaction, so that the change transaction recorded by the change log of the source database is more comprehensive than the change transaction already executed by the source database, and further the data which cannot be synchronized to the destination database due to synchronization delay in the source database can be obtained based on the change log of the source database. Based on the data, a data transmission tool and a log server are deployed in the target data center, the data of a source database of the source data center is synchronized to a target database of the target data center through the data transmission tool, and log files of the source database are synchronously stored in the target data center through the log server; under the condition that the source data center fails, updating the destination database to a state of the source database under the condition that the source data center fails through a data transmission tool of the destination data center based on a log file synchronized by a log server of the destination data center, so that missing data of the destination database caused by data synchronization delay between the source database and the destination database can be made up, and the data of the destination database can meet disaster tolerance requirements; further, the access flow of the source end database is switched to the updated destination end database, and the destination end database replaces the source end database to continue to provide data service, so that disaster recovery and recovery time efficiency of the data center can be improved, and RTO time efficiency of the disaster recovery of the data center can be ensured.

Fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application. Referring to fig. 8, at the hardware level, the electronic device includes a processor, and optionally an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory (non-volatile Memory), such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.

The processor, network interface, and memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture ) bus, a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one bi-directional arrow is shown in FIG. 8, but not only one bus or type of bus.

And the memory is used for storing programs. In particular, the program may include program code including computer-operating instructions. The memory may include memory and non-volatile storage and provide instructions and data to the processor.

The processor reads the corresponding computer program from the nonvolatile memory to the memory and then operates the computer program to form the data center disaster recovery device on the logic level. The processor is used for executing the programs stored in the memory and is specifically used for executing the following operations:

synchronizing data of a source database to a destination database through a data transmission tool of the destination data center, wherein the source database is a database deployed in the source data center, and the destination database is a database deployed in the destination data center;

The method executed by the disaster recovery device of the data center disclosed in the embodiment shown in fig. 2 of the present application may be applied to a processor or implemented by the processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or by instructions in the form of software. The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but also digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.

The electronic device may also execute the method of fig. 2 and implement the function of the disaster recovery device of the data center in the embodiment shown in fig. 2, which is not described herein.

Of course, other implementations, such as a logic device or a combination of hardware and software, are not excluded from the electronic device of the present application, that is, the execution subject of the following processing flow is not limited to each logic unit, but may be hardware or a logic device.

The present embodiments also provide a computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a portable electronic device comprising a plurality of application programs, enable the portable electronic device to perform the method of the embodiment of fig. 2, and in particular to:

In summary, the foregoing description is only a preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.

Claims

1. A method of disaster recovery for a data center, comprising:

2. The method of claim 1, wherein updating the destination database to the source database state in the event of a failure of the source data center based on the log file synchronized by the log server comprises:

and synchronizing the missing data to the destination database.

3. The method of claim 1, wherein synchronizing the log file of the source database to the log server of the destination data center comprises:

The updating, by the data transmission tool, the destination database to a state of the source database in the case of a failure of the source data center based on the log file synchronized by the log server, includes:

4. The method of claim 3, wherein synchronizing the log file of the source database to the log server of the destination data center further comprises:

5. The method of claim 3, wherein after synchronizing the log file pushed by the source database to the memory of the log server, the method further comprises:

and returning a confirmation message to the source database, wherein the confirmation message is used for the source database to execute the submitting operation on the change transaction of the pushed log file record.

6. The method according to any one of claims 1 to 5, wherein after switching access traffic of the source database to the updated destination database, the method further comprises:

if the source data center is recovered to be normal, synchronizing the data of the destination database to the source database through the data transmission tool;

under the condition that the current time point is the same as the preset time point, consistency detection is carried out on the source end database and the destination end database;

and if the source end database is consistent with the destination end database, switching the access flow of the destination end database to the source end database.

7. The method of claim 6, wherein prior to the consistency detection of the source database and the destination database if the current point in time is the same as a preset point in time, the method further comprises:

Acquiring service related information of the destination database and copy delay time between the destination database and the source database, wherein the service related information is information for reflecting the running service of the destination database;

the preset time point is determined based on the service related information and the copy delay time.

8. A data center disaster recovery system, comprising: the system comprises a data transmission tool, a log server and a database server, wherein the data transmission tool, the log server and the database server are all deployed in a target data center;

9. The system of claim 8, wherein the log server comprises a log synchronization unit, a storage unit, and a service unit;

10. The system of claim 9, wherein the storage unit comprises a memory;

11. The system of claim 10, wherein the storage unit further comprises a local disk;

12. The system according to claim 10, wherein the log synchronizing unit is further configured to, after synchronizing the pushed log file of the source database to the memory of the log server, return a confirmation message to the source database, where the confirmation message is used by the source database to perform a commit operation on the change transaction recorded by the pushed log file.

13. A data center disaster recovery device, comprising:

the first synchronization unit is used for synchronizing the data of the source end database to the destination end database through a data transmission tool of the destination data center, wherein the source end database is a database deployed in the source data center, and the destination end database is a database deployed in the destination data center;

the second synchronization unit is used for synchronizing the log file of the source database to the log server of the destination data center, and the log file records a change transaction used for changing the source database;

the updating unit is used for updating the destination database to the state of the source database under the condition that the source data center fails based on the log file synchronized by the log server through the data transmission tool if the source data center fails;

and the switching unit is used for switching the access flow of the source end database to the updated destination end database.

14. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

Wherein the processor is configured to execute the instructions to implement the method of any one of claims 1 to 7.

15. A computer readable storage medium, characterized in that instructions in the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the method of any one of claims 1 to 7.