Disaster recovery method and device and related equipment

By using CDC tools and message queue mechanisms, database logs are automatically converted and parsed, enabling efficient disaster recovery between Galera clusters. This solves the problems of complex manual intervention and high resource consumption in existing technologies, and improves the automation level and recovery efficiency of disaster recovery between database clusters.

CN121523968APending Publication Date: 2026-02-13NEW H3C TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511535815.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-10-24
Publication Date
2026-02-13

AI Technical Summary

Technical Problem

In the containerized deployment of a synchronous multi-master MySQL cluster based on Galera, how can we achieve efficient disaster recovery between database clusters, especially the automatic recovery of data synchronization after a breakpoint, reducing manual intervention and resource consumption?

Method used

The Change Data Capture (CDC) tool is used, and a publish-subscribe mechanism is configured through a message queue. The first database log generated by the primary database cluster is converted into the second database log and published to the backup database cluster through the message queue. The second functional module parses it into data synchronization commands that can be executed by the backup database cluster, thereby realizing automatic failover and data synchronization.

Benefits of technology

It enables efficient and automated disaster recovery across database clusters, reduces manual intervention, optimizes resource consumption, and improves data recovery efficiency and reliability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121523968A_ABST
    Figure CN121523968A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of data processing, in particular to a disaster recovery method and device and related equipment. The method is applied to a CDC tool, the CDC tool comprises a first function module and a second function module, the first function module obtains a first database log generated by a main database cluster and used for representing changes of service data stored in the main database cluster, and the format of the first database log is a first format; the first function module converts the first database log into a second database log and releases the second database log to a message queue, and the format of the second database log is a second format; and the second function module obtains a second database log from the message queue in a subscription mode, and analyzes the second database log into a data synchronization command executable by the standby database cluster, so that the standby database cluster executes data synchronization with the main database cluster based on the data synchronization command.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a disaster recovery method and device and related equipment. BACKGROUND

[0002] The Galera-based synchronous multi-master MySQL cluster has high availability and strong consistency advantages in containerized deployment (such as a k8s platform). The Galera cluster implements data consistency through multi-node synchronous writing, and implements load balancing, read-write separation and other functions through a proxy component. The Service component based on k8s realizes high availability.

[0003] With the rapid development of the big data industry, data backup can be performed in a multi-node manner within a database cluster. However, cluster-level disaster recovery is also needed between database clusters. Therefore, how to implement disaster recovery between database clusters has become a problem to be solved. SUMMARY

[0004] The present application provides a disaster recovery method and device.

[0005] In a first aspect, the present application provides a disaster recovery method. The method is applied to a change data capture (CDC) tool, the CDC tool includes a first functional module and a second functional module, and the first functional module and the second functional module publish and subscribe to a mechanism through a message queue. The method includes the following steps. The first functional module acquires a first database log generated by a master database cluster, the first database log representing changes in business data stored in the master database cluster, wherein the format of the first database log is a first format. The first functional module converts the first database log into a second database log and publishes the second database log to the message queue, wherein the format of the second database log is a second format. The second functional module acquires the second database log from the message queue in a subscription manner, parses the second database log into a data synchronization command executable by a standby database cluster, and enables the standby database cluster to perform data synchronization with the master database cluster based on the data synchronization command.

[0006] Optionally, the first database log is a binary log, and the second database log is a relay SQL.

[0007] Optionally, the step of converting the first database log into a second database log and publishing the second database log to the message queue includes the following steps. The first database log comprising the first database log representing the change of each piece of business data is converted into a corresponding second database log; The converted second database log representing the change of each piece of business data is respectively published to the message queue.

[0008] Optionally, the step of parsing the second database log into a data synchronization command executable by the standby database cluster comprises: The Relay SQL is parsed into an SQL statement executable by the standby database cluster.

[0009] Optionally, the master database cluster and the standby database cluster provide business services to the outside through proxy components; the proxy component of the master database cluster converts the business data change event into a first database log after detecting the business data change event of the master database cluster; the first function module obtains the first database log representing the change of the business data stored in the master database cluster from each proxy component of the master database cluster.

[0010] Optionally, the second function module establishes a long connection with any proxy component of the standby database cluster, and monitors the survival state of the long connection through a heartbeat mechanism; if the long connection between the current proxy component is disconnected, a long connection is established with other proxy components to realize automatic fault switching.

[0011] Optionally, the method further comprises: The second function module sends the data synchronization command executable by the standby database cluster to the standby database cluster through the long connection established between the proxy component of the standby database cluster.

[0012] In a second aspect, the present application provides a disaster recovery device, the device is applied to a change data capture (CDC) tool, the CDC tool comprises a first function module and a second function module, the first function module and the second function module publish and subscribe mechanism through a message queue configuration; the device comprises: A first obtaining unit is configured to obtain a first database log generated by a master database cluster, the first database log representing the change of business data stored in the master database cluster, wherein the format of the first database log is a first format; A conversion unit is configured to convert the first database log into a second database log, and publish the second database log to the message queue, wherein the format of the second database log is a second format; A second obtaining unit is configured to obtain the second database log from the message queue in a subscription manner; The analysis unit is configured to analyze the second database log into a data synchronization command executable by the standby database cluster, so that the standby database cluster performs data synchronization with the master database cluster based on the data synchronization command.

[0013] Optionally, the first database log is a Binary log, and the second database log is a Relay SQL.

[0014] Optionally, when the first database log is converted into the second database log and the second database log is published to the message queue, the conversion unit is specifically configured to: convert the first database log representing the change of each piece of business data into a corresponding second database log; publish the converted second database log representing the change of each piece of business data to the message queue.

[0015] Optionally, when the second database log is analyzed into a data synchronization command executable by the standby database cluster, the analysis unit is specifically configured to: analyze the Relay SQL into an SQL statement executable by the standby database cluster.

[0016] Optionally, the master database cluster and the standby database cluster provide a business service to the outside through a proxy component; the proxy component of the master database cluster converts a business data change event into a first database log after detecting the business data change event; and the first acquisition unit is configured to acquire the first database log representing the change of business data stored in the master database cluster from each proxy component of the master database cluster.

[0017] Optionally, the second functional module establishes a long connection with any proxy component of the standby database cluster, and monitors the survival state of the long connection through a heartbeat mechanism; if the long connection between the current proxy component is disconnected, the long connection with other proxy components is established to realize automatic fault switching.

[0018] Optionally, the apparatus further includes: The sending unit is configured to send the data synchronization command executable by the standby database cluster to the standby database cluster through the long connection established with the proxy component of the standby database cluster.

[0019] In a third aspect, an embodiment of the present application provides a disaster recovery apparatus, which includes: a memory configured to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method as described in any one of the first aspects above, according to the obtained program instructions.

[0020] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the steps of the method as described in any of the first aspects above.

[0021] In summary, the disaster recovery method provided in this application is applied to a Change Data Capture (CDC) tool. The CDC tool includes a first functional module and a second functional module, which are configured with a publish-subscribe mechanism via a message queue. The method includes: the first functional module acquiring a first database log generated by the primary database cluster to characterize changes in business data stored within the primary database cluster, wherein the format of the first database log is a first format; the first functional module converting the first database log into a second database log and publishing the second database log to the message queue, wherein the format of the second database log is a second format; the second functional module acquiring the second database log from the message queue through a subscription method and parsing the second database log into a data synchronization command executable by the backup database cluster, so that the backup database cluster performs data synchronization with the primary database cluster based on the data synchronization command. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments of this application or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this application.

[0023] Figure 1 This is a schematic diagram of a synchronous multi-master MySQL cluster based on Galera; Figure 2 This is a schematic diagram of a primary / standby cluster disaster recovery process; Figure 3 A detailed flowchart of a disaster recovery method provided in an embodiment of this application; Figure 4 A schematic diagram of a disaster recovery process provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a disaster recovery device provided in an embodiment of this application; Figure 6A hardware architecture schematic diagram of a disaster recovery device is provided for an embodiment of the present application. DETAILED DESCRIPTION

[0024] The terminology used in the present application is merely for the purpose of describing particular embodiments and is not intended to be limiting of the present application. As used in the present application and the claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0025] It should be understood that although the terms first, second, third, etc. can be used herein to describe various information, the information should not be limited to these terms. These terms are only used to distinguish one piece of information from another. For example, a first information can also be termed a second information, and similarly, a second information can also be termed a first information without departing from the scope of the present application. Depending on the context, the word "if" can be interpreted to mean "when" or "in response to determining" depending on the context.

[0026] At present, the Galera-based synchronous multi-master MySQL cluster has the advantages of high availability and strong consistency in containerized deployment (such as k8s platform), as shown in Figure 1 The Galera cluster achieves data consistency through multi-node synchronous writing, and achieves load balancing, read-write separation and other functions through a proxy component, and achieves high availability through the Service component of k8s.

[0027] In practical applications, based on the cluster-level disaster recovery requirement, two Galera clusters are needed to form a disaster recovery system. The current cluster-level disaster recovery method is to find one (fixed) node in the disaster recovery master-standby cluster, and establish a MySQL Replication relationship. For example, refer to Figure 2As shown in the figure, it is a schematic diagram of a primary-standby cluster disaster recovery process, POD-mysql-3 in the disaster recovery primary cluster and POD-mysql-1 in the disaster recovery standby cluster. In this way, the data changes of the disaster recovery primary cluster are synchronized to each node in the cluster through the replication provided by Galera; these changes are synchronized to the disaster recovery standby cluster through master-slave replication. It can be seen that this scheme relies on environmental reliability, and after the breakpoint, it cannot automatically continue synchronization and needs manual intervention to repair. When manually intervening in repair, if the node originally acting as a data provider (POD-mysql-3 in the disaster recovery primary cluster in the above figure) continues to be unavailable, if you want to use POD-mysql-1 or POD-mysql-2 nodes in the disaster recovery primary cluster as a new data provider, you need to clean up all the data in the data receiver (POD-mysql-1 in the disaster recovery standby cluster in the above figure), then manually export, copy and import the data of the new data provider (such as POD-mysql-1 in the disaster recovery primary cluster) in the standby cluster, and then reconfigure the synchronization starting point to restore.

[0028] It should be noted that because the data of each node in the cluster is synchronized, cleaning up the data of POD-mysql-1 in the disaster recovery standby cluster will also clean up the data of the other two nodes, and the synchronization relationship needs to be re-established. It involves not only the synchronization of data between clusters, but also the synchronization of data between nodes in the standby cluster. Both of them need to consume the network bandwidth between clusters and within clusters. If the data volume is large, the recovery efficiency and the resource occupation need to be evaluated to see if they meet the requirements.

[0029] The application provides a disaster recovery method based on a Galera-synchronized multi-master MySQL containerized cluster.

[0030] For example, refer to Figure 3 As shown in the figure, it is a detailed flowchart of a disaster recovery method provided by an embodiment of the application. The method is applied to a change data capture (CDC) tool, the CDC tool includes a first function module and a second function module, and the first function module and the second function module publish and subscribe mechanism through a message queue; the method includes the following steps: Step 300: The first function module acquires the first database log generated by the primary database cluster for representing the changes of the business data stored in the primary database cluster, wherein the format of the first database log is a first format.

[0031] In the embodiment of the present application, the CDC tool comprises a first function module and a second function module, and in actual application, the CDC tool can be a third-party device independent of the disaster recovery system; alternatively, the first function module of the CDC tool can run in the primary database cluster, the second function module can run in the standby database cluster, and the message queue can run in the third-party device, the primary database cluster or the standby database cluster, which is not limited herein in the embodiment of the present application.

[0032] In the embodiment of the present application, the primary database cluster and the standby database cluster provide business services to the outside through proxy components; the proxy component of the primary database cluster converts the business data change event into a first database log after detecting the business data change event of the primary database cluster; and the first function module acquires the first database log representing the change of the business data stored in the primary database cluster from each proxy component of the primary database cluster.

[0033] That is, the primary database cluster provides business services to the outside with the support of the proxy component, and when the business data of the primary database cluster changes, the proxy component can acquire the business data change event and convert the business data change event into a first database log.

[0034] It should be noted that in the embodiment of the present application, the first database log is a Binary log, and the format of the first database log is a binary format.

[0035] In the embodiment of the present application, the first function module can acquire the first database log in the following manner: the proxy component converts the business data change event into the corresponding first database log, and then actively pushes the first database log to the first function module; or the first function module acquires the newly generated first database log from the proxy component based on a preset period, which is not limited herein in the embodiment of the present application.

[0036] Step 310: The first function module converts the first database log into a second database log, and publishes the second database log to the message queue, wherein the format of the second database log is a second format.

[0037] In the embodiment of the present application, when the first database log is converted into a second database log and the second database log is published to the message queue, a preferred implementation manner is as follows: The first database log representing the change of each piece of business data is converted into a corresponding second database log; The converted second database log representing the change of each piece of business data is published to the message queue respectively.

[0038] That is, assuming that the business data 1 of the master database changes, then the agent component of the master database cluster monitors the business data 1 change event, and converts the business data 1 change event 1 into a first database log 1 in a corresponding first format, the first function module acquires the first database log 1 and converts it into a second database log 1 in a corresponding second format, and publishes the second database log 1 to the message queue. Wherein, the first database log 1 and the second database log 1 can both represent the change of the business data 1.

[0039] In the embodiment of the application, the second database log is Relay SQL.

[0040] Step 320: The second function module acquires the second database log from the message queue by subscription, and parses the second database log into a data synchronization command executable by the standby database cluster, so that the standby database cluster performs data synchronization with the master database cluster based on the data synchronization command.

[0041] In the embodiment of the application, the second function module subscribes to the message queue, and when a new second database log is published in the message queue, the second function module acquires the second database log from the message queue and parses the second database log into a data synchronization instruction executable by the standby database cluster.

[0042] In actual application, the second function module establishes a long connection with any agent component of the standby database cluster, and monitors the survival state of the long connection by a heartbeat mechanism at regular intervals; if the long connection between the current agent component is disconnected, a long connection is established with other agent components to realize automatic failover.

[0043] Further, in the embodiment of the application, the second function module sends the data synchronization command executable by the standby database cluster to the standby database cluster through the long connection established between the agent component of the standby database cluster.

[0044] That is, after the second function module converts the second database log acquired from the message queue into a data synchronization command executable by the standby database cluster, the second function module sends the data synchronization command to the agent component of the standby database cluster through the long connection established with any agent component of the standby database cluster, and the agent component executes the data synchronization command to complete the data synchronization between the master database cluster and the standby database cluster.

[0045] The disaster recovery process between the master database cluster and the standby database cluster provided by the embodiment of the application will be described in detail in combination with a specific application scenario. For example, refer to Figure 4As shown, a disaster recovery process schematic diagram provided by the embodiment of the application is shown, wherein, The synchronization of the Binary log implementation data of MySQL between the disaster recovery master-slave cluster is taken as an example for description, and the database cluster needs to ensure the completion of the following three configurations: starting the Binary log record; enabling the log_slave_updates, so that the slave server writes the received update operation into its own binary log; and starting the GTID mode, so that the CDC tool provided in the scheme can replay according to the GTID in the disaster recovery backup cluster.

[0046] The CDC tool includes a first function module, The proxy component of the master and backup database cluster: needs to support the function of converting the change event of the Galera cluster into a standard MySQL binlog format file (the first database log); The Binary log analysis module included in the first function module: can actively read and analyze the Binary log from each proxy component of the disaster recovery master cluster, extract the GTID and transaction data to form the Relay SQL, and forward the Relay SQL to the message queue sink module; The message queue sink module included in the first function module: can be connected to the message queue (message queue) such as kafka, and receive the Relay SQL parsed by the Binary log analysis module; in the embodiment of the application, the message queue is used, instead of directly applying the parsed Relay SQL to the backup cluster, which can decouple the master and backup clusters, avoid the performance difference between the master and backup clusters affecting the data synchronization efficiency, and also avoid the sudden failure of the CDC tool itself, resulting in the loss of Relay SQL that has not been applied to the backup cluster; The message queue access module included in the second function module: can be connected to the message queue such as kafka, so that the Relay SQL analysis module can consume the Relay SQL message from the message queue; The Relay SQL analysis module included in the second function module: sequentially reads the Relay SQL message from the message queue, and removes the duplicate messages, then parses the Relay SQL into executable SQL, and executes the SQL through the database connection module connected to the disaster recovery slave cluster.

[0047] The second function module comprises a database interface module: the module can establish a long connection with any proxy component of a MySQL through a MySQL external service, and monitor the survival state of the connection through a heartbeat mechanism. If the connection is detected to be disconnected, the module attempts to establish a connection with other endpoint nodes (i.e., proxy components) of the MySQL external service, to ensure automatic live detection and automatic fault switching.

[0048] Based on the same inventive concept as the above-mentioned embodiments, an exemplary structure of a disaster recovery device provided by the embodiments of the present application is shown in FIG. 1, which is applied to a change data capture (CDC) tool. The CDC tool comprises a first function module and a second function module, and the first function module and the second function module publish and subscribe through a message queue configuration mechanism. The device comprises: Figure 5 A first obtaining unit 50 is configured to obtain a first database log generated by a master database cluster, the first database log being used to represent changes in business data stored in the master database cluster, wherein the first database log is in a first format. A conversion unit 51 is configured to convert the first database log into a second database log, and publish the second database log to the message queue, wherein the second database log is in a second format. A second obtaining unit 52 is configured to obtain the second database log from the message queue in a subscription manner. An analysis unit 53 is configured to analyze the second database log into a data synchronization command executable by a standby database cluster, so that the standby database cluster performs data synchronization with the master database cluster based on the data synchronization command.

[0049] Optionally, the first database log is a binary log, and the second database log is a relay SQL.

[0050] Optionally, when the first database log is converted into the second database log and the second database log is published to the message queue, the conversion unit 51 is specifically configured to: convert the first database log included in the first database log, which respectively represents each change in business data, into a corresponding second database log; publish the converted second database logs representing each change in business data to the message queue respectively.

[0051] Optionally, when the second database log is analyzed into a data synchronization command executable by the standby database cluster, the analysis unit 53 is specifically configured to: ​The Relay SQL is parsed into an SQL statement executable by the standby database cluster.

[0052] Optionally, the primary database cluster and the standby database cluster provide service externally through proxy components; the proxy component of the primary database cluster converts the service data change event into a first database log after detecting the service data change event of the primary database cluster; and the first obtaining unit is configured to obtain the first database log representing the change of the service data stored in the primary database cluster from each proxy component of the primary database cluster.

[0053] Optionally, the second function module establishes a long connection with any proxy component of the standby database cluster, and monitors the survival state of the long connection through a heartbeat mechanism; if the long connection between the current proxy component is disconnected, the long connection is established with other proxy components to realize automatic switching of faults.

[0054] Optionally, the apparatus further comprises: The sending unit is configured to send the data synchronization command executable by the standby database cluster to the standby database cluster through the long connection established with the proxy component of the standby database cluster.

[0055] The above units can be one or more integrated circuits configured to implement the above method, for example, one or more application specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs), etc. For another example, when the above unit is implemented in the form of a processing element scheduling program code, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, the units can be integrated together to implement in the form of a system on a chip (SOC).

[0056] Further, the disaster recovery apparatus provided by the embodiments of the present application is from the hardware layer, and a hardware architecture diagram of the disaster recovery apparatus can be seen from Figure 6 As shown in the figure, the disaster recovery apparatus can include a memory 60 and a processor 61, The memory 60 is configured to store program instructions; the processor 61 invokes the program instructions stored in the memory 60 to execute the above-described method embodiments according to the obtained program instructions. The specific implementation manners and technical effects are similar, and thus are not described herein again.

[0057] Optionally, the present application also provides a disaster recovery device, comprising at least one processing element (or chip) configured to execute the above-described method embodiments.

[0058] Optionally, the present application also provides a program product, for example, a computer readable storage medium, which stores computer executable instructions for causing the computer to execute the above-described method embodiments.

[0059] Here, the machine readable storage medium can be any electronic, magnetic, optical, or other physical storage apparatus, and can contain or store information such as executable instructions, data, etc. For example, the machine readable storage medium can be a RAM (Random Access Memory), a volatile memory, a non-volatile memory, a flash memory, a storage drive (such as a hard drive), a solid state drive, any type of storage disk (such as an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.

[0060] The system, apparatus, module or unit illustrated in the above-described embodiments can be specifically implemented by a computer chip or entity, or by a product with certain functions. A typical implementation device is a computer, and the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an e-mail device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0061] For the convenience of description, the above-described apparatus is described in various units according to functions in the description. Of course, the functions of the units can be implemented in the same or multiple software and / or hardware in the implementation of the present application.

[0062] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present application can take the form of a computer program product implemented on one or more computer usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0063] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart or flowsheet block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 one or more flowcharts and / or blocks

[0064] Also, these computer program instructions can be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the Figure 1 one or more flowcharts and / or blocks Figure 1 one or more flowcharts and / or blocks

[0065] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart or flowsheet block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 one or more flowcharts and / or blocks

[0066] The above description is only preferred embodiments of the present application and is not used to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A disaster recovery method, characterized in that, The method is applied to a Change Data Capture (CDC) tool, which includes a first functional module and a second functional module. The first functional module and the second functional module are configured with a publish-subscribe mechanism via a message queue. The method includes: The first functional module obtains a first database log generated by the main database cluster to characterize changes in business data stored within the main database cluster, wherein the format of the first database log is a first format; The first functional module converts the first database log into a second database log and publishes the second database log to the message queue, wherein the format of the second database log is a second format; The second functional module obtains the second database log from the message queue through a subscription method, and parses the second database log into a data synchronization command that can be executed by the backup database cluster, so that the backup database cluster can perform data synchronization with the primary database cluster based on the data synchronization command.

2. The method as described in claim 1, characterized in that, The first database log is a Binary log, and the second database log is a Relay SQL.

3. The method as described in claim 2, characterized in that, The steps of converting the first database log into a second database log and publishing the second database log to the message queue include: The first database log, which represents the changes of each piece of business data, is converted into the corresponding second database log. The transformed second database logs, representing the changes in each business data item, are published to the message queue.

4. The method as described in claim 2, characterized in that, The steps for parsing the second database log into data synchronization commands executable by the backup database cluster include: The Relay SQL is parsed into SQL statements that can be executed by the backup database cluster.

5. The method as described in claim 1, characterized in that, The primary database cluster and the backup database cluster provide business services to the outside world through proxy components; after detecting a business data change event in the primary database cluster, the proxy component of the primary database cluster converts the business data change event into a first database log; the first functional module obtains the first database log, which is used to characterize the changes in business data stored in the primary database cluster, from each proxy component of the primary database cluster.

6. The method as described in claim 5, characterized in that, The second functional module establishes a long connection with any proxy component of the backup database cluster and monitors the liveness of the long connection periodically through a heartbeat mechanism; if the long connection with the current proxy component is detected to be broken, a long connection is established with other proxy components to achieve automatic fault switching.

7. The method as described in claim 6, characterized in that, The method further includes: The second functional module sends the data synchronization commands executable by the backup database cluster to the backup database cluster through a long connection established with the proxy component of the backup database cluster.

8. A disaster recovery device, characterized in that, The apparatus is used in a Change Data Capture (CDC) tool, which includes a first functional module and a second functional module. The first functional module and the second functional module are configured with a publish-subscribe mechanism via a message queue. The apparatus includes: The first acquisition unit is used to acquire a first database log generated by the main database cluster to characterize changes in business data stored within the main database cluster, wherein the format of the first database log is a first format. A conversion unit is used to convert the first database log into a second database log and publish the second database log to the message queue, wherein the format of the second database log is a second format; The second acquisition unit is used to acquire the second database log from the message queue by subscription; The parsing unit is used to parse the second database log into a data synchronization command that can be executed by the backup database cluster, so that the backup database cluster can perform data synchronization with the primary database cluster based on the data synchronization command.

9. A disaster recovery device, characterized in that, The disaster recovery device includes: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method as described in any one of claims 1-7 according to the obtained program instructions.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing the computer to perform the steps of the method as described in any one of claims 1-7.