Disaster recovery methods and system

Abstract

Provided in the embodiments of the present disclosure are disaster recovery methods and system. A method comprises: a master server side acquiring replica pair metadata and a replication plan corresponding to the replica pair metadata, and generating a replication task; when the replication task is an asynchronous replication task, sending the replication task to a slave server side by means of an asynchronous replication task interface of the slave server side, such that the slave server side executes the replication task according to a process of the asynchronous replication task; when the replication task is a synchronous replication task, sending the replication task to the slave server side by means of a synchronous replication task interface of the slave server side, such that the slave server side executes the replication task according to a process of the synchronous replication task; after a master server side cloud drive is recovered from a fault, rolling back, on the basis of consistency point information, storage data of the master server side cloud drive to a synchronization start snapshot point of a previous round of asynchronous replication task; and obtaining from the slave server side cloud drive incremental data after the synchronization start snapshot point of the previous round of asynchronous replication task.

Description

Disaster recovery methods and systems

[0001] This disclosure claims priority to the Chinese patent application filed with the China Patent Office on September 4, 2023, with application number 202311134653.4 and application name “Disaster Recovery Method and System”, the entire contents of which are incorporated by reference into this disclosure. Technical Field

[0002] The embodiments of the present disclosure relate to the technical field of cloud computing, and in particular to a disaster recovery method. Background Art

[0003] In the era of big data, data is the core asset and lifeblood of any enterprise. Data disaster recovery is crucial to the survival of modern enterprises. Cloud storage services, provided by cloud vendors, offer disaster recovery services that facilitate rapid business deployment and reduce user costs. Therefore, in the era of rapid cloud computing development, more and more enterprise customers are considering cloud-based disaster recovery.

[0004] Currently, cloud disks generally adopt a unilateral disaster recovery management approach, whereby the replication process from the source cloud disk to the destination cloud disk is managed by a single control node. However, this disaster recovery management approach suffers from poor reliability. If a control node fails, the disaster recovery system becomes unusable. Furthermore, disaster recovery management systems only support either synchronous or asynchronous replication, making them less universal.

[0005] Summary of the Invention

[0006] In view of this, embodiments of the present disclosure provide a disaster recovery method. One or more embodiments of the present disclosure also involve a disaster recovery apparatus, a computing device, a computer-readable storage medium, and a computer program to address technical deficiencies in the prior art.

[0007] According to a first aspect of an embodiment of the present disclosure, a disaster recovery method is provided, which is applied to a master server, comprising: obtaining replication pair metadata and a replication plan corresponding to the replication pair metadata, wherein the replication pair metadata includes correspondence information between a master server cloud disk and a slave server cloud disk, and the slave server is used to provide access services when a failure occurs on the master server; generating a replication task based on the replication pair metadata and the replication plan, wherein the replication task is used to replicate data on the master server cloud disk to the slave server cloud disk, so that data stored on the slave server cloud disk is consistent with data stored on the master server cloud disk; in the case where the replication task is an asynchronous replication task, the replication task is sent to the slave server through the asynchronous replication task interface of the slave server, so that the slave server performs the asynchronous replication task according to the asynchronous replication task. The process of the task executes the replication task; in the case that the replication task is a synchronous replication task, the replication task is sent to the slave server through the synchronous replication task interface of the slave server, so that the slave server executes the replication task according to the process of the synchronous replication task; the replication pair metadata also includes: the consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization starting snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk; the method also includes: when the master server cloud disk recovers from the failure, according to the consistency point information, the storage data of the master server cloud disk is rolled back to the synchronization starting snapshot point of the previous round of asynchronous replication tasks; and the incremental data after the synchronization starting snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk.

[0008] According to the second aspect of the embodiment of the present disclosure, a disaster recovery method is provided, which is applied to a slave server, including: if an asynchronous replication task sent by a master server is received through the asynchronous replication task interface of the slave server, the asynchronous replication task is executed according to the process of the asynchronous replication task; if a synchronous replication task sent by the master server is received through the synchronous replication task interface of the slave server, the synchronous replication task is executed according to the process of the synchronous replication task, the asynchronous replication task and the synchronous replication task are used to copy the data of the master server cloud disk to the slave server cloud disk, so that the data stored in the slave server cloud disk is consistent with the data stored in the master server cloud disk; when the master server cloud disk fails, the slave server cloud disk replaces the master server cloud disk to provide access services; after the master server recovers from the failure, the replication pair metadata is obtained, and the replication pair metadata includes : The correspondence information between the master server cloud disk and the slave server cloud disk, the replication pair metadata also includes: the consistency point information corresponding to the previous round of asynchronous replication tasks, the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk, so that when the master server cloud disk recovers from the failure, according to the consistency point information, the storage data of the master server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks, and the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk; according to the replication pair metadata, a reverse replication task is generated and executed, the reverse replication task is used to copy the incremental data of the slave server cloud disk after the disaster recovery is started to the master server cloud disk, so that the data stored on the master server cloud disk is consistent with the data stored on the slave server cloud disk.

[0009] According to a third aspect of an embodiment of the present disclosure, a disaster recovery system is provided, comprising: a master server applying the disaster recovery method described in any embodiment of the present disclosure and a slave server applying the disaster recovery method described in any embodiment of the present disclosure.

[0010] According to the fourth aspect of an embodiment of the present disclosure, a computing device is provided, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the above-mentioned disaster recovery method.

[0011] According to a fifth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the above-mentioned disaster recovery method are implemented.

[0012] According to a sixth aspect of an embodiment of the present disclosure, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned disaster recovery method.

[0013] According to a seventh aspect of an embodiment of the present disclosure, a computer program product is provided, including a computer program, which implements the steps of the above-mentioned disaster recovery method when executed by a processor.

[0014] An embodiment of the present disclosure implements a disaster recovery method applied to a master server. Due to this method, the master server obtains replication pair metadata and a replication plan corresponding to the replication pair metadata. The replication pair metadata includes correspondence information between the master server cloud disk and the slave server cloud disk. The slave server is used to provide access services when a failure occurs in the master server. Therefore, the master server can generate a replication task based on the replication pair metadata and the replication plan, and the slave server provides an asynchronous replication task interface and a synchronous replication task interface. Therefore, when the replication task is an asynchronous replication task, the master server can send the replication task to the slave server through the asynchronous replication task interface of the slave server, so that the slave server executes the replication task according to the process of the asynchronous replication task. In the case where the replication task is a synchronous replication task, the master server can send the replication task to the slave server through the synchronous replication task interface of the slave server, so that the slave server executes the replication task according to the process of the synchronous replication task. Moreover, the replication metadata also includes: consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk. When the master server cloud disk recovers from the failure, the storage data of the master server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks according to the consistency point information, and the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk. It can be seen that in this method, the master server can generate a replication task by obtaining the replication pair metadata and replication plan, and rely on the abstract interface of the two replication tasks between the master server and the slave server to enable the slave server to execute the replication task according to the corresponding process, so that the master and the slave collaborate to complete the data synchronization, realize the bilateral architecture of cross-regional disaster recovery of the cloud disk, reduce the coupling between the master and the slave, improve the reliability of the cloud disk disaster recovery, and support both synchronous replication and asynchronous replication. The universality of cloud disk disaster recovery is improved, and after the master server recovers from the fault, data synchronization is completed through the consistency point information, and only incremental data needs to be copied, which improves efficiency.

[0015] Another embodiment of the present disclosure implements a disaster recovery method applied to a slave server. If the method receives an asynchronous replication task sent by the master server through the asynchronous replication task interface of the slave server, the asynchronous replication task is executed according to the process of the asynchronous replication task. If the method receives a synchronous replication task sent by the master server through the synchronous replication task interface of the slave server, the synchronous replication task is executed according to the process of the synchronous replication task. Therefore, the slave server can support the execution of both synchronous replication tasks and asynchronous replication tasks. Therefore, when disaster recovery is started, the cloud disk of the slave server can provide access services instead of the cloud disk of the master server. Moreover, after the master server cloud disk recovers from the failure, the slave server can obtain the replication pair metadata, and the replication pair metadata also includes: the consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk, so that when the master server cloud disk recovers from the failure, according to the consistency point information, the storage data of the master server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks, and the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk, and then the slave server generates and executes the reverse replication task according to the replication pair metadata to restore the service of the master server cloud disk, thereby realizing the bilateral architecture of cross-regional disaster recovery of the cloud disk, reducing the coupling between the master and the slave, improving the reliability of the cloud disk disaster recovery, and being able to support both synchronous replication and asynchronous replication, thereby improving the universality of cloud disk disaster recovery.

[0016] It can be seen that according to the disaster recovery method provided by the embodiment of the present disclosure, the master and slave servers can manage the replication pair metadata of the available zone based on their respective replication pair metadata to generate replication tasks and reverse replication tasks on demand, and rely on the two abstract interfaces of synchronous replication tasks and asynchronous replication tasks between the master and slave servers. The slave server can execute replication tasks according to the corresponding process, and after the master server recovers from the fault, data synchronization is completed through consistency point information, and only incremental data needs to be copied, which improves efficiency. The master and slave collaborate to complete the data synchronization, realize the bilateral architecture of cross-regional disaster recovery of cloud disks, reduce the coupling between master and slaves, improve the reliability of cloud disk disaster recovery, and can support both synchronous replication and asynchronous replication, thereby improving the universality of cloud disk disaster recovery.

[0017] These and other aspects of the present disclosure will become more apparent from the following description of the embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] FIG1 is a schematic structural diagram of a disaster recovery system provided by an embodiment of the present disclosure;

[0019] FIG2 is a flow chart of a disaster recovery method provided by an embodiment of the present disclosure;

[0020] FIG3a is a schematic diagram of master-slave division of labor and collaboration provided by an embodiment of the present disclosure;

[0021] FIG3 b is a schematic diagram of synchronization point recording bits provided by an embodiment of the present disclosure;

[0022] FIG4 is a schematic diagram of a user interaction interface provided by an embodiment of the present disclosure;

[0023] FIG5 is a modular schematic diagram of a disaster recovery method provided by an embodiment of the present disclosure;

[0024] FIG6 is a schematic diagram of a bilateral collaboration process of a disaster recovery method provided by an embodiment of the present disclosure;

[0025] FIG7 is a schematic structural diagram of a disaster recovery device provided by an embodiment of the present disclosure;

[0026] FIG8 is a flow chart of a disaster recovery method provided by another embodiment of the present disclosure;

[0027] FIG9 is a schematic structural diagram of a disaster recovery device provided by another embodiment of the present disclosure;

[0028] FIG10 is a structural block diagram of a computing device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0029] The following description sets forth many specific details to facilitate a full understanding of the present disclosure. However, the present disclosure can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of the present disclosure. Therefore, the present disclosure is not limited to the specific implementations disclosed below.

[0030] The terms used in one or more embodiments of the present disclosure are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of the present disclosure. The singular forms "a", "the", and "the" used in one or more embodiments of the present disclosure and the appended claims are also intended to include plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of the present disclosure refers to and includes any or all possible combinations of one or more associated listed items.

[0031] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of the present disclosure, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of the present disclosure, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0032] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of the present disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0033] First, the terms involved in one or more embodiments of the present disclosure are explained.

[0034] Disaster recovery refers to the establishment of two or more systems with the same functions in remote locations. These systems can monitor each other's health status and switch functions. When one system stops working due to an accident (such as fire or earthquake), the entire application system can be switched to another location so that the system functions can continue to operate normally.

[0035] RPO: Recovery Point Objective, data recovery point objective, refers to the amount of data loss that the business system can tolerate.

[0036] Asynchronous replication: refers to remote replication with an RPO greater than 0.

[0037] Synchronous replication: refers to remote replication with RPO = 0.

[0038] Cloud disk: refers to the highly reliable virtual storage space of a cloud server.

[0039] Replication pair: In synchronous replication and asynchronous replication, the replication relationship between cloud disks across regions is called a replication pair.

[0040] Primary server cloud disk: In a replication pair, the data source where the data is located before replication is called the primary server cloud disk.

[0041] Slave server cloud disk: In a replication pair, the destination disk to which data is replicated is called the slave server cloud disk.

[0042] Primary server: The server of the primary server cloud disk can be understood as the production site for disaster recovery.

[0043] From the server side: The server side of the server cloud disk can be understood as a disaster recovery site.

[0044] Cloud disks typically provide disaster recovery services. Cross-regional disaster recovery for cloud disks involves replicating data from one cloud disk to another region at a specific RPO, ensuring that the replicated data meets certain consistency semantics to guarantee data availability. This way, if a failure occurs in the service region, the cloud disk in the disaster recovery region can continue to provide service through failover, ensuring service continuity. Once the failure is resolved, the service can be relocated to the original service region through failback, and disaster recovery replication can be restarted. Cloud disk disaster recovery can be categorized as synchronous replication or asynchronous replication, depending on the RPO. Synchronous replication is disaster recovery with an RPO of 0, where data between the master and slave nodes remains completely synchronized. Asynchronous replication is disaster recovery with an RPO greater than 0, where the data difference between the master and slave nodes is no greater than the RPO time.

[0045] Currently, cloud disks generally adopt a unilateral disaster recovery management approach, whereby the replication process from the source cloud disk to the destination cloud disk is managed by a single control node. However, this disaster recovery management approach suffers from poor reliability. If a control node fails, the disaster recovery system becomes unusable. Furthermore, disaster recovery management systems only support either synchronous or asynchronous replication, making them less universal.

[0046] In view of this, in order to improve the reliability and universality of disaster recovery, a disaster recovery method is provided in the present disclosure. The present disclosure also involves a disaster recovery device, a disaster recovery system, a computing device, and a computer-readable storage medium, which are described in detail one by one in the following embodiments.

[0047] 1 , which shows a schematic diagram of the system structure of a disaster recovery system according to an embodiment of the present disclosure. As shown in FIG1 , the disaster recovery system specifically includes: a master server 102 and a slave server 104 .

[0048] The master server 102 is configured to obtain replication pair metadata and a replication plan corresponding to the replication pair metadata, wherein the replication pair metadata includes: information on the corresponding relationship between the master server cloud disk and the slave server cloud disk, wherein the slave server is used to provide access services when a failure occurs on the master server; generating a replication task based on the replication pair metadata and the replication plan, wherein the replication task is used to replicate the data on the master server cloud disk to the slave server cloud disk, so that the data stored on the slave server cloud disk is consistent with the data stored on the master server cloud disk; in the case where the replication task is an asynchronous replication task, the replication task is sent to the slave server through the asynchronous replication task interface of the slave server, so that the slave server executes the replication task according to the process of the asynchronous replication task. control task; in the case that the replication task is a synchronous replication task, the replication task is sent to the slave server through the synchronous replication task interface of the slave server, so that the slave server executes the replication task according to the process of the synchronous replication task; the replication metadata also includes: the consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk; the method also includes: when the master server cloud disk recovers from the failure, according to the consistency point information, the storage data of the master server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks; and the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk.

[0049] The slave server 104 is configured to execute the asynchronous replication task according to the process of the asynchronous replication task if it receives the asynchronous replication task sent by the master server through the asynchronous replication task interface of the slave server; execute the synchronous replication task according to the process of the synchronous replication task if it receives the synchronous replication task sent by the master server through the synchronous replication task interface of the slave server; when disaster recovery is started, the slave server cloud disk replaces the master server cloud disk to provide access service; after the master server recovers from the fault, the replication pair metadata is obtained, the replication pair metadata includes: the correspondence information between the master server cloud disk and the slave server cloud disk, the replication pair metadata also includes: the consistent relationship information corresponding to the previous round of asynchronous replication tasks The consistency point information includes at least: the synchronization starting snapshot point of the previous round of asynchronous replication task on the master server cloud disk, so that when the master server cloud disk recovers from the failure, the storage data of the master server cloud disk is rolled back to the synchronization starting snapshot point of the previous round of asynchronous replication task according to the consistency point information, and the incremental data after the synchronization starting snapshot point of the previous round of asynchronous replication task is obtained from the slave server cloud disk; according to the replication pair metadata, a reverse replication task is generated and executed, and the reverse replication task is used to copy the incremental data of the slave server cloud disk after the disaster recovery is started to the master server cloud disk, so that the data stored in the master server cloud disk is consistent with the data stored in the slave server cloud disk.

[0050] As shown in Figure 1, the master server 102 and the slave server 104 may have their own storage systems. The storage system may include one or more cloud disks. The cloud disk in the storage system of the master server 102 is called the master server cloud disk, and the cloud disk in the storage system of the slave server 104 is called the slave server cloud disk. A cloud disk is a virtual storage device at the data block level provided by the cloud. The bottom layer of the cloud disk may be a physical block storage device such as a disk. The master server and the slave server can be understood as cloud servers. A cloud server can be a distributed server cluster including multiple servers or a single server. The services provided by the cloud server may include: cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and basic cloud computing services such as big data and artificial intelligence platforms.

[0051] It can be seen from the above application scenarios that according to the disaster recovery system provided by the embodiment of the present disclosure, the master and slave servers can manage the replication pair metadata of the available zone based on their respective replication pair metadata to generate replication tasks and reverse replication tasks on demand, and rely on the abstract interface of the two replication tasks between the master server and the slave server to enable the slave server to execute the replication task according to the corresponding process. The master and slave cooperate with each other to complete the synchronization of data, realizing the bilateral architecture of cross-regional disaster recovery of cloud disks, improving the reliability of cloud disk disaster recovery, and being able to support both synchronous replication and asynchronous replication, thereby improving the universality of cloud disk disaster recovery.

[0052] Referring to Figure 2, Figure 2 shows a flow chart of a disaster recovery method provided according to an embodiment of the present disclosure. The disaster recovery method can be applied to a primary server. As shown in Figure 2, the disaster recovery method specifically includes the following steps.

[0053] Step 202: Obtain replication pair metadata and a replication plan corresponding to the replication pair metadata, wherein the replication pair metadata includes: correspondence information between the master server cloud disk and the slave server cloud disk, and the slave server is used to provide access services when a failure occurs in the master server.

[0054] Replication pair metadata, corresponding to a replication pair, is data used to describe the replication pair, including at least the corresponding relationship information between the master server cloud disk and the slave server cloud disk. Replication pair metadata can also be understood as management entries used to manage the properties of the corresponding master server cloud disk and the slave server cloud disk.

[0055] Depending on the application scenario, the replication pair metadata may also include other user-configured information, such as the replication pair name and region information, as well as replication task-related information, such as replication task status information and consistency point information. For example, the replication pair metadata may include the replication pair name (e.g., the replication pair name is "Replication Pair 1"), the corresponding relationship between the primary server's cloud disk and the secondary server's cloud disk (e.g., "A1<->B1" indicates that cloud disk A1 on server A corresponds to cloud disk B1 on server B, and there is a replication relationship between the two).

[0056] Step 204: Generate a replication task based on the replication pair metadata and the replication plan, wherein the replication task is used to replicate the data of the master server cloud disk to the slave server cloud disk, so that the data stored in the slave server cloud disk is consistent with the data stored in the master server cloud disk.

[0057] As you can understand, since synchronous and asynchronous replication tasks have different processes, the master server is responsible for promoting the replication task execution plan and lifecycle management to ensure that synchronous and asynchronous replication tasks are executed according to the correct process. The replication plan is the process information used to promote the execution of replication tasks. For example, for asynchronous replication tasks, the replication plan can be set to start a replication cycle every RPO / 2, while for synchronous replication tasks, the replication plan can be set to maintain the task for a long time after replication starts.

[0058] Because the replication pair metadata contains the correspondence between the master and slave cloud disks, the master server can determine the slave cloud disk for disaster recovery based on this correspondence and generate a replication task to copy the master cloud disk's data to the slave cloud disk according to the replication plan. The replication pair metadata also includes consistency point information corresponding to the previous round of asynchronous replication tasks, which includes at least the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master cloud disk.

[0059] The replication task may be an asynchronous replication task or a synchronous replication task according to the RPO requirements of the actual application scenario.

[0060] Understandably, there are some differences between the processes of synchronous and asynchronous replication tasks. For example, a synchronous replication task is a long-term replication task that starts after replication is initiated, while an asynchronous replication task is a short-term replication task that periodically initiates a replication cycle. Therefore, asynchronous replication tasks require periodic snapshots to obtain incremental data in stages.

[0061] Taking the synchronous replication task as an example, the replication task is generated according to the replication pair metadata and the replication plan, including: generating a long-term replication task for fully replicating the data of the primary server cloud disk to the secondary server cloud disk according to the replication pair metadata.

[0062] Taking an asynchronous replication task as an example, generating a replication task according to the replication pair metadata and the replication plan includes:

[0063] According to the replication plan corresponding to the replication pair metadata being an asynchronous replication plan, determining the synchronization start snapshot point of the previous round of asynchronous replication tasks on the primary server cloud disk;

[0064] Generate a current asynchronous replication task, which is used to copy the incremental data of the master server cloud disk between the synchronization start snapshot point of the previous round of asynchronous replication task and the synchronization start snapshot point of the current asynchronous replication task to the slave server cloud disk.

[0065] Step 206: When the replication task is an asynchronous replication task, the replication task is sent to the slave server through the asynchronous replication task interface of the slave server, so that the slave server executes the replication task according to the asynchronous replication task process.

[0066] Step 208: When the replication task is a synchronous replication task, the replication task is sent to the slave server through the synchronous replication task interface of the slave server, so that the slave server executes the replication task according to the synchronous replication task process.

[0067] Step 210: After the primary server cloud disk recovers from the failure, the storage data of the primary server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication task according to the consistency point information.

[0068] Step 212: Obtain incremental data after the synchronization start snapshot point of the previous round of asynchronous replication task from the slave server cloud disk.

[0069] Because the slave server provides an asynchronous replication task interface and a synchronous replication task interface, this method can implement different execution processes for synchronous replication tasks and asynchronous replication tasks based on interface instantiation. A synchronous replication task is a long-term, uninterrupted task execution process, while an asynchronous replication task requires periodic generation of an execution point and phased acquisition of incremental data for replication. This supports both synchronous and asynchronous replication modes and improves the universality of cloud disk disaster recovery. For example, as shown in the master-slave division of labor and collaboration diagram in Figure 3a, the master server is responsible for task execution management (such as promoting the execution plan and lifecycle management of the replication task), and the slave server is responsible for replication task execution (such as executing specific replication tasks and pushing the replication task forward according to the state machine corresponding to the task). The replication task is represented by an instantiated synchronous replication task or an instantiated asynchronous replication task.

[0070] It can be seen that in this method, the master server can generate a replication task by obtaining the replication pair metadata, and rely on the abstract interface of the two replication tasks between the master server and the slave server to enable the slave server to execute the replication task according to the corresponding process, so that the master and the slave cooperate with each other to complete the data synchronization, realize the bilateral architecture of cross-regional disaster recovery of the cloud disk, reduce the coupling between the master and the slave, improve the reliability of the cloud disk disaster recovery, and can support both synchronous replication and asynchronous replication, thereby improving the universality of cloud disk disaster recovery. After the master server recovers from the fault, data synchronization is completed through the consistency point information, and only incremental data needs to be copied, which improves efficiency.

[0071] In the above embodiment, in order to enable the user service to switch back to the master server as quickly as possible after the master server recovers from a fault and improve the switching efficiency, the consistency point information corresponding to the previous round of asynchronous replication tasks is also recorded in the replication pair metadata. By recording the consistency point information corresponding to the previous round of asynchronous replication tasks and associating the previous round of asynchronous replication tasks during reverse replication, the data relationship between the master server cloud disk and the slave server cloud disk can be found as quickly as possible, and the incremental data that needs to be reverse replicated can be found as quickly as possible, avoiding the reverse replication of the full amount of data and reducing the duration of reverse replication. Accordingly, the replication pair metadata on the slave server side can include: the consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization completion snapshot point of the previous round of asynchronous replication tasks on the slave server cloud disk. In this way, the slave server cloud disk can determine the synchronization completion snapshot point of the previous round of asynchronous replication task on the slave server cloud disk based on the replication pair metadata, and generate a reverse replication task based on the synchronization completion snapshot point. The reverse replication task is used to copy the incremental data of the slave server cloud disk from the synchronization completion snapshot point to the current moment to the master server cloud disk.

[0072] It should be noted that the previous round of asynchronous replication tasks is a completed asynchronous replication task. Therefore, the data of the previous round of asynchronous replication tasks on the master server cloud disk is consistent with the data of the previous round of asynchronous replication tasks on the slave server cloud disk at the synchronization completion snapshot point. In the process of copying data from the master server cloud disk to the slave server cloud disk, failures may occur at any time, and the previous round of asynchronous replication tasks must be completed asynchronous replication tasks. Even if a failure occurs, as long as the consistency point information of the previous round of asynchronous replication tasks is recorded, the relationship between the data on the master server cloud disk and the data on the slave server cloud disk can be found based on the consistency point information. Therefore, in this embodiment, the master server cloud disk rolls back to the synchronization start snapshot point of the previous round of asynchronous replication tasks. In this case, it is only necessary to obtain the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks from the slave server cloud disk to make the master and slave data consistent, thereby switching back the service. Since the amount of incremental data is small, the recovery time of service switching back can be greatly saved, and the switching back efficiency can be improved.

[0073] Specifically, a synchronization point record bit can be set for each asynchronous replication task in the replication pair metadata. The synchronization point record bit is used to record the synchronization start snapshot point of the corresponding current round of asynchronous replication tasks on the master server cloud disk and the synchronization completion snapshot point on the slave server cloud disk, as well as the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk and the synchronization completion snapshot point on the slave server cloud disk. For example, as shown in the synchronization point record bit diagram in FIG3b, the data of the synchronization start snapshot point and the synchronization completion snapshot point of a round of asynchronous replication tasks are consistent. For example, during reverse replication, the data of Sstandby1 shown in FIG3b is consistent with the data of Sprimary1. At this time, the data of the master server cloud disk is rolled back to Sprimary1, which can ensure that the incremental data after Sstandby1 is obtained from the slave server cloud disk, and the data of the master and slave cloud disks can be kept consistent. It can be seen that the first round of replication in reverse replication is an incremental replication with a very small amount of data, which can greatly save the recovery time of service switching back. In Figure 3b, Sprimary1 represents the synchronization start snapshot point of the current round of asynchronous replication tasks, and Sstandby1 represents the synchronization completion snapshot point of the current round of asynchronous replication tasks. Sprimary0 represents the synchronization start snapshot point of the previous round of asynchronous replication tasks, and Sstandby0 represents the synchronization completion snapshot point of the previous round of asynchronous replication tasks.

[0074] In order to facilitate users to perform disaster recovery related management, one or more embodiments of the present disclosure also provide an embodiment for implementing user management functions. Specifically, the method further includes:

[0075] receiving a user's management operation on the replica pair metadata, the management operation including any one or more operations of a create operation, a delete operation, a query operation, a modify operation, and a stop operation;

[0076] executing the management operation;

[0077] The management operation is performed on the slave server through remote calling.

[0078] In one or more embodiments of the present disclosure, in order to improve the efficiency of user management of replication pairs, multiple replication pairs can also be grouped into replication groups so that users can perform the above management operations on the replication groups, so that users can perform the same management on multiple replication pairs at one time.

[0079] According to this embodiment, users can create replication pairs or replication groups, delete replication pairs or replication groups, modify replication pair or replication group information, query replication pairs or replication groups, and stop replication tasks for replication pairs or replication groups. More granularly, for example, users can manage any information in replication pair metadata, including the cloud disk corresponding to the disk, replication pair name, replication pair status (such as stop replication, start replication, etc.), and regional information.

[0080] For example, the main server can provide a user interaction interface as shown in Figure 4, which displays relevant information of replication pairs and replication groups and interactive controls for users to input management operations. Users can input the management operations in the user interaction interface through any interactive method such as clicking, double-clicking, touching, hovering the mouse, sliding, long pressing, voice control or shaking.

[0081] For another example, the master server can communicate with an external party to receive management operations. For example, the master server can communicate with a user's client and present a user interface such as that shown in FIG4 to the user on the client. In this embodiment, to enable the master server to receive external management operations, the master server can also provide an external service interface, thereby receiving external requests through the service interface. Such requests may include management operation requests, disaster recovery failover requests, reverse replication requests, and the like.

[0082] The disaster recovery method provided by the embodiments of the present disclosure adopts a master-slave bilateral architecture. Therefore, in order to facilitate users to manage disaster recovery on the slave server, in one or more embodiments of the present disclosure, the slave server can also provide the above-mentioned service interface to receive user management operations.

[0083] In addition, when the management operation is completed, the main server can also return the operation result corresponding to the management operation to the user, for example, returning information such as successful creation of the replication pair, failed creation of the replication pair, and stopped replication.

[0084] Taking the management operation as a creation operation as an example, the receiving of the user's management operation on the replica pair metadata includes:

[0085] A user creation operation on the replication pair metadata is received.

[0086] Accordingly, the performing of the management operation includes:

[0087] According to the creation operation, corresponding replication pair metadata is created.

[0088] Accordingly, executing the management operation on the slave server through remote calling includes:

[0089] Through remote calling, corresponding replication pair metadata is created on the slave server.

[0090] In this embodiment, when a user performs management operations on either the master or slave side, the same management operations are automatically performed on the other side via remote calls. For example, when a user creates a replica pair on the master server, the slave server also creates the same replica pair and replica pair metadata. This prevents a single-side failure from causing the disaster recovery system to become unavailable. Specifically, the user's create operation request can be routed to the master server of the replica pair by default. The master server performs a validity check on the request, persistently stores the corresponding replica pair metadata, and creates the replica pair on the slave server via remote calls.

[0091] It should be noted that some management operations may involve setting the status of underlying resources and require multiple processing steps. In such cases, management operations can be executed via asynchronous tasks, thus avoiding time-consuming management operations that could cause program blocking. Furthermore, to prevent exceptions caused by concurrent management operations on the same replication pair or replication group, multiple asynchronous tasks used to execute management operations on the same replication pair or replication group can be mutually exclusive. It is important to note that the user's replication pair status is based on the master server's replication pair status. Therefore, the master server must wait for the slave server to return a message indicating that the creation status has been completed before setting the replication pair's status to "completed." For example, when the remote call to the slave server succeeds, both the master and the slave have completed the creation operation. However, since the master and the slave perform the creation operation by submitting asynchronous tasks, the replication pair is not successfully created when the asynchronous tasks are launched and executed in the background. Therefore, after the remote call succeeds, the replication pair's corresponding status remains "Creating." Only after both the master and the slave have completed the replication pair creation do they each set their respective replication pair status to "Completed." In addition, if an asynchronous task fails after multiple executions, such as reaching the retry limit or time limit, the asynchronous task can be marked as failed, and the status of the replication pair can be set to creation failure.

[0092] In one or more embodiments of the present disclosure, the master server also needs to synchronously obtain relevant status information returned by the slave server for the replication pair, thereby promoting replication planning and lifecycle management for the replication pair based on the relevant status information returned by the slave server. Specifically, the method further includes: polling the slave server through a status query interface to obtain synchronization information, wherein the synchronization information includes at least the status information returned by the slave server for the replication pair.

[0093] For example, the replication plan may be updated based on the synchronization information obtained through polling, the operation result of the remote call for the management operation may be updated, and the related information of the replication pair metadata, such as the consistency point information, may be updated.

[0094] The status query interface specifies the communication rules for querying synchronization information. Through the status query interface, the master server can communicate with the slave server and poll to obtain synchronization information for any task executed by the slave server. For example, the execution status information may include: the execution progress information of the aforementioned asynchronous tasks, including status details such as "in progress", "completed", and "failed", and the execution progress information of the replication tasks, including status details such as "in progress", "completed", and "failed".

[0095] In one or more embodiments of the present disclosure, the replication pair metadata may be stored in a pluggable metadata storage module. This metadata storage module may provide a unified metadata abstraction interface, employ a pluggable design, and support different types of storage, such as databases or any other highly reliable storage system, such as distributed key-value pairs.

[0096] It should be noted that the method provided in the embodiment of the present disclosure can be implemented by splitting it into multiple modules according to its functions. Each module can provide an abstract interface and be executed by calling it, so that the system implemented by the method provided in the embodiment of the present disclosure is easier to implement, avoids duplication of construction, and has good versatility.

[0097] The following, in conjunction with Figure 5, takes the application of the disaster recovery method provided by the present disclosure, which is divided into multiple modules according to functional division, as an example, to further illustrate the disaster recovery method. Figure 5 shows a modular schematic diagram of a disaster recovery method provided by an embodiment of the present disclosure. As shown in Figure 5, both the master and the slave have service interfaces, replication pair management and replication group management, asynchronous task management and execution log management, metadata storage and other modules. In addition, the master server also includes a synchronization plan management module, and the slave server also includes a replication task management module. Specifically:

[0098] The service interface module is used to receive external requests, such as receiving user management operations, including creating, querying, deleting, activating, and stopping replication peers. It can also receive user disaster recovery failover operations and reverse replication operations, and return the results of related operations to the user.

[0099] The replication pair management module is used to perform corresponding management functions on the replication pair metadata according to the management operations received from the user.

[0100] The replication group management module is configured to perform corresponding management functions on the replication pair metadata of the plurality of replication pairs in the replication group according to the received management operations of the user.

[0101] The asynchronous task management module is used to perform some complex management operations, such as creating and deleting replica pairs, through the asynchronous task management mechanism. Specifically, before the service interface returns information to the user, the asynchronous task management module will submit the asynchronous task. The asynchronous task is set to have mutually exclusive semantics for the operation object. An operation object can be a replica pair or a replica group, thereby ensuring that an operation object can only submit one asynchronous task, avoiding abnormal situations caused by multiple asynchronous tasks running concurrently. At the same time, the asynchronous task management module can also be responsible for the scheduling and execution of asynchronous tasks. When an error occurs during the execution of an asynchronous task, the asynchronous task management module can automatically back off and retry the asynchronous task.

[0102] The execution log management module is used to log the interfaces of each module and provide interface idempotence. Interface idempotence means that the result of executing an operation N times is the same as executing it once.

[0103] The metadata storage module is used to store replication pair metadata.

[0104] The synchronization plan management module is used to promote and manage the life cycle of the execution plan of the replication pair. It can receive the synchronization information returned from the server and promote and manage according to the synchronization information.

[0105] The replication task management module is used to execute specific replication tasks and push the replication tasks forward according to the state machine.

[0106] It can be seen from this embodiment that this embodiment incorporates synchronous replication and asynchronous replication into a unified disaster recovery management model. Through the abstraction and layering of modules and the instantiation of abstract interfaces, the different designs of synchronous replication and asynchronous replication are solved, which facilitates architectural reuse, avoids duplicate construction, and has good versatility.

[0107] The following further illustrates the process of the master server and the slave server collaborating to perform asynchronous replication tasks, in conjunction with FIG6 . FIG6 illustrates a schematic diagram of the bilateral collaboration process of a disaster recovery method provided by one embodiment of the present disclosure. As shown in FIG6 , the process specifically includes:

[0108] Step 602: Generate a synchronization start snapshot point Sprimary 1 for the primary server cloud disk.

[0109] Step 604: The primary server generates an asynchronous replication task for this round, which is used to replicate the incremental data between the synchronization start snapshot point Sprimary 0 of the previous round of asynchronous replication task and the synchronization start snapshot point Sprimary 1 of the current round of asynchronous replication task to the cloud disk of the secondary server.

[0110] Step 606: The master server sends the asynchronous replication task of this round to the slave server.

[0111] Step 608: The slave server executes the received asynchronous replication task, and upon completion of the asynchronous replication task, generates a synchronization completion snapshot point Sstandby 1 for the slave server cloud disk.

[0112] Step 610: After completing the current round of asynchronous replication tasks, the slave server deletes the synchronization completion snapshot point Sstandby 0.

[0113] In addition, the master server can also obtain synchronization information from the slave server through polling, such as consistency point information.

[0114] Step 612: When the primary server determines that the secondary server has completed the current round of asynchronous replication tasks, the primary server deletes the synchronization starting snapshot point Sprimary 0.

[0115] Sprimary1 represents the synchronization start snapshot point of the current round of asynchronous replication tasks, and Sstandby1 represents the synchronization completion snapshot point of the current round of asynchronous replication tasks. Sprimary0 represents the synchronization start snapshot point of the previous round of asynchronous replication tasks, and Sstandby0 represents the synchronization completion snapshot point of the previous round of asynchronous replication tasks.

[0116] It is understandable that when the current round of asynchronous replication tasks is completed, the current round of asynchronous replication tasks randomly becomes the previous round of asynchronous replication tasks in the actual sense, and the previous round of asynchronous replication tasks immediately becomes the previous round of asynchronous replication tasks. Therefore, in order to save storage space, the master and slave ends can delete the synchronization start snapshot point and synchronization completion snapshot point of the previous round of asynchronous replication tasks.

[0117] In the above processing, in order to reduce the master-slave dependency, the consistency point information of the master and slave can be completed within the local availability zone. For example, the consistency point Sstandby1 of the slave server's cloud disk is completed by the slave server itself and does not require the participation of the master server. In order to minimize the coupling between the master and the slave, the slave server can also provide an interactive interface for master-slave interaction. For example: an interactive interface for replication tasks can be provided, and the interactive interface for replication tasks can support the dispatch of replication tasks for replication pairs or replication groups. For another example: a status query interface can be provided, and the master server can poll the execution status of the replication tasks of the slave server through the status query interface. The consistency point information generated by each master and slave can also be obtained through the status query interface. The master and slave ends store the consistency point information in persistent storage through the metadata storage module.

[0118] This embodiment shows that, in order to address the complexity of bilateral collaboration and synchronization brought about by the bilateral architecture, through collaboration between the master and the slave, the availability zone only needs to manage the storage status and consistency point information of the availability zone. At the same time, through a unified abstract interaction interface, the information between the master and the slave is synchronized, reducing the coupling between the master and the slave.

[0119] Corresponding to the above method embodiment, the present disclosure also provides an embodiment of a disaster recovery device applied to a primary server. FIG7 shows a schematic diagram of the structure of a disaster recovery device provided by an embodiment of the present disclosure. As shown in FIG7, the device includes:

[0120] The metadata acquisition module 702 is configured to obtain replication pair metadata and the replication plan corresponding to the replication pair metadata. The replication pair metadata includes the correspondence information between the master server cloud disk and the slave server cloud disk. The slave server is used to provide access services when the master server fails.

[0121] The task generation module 704 is configured to generate a replication task based on the replication pair metadata and the replication plan. The replication task is used to copy the data of the master server cloud disk to the slave server cloud disk so that the data stored on the slave server cloud disk is consistent with the data stored on the master server cloud disk.

[0122] The first task sending module 706 is configured to send the replication task to the slave server through the asynchronous replication task interface of the slave server when the replication task is an asynchronous replication task, so that the slave server executes the replication task according to the asynchronous replication task process.

[0123] The second task sending module 708 sends the replication task to the slave server through the synchronization replication task interface of the slave server when the replication task is a synchronization replication task, so that the slave server executes the replication task according to the synchronization replication task process.

[0124] In one or more embodiments, the replication pair metadata further includes: consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the primary server cloud disk. The device also includes:

[0125] The rollback module 710 is configured to roll back the storage data of the primary server cloud disk to the synchronization start snapshot point of the previous round of asynchronous replication task according to the consistency point information after the primary server cloud disk recovers from the failure;

[0126] The incremental data obtaining module 712 is configured to obtain the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication task from the server-side cloud disk.

[0127] In one or more embodiments, the apparatus further comprises:

[0128] a management receiving module configured to receive a user's management operation on the metadata of the replication pair, wherein the management operation includes any one or more operations of a create operation, a delete operation, a query operation, a modify operation, and a stop operation;

[0129] A management execution module, which executes the management operation;

[0130] The remote calling module is configured to execute the management operation on the slave server through remote calling.

[0131] In one or more embodiments, the management receiving module is configured to receive a user's creation operation on the replication pair metadata;

[0132] The management execution module is configured to create corresponding replication pair metadata according to the creation operation;

[0133] The remote call module is configured to create corresponding replication pair metadata on the slave server through remote call.

[0134] In one or more embodiments, the task generation module includes:

[0135] A starting point determination submodule is configured to determine a synchronization starting snapshot point of the previous round of asynchronous replication task on the primary server cloud disk according to the replication plan corresponding to the replication pair metadata being an asynchronous replication plan;

[0136] The asynchronous replication task generation submodule is configured to generate the current asynchronous replication task, and the current asynchronous replication task is used to copy the incremental data of the master server cloud disk from the synchronization start snapshot point of the previous round of asynchronous replication task to the synchronization start snapshot point of the current asynchronous replication task to the slave server cloud disk.

[0137] In one or more embodiments, the device further includes: a polling module configured to poll the synchronization information of the slave server through a status query interface of the slave server, wherein the synchronization information at least includes: status information returned by the slave server for the replication pair.

[0138] In one or more embodiments, the replication pair metadata is stored in a pluggable metadata storage module.

[0139] The above is a schematic diagram of the disaster recovery device configured on the primary server in this embodiment. It should be noted that the technical solution of the disaster recovery device and the technical solution of the disaster recovery method described above are based on the same concept. For details not described in detail in the technical solution of the disaster recovery device, please refer to the description of the technical solution of the disaster recovery method described above.

[0140] Corresponding to the above-mentioned disaster recovery method embodiment applied to the master server, the present disclosure also provides a disaster recovery method embodiment applied to the slave server. FIG8 shows a flow chart of a disaster recovery method provided by one embodiment of the present disclosure. As shown in FIG8 , the disaster recovery method includes:

[0141] Step 802: If the asynchronous replication task sent by the master server is received through the asynchronous replication task interface of the slave server, the asynchronous replication task is executed according to the asynchronous replication task process.

[0142] Step 804: If the synchronous replication task sent by the master server is received through the synchronous replication task interface of the slave server, the synchronous replication task is executed according to the synchronous replication task process.

[0143] The asynchronous replication task and the synchronous replication task are used to replicate the data of the master server cloud disk to the slave server cloud disk, so that the data stored in the slave server cloud disk is consistent with the data stored in the master server cloud disk.

[0144] Step 806: When the master server cloud disk fails, the slave server cloud disk replaces the master server cloud disk to provide access services.

[0145] Step 808: After the master server recovers from the failure, the replication pair metadata is obtained, and the replication pair metadata includes: the correspondence information between the master server cloud disk and the slave server cloud disk, and the replication pair metadata also includes: the consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk, so that when the master server cloud disk recovers from the failure, the storage data of the master server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks according to the consistency point information, and the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk.

[0146] Step 810: Based on the replication pair metadata, generate and execute a reverse replication task, wherein the reverse replication task is used to copy the incremental data of the slave server cloud disk after disaster recovery is started to the master server cloud disk, so that the data stored on the master server cloud disk is consistent with the data stored on the slave server cloud disk.

[0147] In the disaster recovery method provided by the embodiment of the present disclosure, when a failure occurs on the primary server, the secondary server cloud disk can replace the primary server cloud disk to provide access services. In this case, the status of the secondary server cloud disk is user-readable and writable, and the secondary server cloud disk can be restored to the most recent consistency point of the secondary server cloud disk, that is, the synchronization completion snapshot point of the previous round of asynchronous replication tasks recorded in this availability zone, and the failover does not rely on the primary server. When the primary server recovers from the failure, if the user wishes to restore the service to the primary server, then, according to this embodiment, the user can initiate a reverse replication request to the secondary server, so that the secondary server generates a reverse replication task, and uses incremental replication to synchronize the incremental data after the failure to the primary server cloud disk.

[0148] According to the disaster recovery method, the slave server can support the execution of synchronous replication tasks and asynchronous replication tasks. When disaster recovery is started, the slave server cloud disk can provide access services instead of the master server cloud disk. Moreover, after the master server recovers from the failure, the slave server can obtain the replication pair metadata, and generate and execute reverse replication tasks based on the replication pair metadata to restore the service of the master server. This realizes the bilateral architecture of cross-regional disaster recovery of the cloud disk, reduces the coupling between the master and the slave, improves the reliability of the cloud disk disaster recovery, and can support both synchronous replication and asynchronous replication, thereby improving the universality of cloud disk disaster recovery.

[0149] The above is an illustrative solution for the disaster recovery method applied to the slave server of this embodiment. It should be noted that the technical solution for the disaster recovery method applied to the slave server is based on the same concept as the technical solution for the disaster recovery method applied to the master server. For details not described in detail in the technical solution for the disaster recovery method applied to the slave server, please refer to the description of the technical solution for the disaster recovery method applied to the master server.

[0150] Corresponding to the above-mentioned disaster recovery method embodiment applied to the slave server, the present disclosure also provides an embodiment of a disaster recovery device configured on the slave server. FIG9 shows a schematic structural diagram of a disaster recovery device provided by an embodiment of the present disclosure. As shown in FIG9 , the device includes:

[0151] The asynchronous replication task receiving module 902 is configured to execute the asynchronous replication task according to the asynchronous replication task process if it receives the asynchronous replication task sent by the master server through the asynchronous replication task interface of the slave server.

[0152] The synchronous replication task receiving module 904 is configured to, upon receiving the synchronous replication task sent by the master server through the synchronous replication task interface of the slave server, execute the synchronous replication task according to the synchronous replication task process.

[0153] The disaster recovery processing module 906 is configured to replace the primary server cloud disk with a secondary server cloud disk to provide access services when the primary server cloud disk fails.

[0154] The fault recovery processing module 908 is configured to obtain replication pair metadata after the master server recovers from the fault. The replication pair metadata includes: the correspondence information between the master server cloud disk and the slave server cloud disk. The replication pair metadata also includes: the consistency point information corresponding to the previous round of asynchronous replication tasks. The consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk, so that when the master server cloud disk recovers from the fault, the storage data of the master server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks according to the consistency point information, and the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk.

[0155] The reverse replication module 910 is configured to generate and execute a reverse replication task based on the replication pair metadata. The reverse replication task is used to copy the incremental data of the slave server cloud disk after disaster recovery is started to the master server cloud disk, so that the data stored on the master server cloud disk is consistent with the data stored on the slave server cloud disk.

[0156] In one or more embodiments, the replication pair metadata further includes: consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization completion snapshot point of the previous round of asynchronous replication tasks on the slave server cloud disk. The reverse replication module 910 includes:

[0157] The completion point determination submodule is configured to determine the synchronization completion snapshot point of the previous round of asynchronous replication task on the slave server cloud disk according to the replication pair metadata.

[0158] The asynchronous reverse replication submodule is configured to generate a reverse replication task based on the synchronization completion snapshot point. The reverse replication task is used to copy the incremental data of the slave server cloud disk from the synchronization completion snapshot point to the current moment to the master server cloud disk.

[0159] The above is a schematic diagram of the disaster recovery device configured on the slave server in this embodiment. It should be noted that the technical solution of the disaster recovery device and the technical solution of the disaster recovery method described above are based on the same concept. For details not described in detail in the technical solution of the disaster recovery device, please refer to the description of the technical solution of the disaster recovery method described above.

[0160] The present disclosure also provides an embodiment of a disaster recovery system. FIG1 is a block diagram of a disaster recovery system provided by an embodiment of the present disclosure, wherein the disaster recovery system includes: a master server 102 applying the disaster recovery method described in the embodiment of the present disclosure and a slave server 104 applying the disaster recovery method described in the embodiment of the present disclosure.

[0161] In one or more embodiments, the master server is further provided with at least one backup master server, and the slave server is further provided with at least one backup slave server.

[0162] For example, based on the bilateral architecture of the disaster recovery method provided in the embodiments of the present disclosure, it is also possible to combine the characteristics of disaster recovery on the cloud and adopt a three-node deployment within the availability zone, that is, a three-node deployment with one master server and two backup servers, and one slave server and two backup slave servers, thereby further improving the reliability and deployment flexibility of the disaster recovery system. In combination with the implementation of the master-slave bilateral architecture in the disaster recovery system provided in the embodiments of the present disclosure, it is possible to reduce the coupling between the master and the slave, ensure the synchronization of key data between the master and the slave, and reduce the complexity of system implementation.

[0163] Figure 10 shows a block diagram of a computing device 1000 according to one embodiment of the present disclosure. Components of the computing device 1000 include, but are not limited to, a memory 1010 and a processor 1020. The processor 1020 is connected to the memory 1010 via a bus 1030, and a database 1050 is used to store data.

[0164] The computing device 1000 also includes an access device 1040 that enables the computing device 1000 to communicate via one or more networks 1060. Examples of such networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 1040 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, or a near field communication (NFC) interface.

[0165] In one embodiment of the present disclosure, the aforementioned components of the computing device 1000 and other components not shown in FIG10 may also be connected to each other, for example, via a bus. It should be understood that the computing device structure block diagram shown in FIG10 is for illustrative purposes only and does not limit the scope of the present disclosure. Those skilled in the art may add or replace other components as needed.

[0166] Computing device 1000 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, personal digital assistant, laptop computer, notebook computer, netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or personal computer (PC). Computing device 1000 may also be a mobile or stationary server.

[0167] The processor 1020 is configured to execute the following computer-executable instructions, which implement the steps of the above-mentioned disaster recovery method when executed by the processor.

[0168] The above is a schematic solution of a computing device of this embodiment. It should be noted that the technical solution of the computing device and the technical solution of the above-mentioned disaster recovery method are of the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-mentioned disaster recovery method.

[0169] An embodiment of the present disclosure further provides a computer-readable storage medium storing computer-executable instructions, which implement the steps of the above-mentioned disaster recovery method when executed by a processor.

[0170] The above is a schematic solution of a computer-readable storage medium of this embodiment. It should be noted that the technical solution of the storage medium and the technical solution of the above-mentioned disaster recovery method are of the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-mentioned disaster recovery method.

[0171] An embodiment of the present disclosure further provides a computer program product, including a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned disaster recovery method.

[0172] The above is an illustrative solution of a computer program of this embodiment. It should be noted that the technical solution of the computer program and the technical solution of the above-mentioned disaster recovery method are of the same concept. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the above-mentioned disaster recovery method.

[0173] The foregoing description describes specific embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0174] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0175] It should be noted that for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present disclosure are not limited by the order of the actions described, because according to the embodiments of the present disclosure, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of the present disclosure.

[0176] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0177] The preferred embodiments of the present disclosure disclosed above are only used to help illustrate the present disclosure. The optional embodiments do not describe all details in detail, nor do they limit the invention to only the specific embodiments described. Obviously, many modifications and variations can be made based on the content of the embodiments of the present disclosure. The present disclosure selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of the present disclosure, so that those skilled in the art can better understand and utilize the present disclosure. The present disclosure is limited only by the claims and their full scope and equivalents.

Claims

1. A disaster recovery method, applied to a primary server, comprising: Acquire replication pair metadata and a replication plan corresponding to the replication pair metadata, wherein the replication pair metadata includes corresponding relationship information between a master server cloud disk and a slave server cloud disk, and the slave server is used to provide access services when a failure occurs on the master server; Generate a replication task according to the replication pair metadata and the replication plan, wherein the replication task is used to replicate the data of the master server cloud disk to the slave server cloud disk, so that the data stored in the slave server cloud disk is consistent with the data stored in the master server cloud disk; In the case where the replication task is an asynchronous replication task, the replication task is sent to the slave server through the asynchronous replication task interface of the slave server, so that the slave server executes the replication task according to the process of the asynchronous replication task; In the case where the replication task is a synchronous replication task, the replication task is sent to the slave server through the synchronous replication task interface of the slave server, so that the slave server executes the replication task according to the process of the synchronous replication task; The replication pair metadata further includes: consistency point information corresponding to the previous round of asynchronous replication tasks, and the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the primary server cloud disk; The method further comprises: When the primary server cloud disk recovers from the failure, the storage data of the primary server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks according to the consistency point information; The incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the server-side cloud disk.

2. The method according to claim 1, further comprising: Receiving a management operation of the user on the metadata of the replica pair, wherein the management operation includes any one or more operations of a create operation, a delete operation, a query operation, a modify operation, and a stop operation; Execute the management operation; The management operation is performed on the slave server through remote calling.

3. The method according to claim 1, wherein generating a replication task according to the replication pair metadata and the replication plan comprises: According to the replication plan corresponding to the replication pair metadata as an asynchronous replication plan, a synchronization start snapshot point of the previous round of asynchronous replication tasks on the primary server cloud disk is determined; Generate a current asynchronous replication task, the current asynchronous replication task is used to copy the incremental data of the master server cloud disk from the synchronization start snapshot point of the previous round of asynchronous replication tasks to the synchronization start snapshot point of the current asynchronous replication task to the slave server cloud disk.

4. The method according to claim 1, further comprising: The synchronization information of the slave server is obtained by polling through the status query interface of the slave server, and the synchronization information at least includes: the status information returned by the slave server for the replication pair.

5. The method according to any one of claims 1 to 4, wherein the replication pair metadata is stored in a pluggable metadata storage module.

6. A disaster recovery method, applied to a slave server, comprising: If an asynchronous replication task sent by the master server is received through the asynchronous replication task interface of the slave server, Execute the asynchronous replication task according to the asynchronous replication task process; If a synchronous replication task sent by the master server is received through the synchronous replication task interface of the slave server, the synchronous replication task is executed according to the synchronous replication task process, and the asynchronous replication task and the synchronous replication task are used to copy the data of the master server cloud disk to the slave server cloud disk, so that the data stored in the slave server cloud disk is consistent with the data stored in the master server cloud disk; When the main server cloud disk fails, the secondary server cloud disk replaces the main server cloud disk to provide access services; After the master server recovers from the failure, the replication pair metadata is obtained, the replication pair metadata includes: the corresponding relationship information between the master server cloud disk and the slave server cloud disk, the replication pair metadata also includes: the consistency point information corresponding to the previous round of asynchronous replication tasks, the consistency point information at least includes: the synchronization start snapshot point of the previous round of asynchronous replication tasks on the master server cloud disk, so that when the master server cloud disk recovers from the failure, according to the consistency point information, the storage data of the master server cloud disk is rolled back to the synchronization start snapshot point of the previous round of asynchronous replication tasks, and the incremental data after the synchronization start snapshot point of the previous round of asynchronous replication tasks is obtained from the slave server cloud disk; Based on the replication pair metadata, a reverse replication task is generated and executed, wherein the reverse replication task is used to replicate the incremental data of the slave server cloud disk after disaster recovery is started to the master server cloud disk, so that the data stored on the master server cloud disk is consistent with the data stored on the slave server cloud disk.

7. The method according to claim 6, wherein the copying of metadata further comprises: The consistency point information corresponding to the previous round of asynchronous replication tasks, the consistency point information at least includes: the synchronization completion snapshot point of the previous round of asynchronous replication tasks on the slave server cloud disk; The generating and executing the reverse replication task according to the replication pair metadata includes: Determine, according to the replication pair metadata, a synchronization completion snapshot point of the previous round of asynchronous replication tasks on the slave server cloud disk; A reverse replication task is generated according to the synchronization completion snapshot point, and the reverse replication task is used to copy the incremental data of the slave server cloud disk from the synchronization completion snapshot point to the current moment to the master server cloud disk.

8. A disaster recovery system, comprising: A master server applying the disaster recovery method according to any one of claims 1 to 5 and a slave server applying the disaster recovery method according to claim 6 or 7.

9. According to the system of claim 8, the master server is further provided with at least one backup master server, and the slave server is further provided with at least one backup slave server.

10. A computing device comprising: Memory and processor; The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the disaster recovery method described in any one of claims 1 to 7 are implemented.

11. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the steps of the disaster recovery method according to any one of claims 1 to 7.

12. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the steps of the disaster recovery method according to any one of claims 1 to 7 are implemented.

Images