Distributed database system disaster recovery method and system based on cross-cluster data synchronization

Abstract

The present application relates to the field of data synchronization technology, and in particular to a method and system for disaster recovery of a distributed database system based on cross-cluster data synchronization. The method comprises: the target database cluster pulls source cluster metadata from the source database cluster based on a synchronization cycle, the target database cluster is any slave database cluster, and the source cluster metadata includes the full data information and full node information of the source database cluster; the target database cluster compares the target cluster metadata of the target database cluster with the source cluster metadata to determine differential data; the target database cluster determines a number of transactions based on the differential data, and executes the data version synchronization task corresponding to each transaction, and the data version synchronization task is used to synchronize data from the source database cluster. The present application can achieve efficient and flexible cross-cluster data synchronization.

Description

Technical Field

[0001] The present application relates to the technical field of data synchronization, and in particular to a distributed database system disaster recovery method and system based on cross-cluster data synchronization. Background Art

[0002] In modern distributed database systems, cross-region data synchronization is a key technology for achieving high availability, disaster recovery, and load balancing. As business scale and data volumes grow, the need for cross-region data synchronization is becoming increasingly common. For example, global enterprises need to synchronize data between database clusters in different regions to ensure that users can access consistent data regardless of their location. Furthermore, cross-region data synchronization improves the system's disaster recovery capabilities. If a cluster in one region fails, clusters in other regions can take over services, ensuring business continuity.

[0003] Data synchronization methods can be divided based on different perspectives, including: push and pull, synchronous replication and asynchronous replication, homogeneous replication and heterogeneous replication, logical replication and physical replication, master-slave replication and multi-master replication and masterless replication, point-to-point replication and broker replication, whether it is based on log replication, and dynamic member changes.

[0004] Currently, consensus algorithms such as Paxos / Raft are widely used in the industry to achieve cross-regional data synchronization. These algorithms partition data by building replication groups and assigning them to different Paxos / Raft instances. Each instance is responsible for state machine replication of a data partition. Each node in a Paxos / Raft instance resides in a distributed database system in a specific region. Each Paxos / Raft instance elects a leader node. Write requests are processed by the leader node and must be replicated to a majority of nodes before they are returned, ensuring data consistency and reliability. Paxos / Raft also supports dynamic membership changes, allowing cluster members to be added or removed at runtime to adapt to changing business needs.

[0005] However, cross-region data synchronization technology based on Paxos / Raft has some significant shortcomings. First, engineering implementation is complex, especially in analytical distributed databases, where the lack of mechanisms similar to redolog and binlog makes modification and implementation challenging. Second, this semi-synchronous replication approach significantly impacts write latency to the source cluster. Especially in cross-region scenarios, network latency can significantly increase write response time, making it difficult to meet high-throughput write requirements. Furthermore, Paxos / Raft requires the generation of logs and snapshots, resulting in redundant data writes and additional storage and computing overhead. Furthermore, because the leader node may not be located on the source cluster, write requests must be forwarded across regions, further increasing latency and overhead. Another issue is that Paxos / Raft-based replication cannot guarantee snapshot consistency. Because each replication group is independently replicated, the data version on the target cluster may not exactly correspond to a historical version on the source cluster, which can cause problems in scenarios requiring high consistency. In addition, Paxos / Raft requires an odd number of clusters participating in replication, and a majority of clusters must be alive to work properly. This results in a minimum deployment specification of three clusters, increasing deployment costs and complexity. In some scenarios, two clusters may be sufficient.

[0006] In summary, consensus algorithms such as Paxos and Raft have obvious shortcomings in cross-region data synchronization, such as engineering implementation complexity, write latency, data redundancy, snapshot consistency, and deployment flexibility, making it difficult to meet the actual needs of cross-region data synchronization. Summary of the Invention

[0007] In order to solve the problem that existing technologies are difficult to meet the actual needs of cross-regional data synchronization, the present application provides a distributed database system disaster recovery method and system based on cross-cluster data synchronization.

[0008] In the first aspect, the present application provides a distributed database system disaster recovery method based on cross-cluster data synchronization, which adopts the following technical solutions:

[0009] A distributed database system disaster recovery method based on cross-cluster data synchronization, applied to a distributed database system, includes:

[0010] The target database cluster pulls source cluster metadata from the source database cluster based on a synchronization period. The target database cluster is any slave database cluster. The source cluster metadata includes full data information and full node information of the source database cluster.

[0011] The target database cluster compares the target cluster metadata of the target database cluster with the source cluster metadata to determine difference data;

[0012] The target database cluster determines a number of transactions based on the differential data, and executes a data version synchronization task corresponding to each transaction, where the data version synchronization task is used to synchronize data from the source database cluster.

[0013] By adopting the above technical solution, the target database cluster regularly pulls full metadata, which can fully grasp the status of the source database cluster and ensure the timeliness and accuracy of data synchronization; by comparing metadata to determine differential data, the resource waste caused by full synchronization is avoided, and the synchronization efficiency is significantly improved; based on differential data, transactions are divided and data version synchronization tasks are executed, ensuring the atomicity and consistency of data synchronization, while supporting concurrent execution, further improving synchronization performance.

[0014] In a preferred example, the present application may be further configured as follows: the target database cluster determines a number of transactions based on the difference data, including:

[0015] The target database cluster determines whether a consistency range input by the user is received, where the consistency range includes any one of: table level, database level, and cluster level;

[0016] If the target database cluster receives the consistency range input by the user, determining a number of transactions based on the consistency range and the difference data;

[0017] If the target database cluster does not receive the consistency range input by the user, a number of transactions are determined based on a default consistency range and the difference data.

[0018] By adopting the above technical solution, users can customize the consistency range (such as table level, database level, cluster level), and flexibly adjust the synchronization granularity according to different business needs, which not only meets the scenarios with high consistency requirements, but also avoids the performance overhead caused by excessive synchronization; when the user does not specify the consistency range, the system automatically adopts the default consistency range, ensuring the ease of operation and system stability; dividing transactions based on consistency ranges allows synchronization tasks to be executed in a targeted manner, which not only improves synchronization efficiency but also reduces resource waste, optimizes the division and execution of synchronization tasks, significantly improves the performance and reliability of data synchronization, and provides distributed database systems with efficient and flexible cross-cluster data synchronization capabilities.

[0019] In a preferred example, the present application may be further configured as follows: the difference data includes: tables or partitions in which the target cluster metadata has missing or outdated data versions compared to the source cluster metadata;

[0020] When the target database cluster receives the consistency range input by the user, determining a number of transactions based on the consistency range and the difference data includes:

[0021] The consistency range input by the user is used as the target level, and the difference data belonging to the same target level in the difference data are divided into the same transaction, thereby obtaining a plurality of transactions formed by the difference data.

[0022] By adopting the above technical solution and dividing transactions according to the consistency range, the system can accurately match the granularity of synchronization tasks with business needs, which not only meets the scenarios with high consistency requirements but also avoids unnecessary synchronization overhead; dividing the differential data of the same target level into the same transaction ensures the logical consistency and execution efficiency of the synchronization tasks, while supporting concurrent execution, further improving synchronization performance.

[0023] In a preferred example, the present application may be further configured as follows: executing the data version synchronization task corresponding to each transaction includes:

[0024] The target database cluster sends a data synchronization request to the source database cluster based on the data version synchronization task corresponding to each transaction;

[0025] After receiving the data synchronization request, the source database cluster suspends recycling of old data versions;

[0026] After completing the data version synchronization task corresponding to each transaction, the target database cluster submits a transaction completion notification to the source database cluster;

[0027] After receiving the transaction completion notification, the source database cluster starts recycling the old data version.

[0028] By adopting the above technical solution, the recycling of old data versions is suspended, and the source database cluster can retain the data versions required by the target database cluster, avoiding synchronization failures caused by premature recycling of data versions, thereby improving the reliability of data synchronization; after completing the synchronization task, the target database cluster submits a transaction completion notification to the source database cluster, ensuring the atomicity and consistency of the synchronization process and avoiding the problem of partial synchronization success and partial failure; after receiving the transaction completion notification, the source database cluster resumes recycling old data versions, optimizing the utilization of storage resources.

[0029] In a preferred example, the present application may be further configured as follows: the method further includes:

[0030] When the source database cluster is unavailable, selecting an available slave database cluster as a new source database cluster to complete failover;

[0031] The new source database cluster sends an on-call message to each slave database cluster;

[0032] After receiving the taking office message, each slave database cluster synchronizes data with the new source database cluster based on the synchronization period.

[0033] By adopting the above technical solution, the new source database cluster is quickly selected and the taking-over message is sent. The system can quickly restore service when the main cluster fails, minimize business interruption time, and improve the high availability of the system; the new source database cluster and other slave database clusters continue to synchronize data based on the synchronization cycle, ensuring data consistency and integrity, and avoiding data loss or inconsistency problems; the system can quickly resume normal operation after failover, and at the same time optimize the efficiency and reliability of data synchronization by dynamically adjusting the synchronization strategy.

[0034] In a preferred example, the present application may be further configured as follows: synchronizing data between the target database cluster and the new source database cluster includes:

[0035] The target database cluster pulls new source cluster metadata from the new source database based on the synchronization period, and compares the new source cluster metadata with the target cluster metadata to obtain new difference data;

[0036] When the data version of the target cluster metadata in the new differential data is higher than that of the new source cluster metadata, the data in the target cluster metadata with a data version higher than that of the new source cluster metadata is deleted, and the deleted data is synchronized again from the new source cluster metadata.

[0037] By adopting the above technical solution, by comparing the target cluster metadata with the new source cluster metadata, the difference in data versions can be accurately identified, ensuring the accuracy and efficiency of synchronization; when the data version of the target cluster metadata is higher than the new source cluster metadata, these higher-version data are deleted and re-synchronized from the new source database cluster, avoiding data conflicts or errors caused by inconsistent data versions, thereby ensuring data consistency.

[0038] In a preferred example, the present application may be further configured as follows: after completing the failover, the method further includes:

[0039] The new source database cluster queries the transaction records synchronized from the source database cluster, and determines the latest transaction record from the transaction records;

[0040] The application rewrites the data lost during the failover process to the source database cluster based on the latest transaction record.

[0041] By adopting the above technical solution, querying transaction records and determining the latest transaction records can accurately locate the scope of lost data and ensure the accuracy and efficiency of data recovery; the application rewrites the lost data based on the latest transaction records, minimizing the impact of data loss while ensuring data consistency and integrity; significantly improving the data recovery capability and business continuity of the distributed database system after failover.

[0042] In a preferred example, the present application may be further configured as follows: the synchronization period is not greater than the recovery point objective, and the synchronization period is not greater than the duration for which the application retains data.

[0043] By adopting the above technical solution, the synchronization period is no longer than the recovery point objective, and data synchronization can be completed within the maximum allowable data loss range, minimizing the risk of data loss. The synchronization period is no longer than the application's data retention period, ensuring that the application can make up for the lost part based on the locally retained data after failover, further enhancing the data recovery capability.

[0044] In a second aspect, the present application provides a distributed database system, which adopts the following technical solutions:

[0045] A distributed database system, comprising: a source database cluster, multiple slave database clusters, and an application; any one of the multiple slave database clusters serves as a target database cluster to execute the distributed database system disaster recovery method based on cross-cluster data synchronization as described in any one of the first aspects;

[0046] The application is used to access the source database cluster;

[0047] The source database cluster is configured to provide corresponding services based on access by the application;

[0048] Each slave database is used to synchronize data of the source database cluster based on a synchronization period.

[0049] In summary, this application has the following beneficial technical effects:

[0050] In this application, the target database cluster regularly pulls full metadata, which can fully grasp the status of the source database cluster and ensure the timeliness and accuracy of data synchronization; by comparing metadata to determine differential data, the resource waste caused by full synchronization is avoided, and the synchronization efficiency is significantly improved; based on differential data, transactions are divided and data version synchronization tasks are executed, ensuring the atomicity and consistency of data synchronization, while supporting concurrent execution, further improving synchronization performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1This is a flow chart of a distributed database system disaster recovery method based on cross-cluster data synchronization provided by an embodiment of the present application;

[0052] Figure 2 This is a flowchart of performing data synchronization provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] The following is combined with Figure 1 -Attached Figure 2 This application is described in further detail.

[0054] This specific embodiment is merely an explanation of the present application and is not a limitation of the present application. After reading this specification, those skilled in the art may make non-creative modifications to the present embodiment as needed, but as long as they are within the scope of the claims of the present application, they are protected by the patent law.

[0055] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0056] In this document, the term "and / or" simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document, unless otherwise specified, generally indicates an "or" relationship between the related objects.

[0057] It should be noted that in the optional embodiments of the present application, the object information and other related data involved, when the embodiments in the present application are applied to specific products or technologies, need to obtain the permission or consent of the object, and the collection, use and processing of the relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions. In other words, if the embodiments of the present application involve data related to the object, it needs to be obtained through the authorization and consent of the object, the authorization and consent of the relevant departments, and in compliance with the relevant laws, regulations and standards of the country and region. If personal information is involved in the embodiments, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject needs to be obtained. The embodiments also need to be implemented with the authorization and consent of the object.

[0058] In distributed database systems, cross-region disaster recovery is a key requirement for ensuring high data reliability and business continuity. For users with high data reliability requirements, the system must ensure data protection and rapid service recovery even if an extreme natural disaster causes the entire cluster in a specific region to fail. To achieve this, multiple identical distributed database clusters are typically deployed in different regions. The cluster in one region serves as the primary cluster. Normally, applications access only the primary cluster, which provides the corresponding services. Clusters in other regions serve as slave clusters, backing up data and providing read-only services.

[0059] Data in the master cluster is synchronized to all slave clusters in near real time. This cross-regional data synchronization mechanism ensures that even if a cluster in one region is completely shut down due to a natural disaster, data can still be recovered from clusters in other regions. When a master cluster fails, the system needs to failover and select one of the slave clusters as the new master cluster to continue providing services. The speed of failover is critical, and the time the service is unavailable needs to be minimized. In addition, some recent data may be lost after a failover. The system needs to provide the starting point of data loss so that the application can rewrite the lost data to minimize the impact of data loss.

[0060] However, cross-region data synchronization presents challenges. Network latency between regions is high, and bandwidth may be limited. Therefore, the data synchronization process must minimize the impact on the primary cluster to avoid disrupting normal application usage. To achieve this, systems typically employ asynchronous or semi-synchronous replication, ensuring data reliability while minimizing the impact on write performance. Furthermore, the post-failover data completion mechanism must be efficient and flexible to ensure that applications can quickly restore data consistency.

[0061] To enable cross-regional disaster recovery for distributed databases, embodiments of the present application provide a distributed database system comprising: a source database cluster, multiple slave database clusters, and an application. The application is used to access the source database cluster; the source database cluster is used to provide services based on application access; and each slave database is used to synchronize data from the source database cluster based on a synchronization cycle.

[0062] The present application embodiment provides a distributed database system disaster recovery method based on cross-cluster data synchronization, such as Figure 1 As shown, applied to the above-mentioned distributed database system, the method includes steps S101 to S103, wherein:

[0063] S101: The target database cluster pulls source cluster metadata from the source database cluster based on a synchronization cycle. The target database cluster is any slave database cluster. The source cluster metadata includes full data information and full node information of the source database cluster.

[0064] Specifically, both the source and slave database clusters are distributed database clusters. The source database cluster serves as the master database cluster. Cross-cluster data synchronization uses asynchronous synchronization. Each slave database cluster periodically pulls data from the source database cluster, synchronizing data to allow the slave cluster to catch up with the metadata cluster to the latest data. This example uses any slave database cluster (target database cluster) as an example to illustrate the process of synchronizing data from a single slave database cluster to the source database cluster.

[0065] The synchronization period can be selected based on actual needs, subject to constraints, such as every minute, every ten minutes, every hour, or every day. You can also use cron expressions to precisely specify the time to initiate synchronization, such as initiating synchronization at 2:00 AM every day during low-peak business hours. Constraints on the synchronization period include: the synchronization period must not exceed the Recovery Point Objective (RPO) and must not exceed the application's data retention period.

[0066] See also Figure 2 , which shows a schematic diagram of the data synchronization process provided by this embodiment. The target database cluster synchronizes data from the source database cluster, including: the target database cluster pulls the source cluster metadata from the source database cluster. The source cluster metadata includes the current full data and full node information of the source database cluster, such as the tables contained in the cluster, the partitions contained in each table, the current data version of the partition, and the corresponding nodes stored in the cluster for each partition. The total amount of source cluster metadata is very small, and synchronizing the source cluster metadata synchronizes a snapshot of the full metadata.

[0067] S102: The target database cluster compares the target cluster metadata of the target database cluster with the source cluster metadata to determine difference data.

[0068] See also Figure 2 After the target database cluster obtains the source cluster metadata of the source database cluster, it compares the source cluster metadata with its own target cluster metadata to determine the difference data. The difference data includes tables or partitions in the target cluster metadata that are missing or outdated compared to the source cluster metadata. For tables or partitions with outdated or missing data versions, data synchronization is required.

[0069] S103: The target database cluster determines several transactions based on the differential data, and executes a data version synchronization task corresponding to each transaction. The data version synchronization task is used to synchronize data from the source database cluster.

[0070] Specifically, for the identified discrepancies, several transactions are created corresponding to these discrepancies. Each transaction is responsible for a portion of the tables or partitions with missing or outdated data versions. Different transactions are responsible for different tables or partitions, and there is no overlap between them, so they can be executed concurrently. The target database cluster executes the transactions started in the previous step. Each transaction represents a data version synchronization task. When all transactions are completed, the target database cluster completes synchronization of the missing data from the source database cluster, and data synchronization within that synchronization cycle is complete.

[0071] The target database cluster regularly pulls full metadata, which can fully grasp the status of the source database cluster and ensure the timeliness and accuracy of data synchronization. By comparing metadata to determine differential data, the resource waste caused by full synchronization is avoided, and the synchronization efficiency is significantly improved. Based on differential data, transactions are divided and data version synchronization tasks are executed, which ensures the atomicity and consistency of data synchronization, while supporting concurrent execution, further improving synchronization performance.

[0072] In this embodiment, an asynchronous pull method is used to achieve cross-cluster data synchronization, which can flexibly control the timing of triggering synchronization. The coupling between the clusters participating in the synchronization is low, which does not affect the original write process on the source cluster and has little impact on the source cluster. Compared with a single cluster deployment without cross-cluster synchronization, the access experience of the source cluster is basically the same. The target database cluster first synchronizes a snapshot of the full metadata from the source database cluster, and then compares the synchronized metadata with its own source data. According to the comparison results, the corresponding transaction is started to synchronize the incremental data. When the transaction is committed, the synchronized data is atomically visible to the outside world. This makes the data on the target cluster a snapshot of a historical version on the source cluster after each synchronization is complete, ensuring the consistency of the synchronized snapshot. Utilizing the multi-version data management technology commonly used by database systems, synchronization is performed according to the data version to achieve synchronization of incremental or full data versions. No redo log or binlog is required to achieve synchronization, and the distributed database modification is small and simple to implement. At the same time, the version of the data itself is used to ensure data consistency, making data alignment after failover simple and natural.

[0073] In one possible implementation of the embodiment of the present application, the target database cluster determines several transactions based on the difference data, including:

[0074] The target database cluster determines whether it has received the consistency range entered by the user. The consistency range includes: table level, database level, and cluster level.

[0075] If the target database cluster receives the consistency range input by the user, it determines a number of transactions based on the consistency range and the difference data;

[0076] If the target database cluster does not receive the consistency range input by the user, a number of transactions are determined based on a default consistency range and the difference data.

[0077] In this embodiment, advanced users can be given user input permissions and a consistency range option. If a user wishes to set a consistency range, they can do so. If an advanced user chooses to skip this option, the default consistency range is automatically selected. The default consistency range can be set at the table level. Ordinary users can choose to set the default consistency range directly without specifying the consistency range option.

[0078] This embodiment supports user-defined consistency ranges (such as table level, database level, and cluster level), and can flexibly adjust the synchronization granularity according to different business needs, which not only meets the scenarios with high consistency requirements but also avoids the performance overhead caused by excessive synchronization; when the user does not specify the consistency range, the system automatically adopts the default consistency range, ensuring the ease of operation and system stability; dividing transactions based on consistency ranges allows synchronization tasks to be executed in a targeted manner, which not only improves synchronization efficiency but also reduces resource waste, optimizes the division and execution of synchronization tasks, significantly improves the performance and reliability of data synchronization, and provides distributed database systems with efficient and flexible cross-cluster data synchronization capabilities.

[0079] In a possible implementation of the embodiment of the present application, the difference data includes: tables or partitions in which the target cluster metadata has missing or outdated data versions compared to the source cluster metadata;

[0080] When the target database cluster receives the consistency range input by the user, it determines several transactions based on the consistency range and the difference data, including:

[0081] The consistency range input by the user is used as the target level, and the difference data belonging to the same target level in the difference data are divided into the same transaction, thereby obtaining several transactions formed by the difference data.

[0082] In this embodiment, a number of transactions is determined based on the difference data, and the number of the determined transactions is related to the consistency range.

[0083] In one possible scenario, based on business needs, table-level consistency must be ensured. Figure 2 , a transaction is started for each table to be synchronized in the differential data. In another possible scenario, assuming that business needs require cluster-level consistency, all tables to be synchronized in the differential data should be grouped into the same transaction when determining transactions. In another possible scenario, assuming that business needs require database-level consistency, tables in the differential data belonging to the same database should be grouped into the same transaction when determining transactions.

[0084] Among them, the larger the transaction granularity, the larger the consistency range, but the greater the cost of retrying failure; the smaller the transaction granularity, the smaller the consistency range, and the smaller the cost of retrying failure.

[0085] This embodiment divides transactions according to the consistency range. The system can accurately match the granularity of synchronization tasks with business needs, which not only meets the scenarios with high consistency requirements but also avoids unnecessary synchronization overhead. Differential data at the same target level are divided into the same transaction, ensuring the logical consistency and execution efficiency of synchronization tasks, while supporting concurrent execution, further improving synchronization performance.

[0086] A possible implementation of the embodiment of the present application is to execute the data version synchronization task corresponding to each transaction, including:

[0087] The target database cluster sends a data synchronization request to the source database cluster based on the data version synchronization task corresponding to each transaction;

[0088] After receiving a data synchronization request, the source database cluster suspends recycling of old data versions.

[0089] After completing the data version synchronization task corresponding to each transaction, the target database cluster submits a transaction completion notification to the source database cluster;

[0090] After the source database cluster receives the transaction completion notification, it starts recycling the old data version.

[0091] In this embodiment, the target database cluster synchronizes missing or outdated data versions from the source database cluster. Utilizing the multi-version data organization of the distributed database, each synchronization only incrementally synchronizes the missing or outdated data versions from the last synchronization to the current moment.

[0092] To successfully synchronize missing or outdated data versions, the recovery of old data versions in the source database cluster is delayed until synchronization with the target database cluster is complete. Specifically, while the target database cluster is synchronizing metadata from the source database cluster, the recovery of old data versions in the source database cluster is suspended until the target database cluster has synchronized all missing or outdated data versions with the source database cluster. The source database cluster then resumes recovery of old data versions. After synchronization of missing or outdated data versions for all tables or partitions involved in a transaction is complete, the transaction is committed. After all transactions are committed, synchronization within the current synchronization cycle is complete. Transaction commits make the atomicity of the synchronized data visible to the public, ensuring snapshot consistency.

[0093] This embodiment suspends the recycling of old data versions, allowing the source database cluster to retain the data versions required by the target database cluster, avoiding synchronization failures caused by premature recycling of data versions, thereby improving the reliability of data synchronization; after completing the synchronization task, the target database cluster submits a transaction completion notification to the source database cluster, ensuring the atomicity and consistency of the synchronization process and avoiding the problem of partial synchronization success and partial failure; after receiving the transaction completion notification, the source database cluster resumes recycling old data versions, optimizing the utilization of storage resources.

[0094] In a possible implementation of the embodiment of the present application, the method further includes:

[0095] When the source database cluster becomes unavailable, an available slave database cluster is selected as the new source database cluster to complete the failover.

[0096] The new source database cluster sends a take-off message to each slave database cluster;

[0097] After receiving the inauguration message, each slave database cluster synchronizes data with the new source database cluster based on the synchronization cycle.

[0098] In this embodiment, if a source database cluster participating in data synchronization fails and becomes unavailable, a failover is required. Users or slave database clusters vote to select one of the remaining surviving slave database clusters to become the new primary cluster (i.e., the new source database cluster). The selection of the new source database cluster can be based on the geographic location of the application deployment. The slave database cluster in the region closest to the application is selected to reduce network latency in accessing the primary database cluster.

[0099] After the new source database cluster is selected, it sends a message to the other slave database clusters to inform them of its presence. After receiving the message from the new source database cluster, the other slave database clusters can synchronize their data with the new source database cluster.

[0100] After the failover, the application needs to switch to access the new source database. The application can use DNS access so that after the primary database cluster changes, the DNS points to the address of the new primary cluster, keeping the domain name accessed by the application unchanged.

[0101] This embodiment quickly selects a new source database cluster and sends an appointment message. This allows the system to quickly restore services when the primary cluster fails, minimizing business interruption time and improving the high availability of the system. The new source database cluster continues to synchronize data with other slave database clusters based on the synchronization cycle, ensuring data consistency and integrity and avoiding data loss or inconsistency. The system can quickly resume normal operation after a failover and optimize the efficiency and reliability of data synchronization by dynamically adjusting the synchronization strategy.

[0102] In one possible implementation of the embodiment of the present application, synchronizing data between the target database cluster and the new source database cluster includes:

[0103] The target database cluster pulls the new source cluster metadata from the new source database based on the synchronization cycle, and compares the new source cluster metadata with the target cluster metadata to obtain new difference data;

[0104] When the data version of the target cluster metadata in the new differential data is higher than the new source cluster metadata, the data in the target cluster metadata with a data version higher than the new source cluster metadata is deleted, and the deleted data is synchronized with the new source cluster metadata again.

[0105] In this embodiment, after a failover, the data on the new source database cluster may lag behind that of the other slave database clusters. These slave database clusters need to align their data with the new metadata database cluster. This alignment occurs during data synchronization. If the data version of a table or partition on the target database cluster is older than that of the new source database cluster, the target database cluster deletes the table or partition and resynchronizes with the new source database cluster to ensure data consistency between the target and source clusters.

[0106] This embodiment can accurately identify data version differences by comparing the target cluster metadata with the new source cluster metadata, ensuring the accuracy and efficiency of synchronization; when the data version of the target cluster metadata is higher than the new source cluster metadata, these higher-version data are deleted and re-synchronized from the new source database cluster, avoiding data conflicts or errors caused by inconsistent data versions, thereby ensuring data consistency.

[0107] In a possible implementation of the embodiment of the present application, after the failover is completed, the method further includes:

[0108] The new source database cluster queries the transaction records synchronized from the source database cluster and determines the latest transaction record from the transaction records;

[0109] The application rewrites the data lost during the failover process to the source database cluster based on the latest transaction records.

[0110] In this embodiment, since a failover may lose some recent data, some users want the application to rewrite the lost data after the failover. Therefore, the starting location of the lost data is required to facilitate the application to complete the missing data. Each data write is a transaction, and retaining the transaction record can clearly identify the current write transaction.

[0111] Specifically, during metadata synchronization, transaction records on the source database cluster are also synchronized. Transaction record synchronization and corresponding data synchronization are combined into a single transaction to ensure consistency. By querying the latest transaction record synchronized from the source database cluster on the target database cluster, you can determine which transaction was written at the time of the failure. Subsequent transactions write data to complement the data in the new source database cluster and must be rewritten after failover. The application records the data written by recent transactions so that it can rewrite this data when the data is completed.

[0112] The following table shows an example of a transaction record:

[0113] Transaction ID Transaction Tags Start time End Time 10001 customer_a_20250102 2025-01-0210:00:00:000 2025-01-0210:00:00:100

[0114] The transaction ID is a globally unique transaction number assigned internally by the system. The transaction tag is an optional descriptive information about the transaction provided by the application. The application can record some transaction information in the transaction tag. The transaction record also includes a time stamp, which includes the start time and end time. The start time is the time when the transaction begins, and the end time is the time when the transaction ends. After a failover, the transaction record provides the starting location of the lost data, allowing the application to easily recover the lost data.

[0115] For example, after a failover, the latest transaction records synchronized from the source database cluster saved by the new source database cluster are as shown in the table above, indicating that data written by transactions with transaction IDs greater than 10001 need to be rewritten. It can also be seen that data written after the transaction start time has been lost and needs to be supplemented.

[0116] This embodiment can accurately locate the scope of lost data by querying transaction records and determining the latest transaction records, ensuring the accuracy and efficiency of data recovery; the application rewrites the lost data based on the latest transaction records, minimizing the impact of data loss while ensuring data consistency and integrity; and significantly improving the data recovery capability and business continuity of the distributed database system after failover.

[0117] In a possible implementation of the embodiment of the present application, the synchronization period is no greater than the recovery point objective, and the synchronization period is no greater than the duration for which the application retains data.

[0118] The shorter the synchronization period, the more resources the source database cluster uses. After a failover, recent data may be lost. If the application needs to recover the lost data, the synchronization period should be no longer than the application's data retention period.

[0119] The synchronization cycle is no longer than the recovery point objective, and data synchronization can be completed within the maximum allowable data loss range, minimizing the risk of data loss. The synchronization cycle is no longer than the application's data retention period, ensuring that the application can make up for the lost part based on locally retained data after failover, further enhancing data recovery capabilities.

[0120] The embodiment of the present application provides a distributed database system disaster recovery method based on cross-cluster data synchronization, and its technical effects include:

[0121] 1. Synchronization has minimal impact on the source database cluster. Cross-cluster synchronization uses the method of asynchronously pulling data from the source database cluster to the target database cluster. This does not affect the existing write process on the source database cluster and has minimal impact on the source database cluster.

[0122] 2. Low coupling between clusters involved in synchronization. Different target database clusters independently initiate pull synchronization from the source cluster. Clusters are loosely coupled, and the downtime or exit of any cluster other than the primary cluster does not affect cross-cluster synchronization.

[0123] 3. Clusters involved in synchronization are well isolated. Only cross-cluster synchronization generates cross-cluster interactions. Normal writes and queries are processed locally in the cluster, without cross-cluster interactions. Clusters are well isolated.

[0124] 4. Provide snapshot consistency. At any point in time, the data on the target database cluster is a snapshot of the source database cluster at a certain historical point in time. Queries on the target database cluster ensure that the data is consistent.

[0125] 5. Flexible control of the timing of triggering synchronization. Synchronization can be triggered periodically, with flexible selection of synchronization periods, or at a specified time.

[0126] 6. No redo log or binlog required. This fully leverages the multi-version data management technology commonly used in database systems, synchronizing data by version, achieving incremental and full data version synchronization without the need for redo logs or binlogs.

[0127] 7. Unified full and incremental synchronization. Synchronizing by data version, whether full or incremental, follows the same synchronization process, achieving unified full and incremental synchronization.

[0128] 8. Simple engineering implementation. Compared with methods based on consensus protocols such as Paxos / Raft, the present invention is simpler in engineering implementation and more conducive to engineering implementation.

[0129] 9. Flexible deployment. Flexible deployment can be implemented with any number of clusters, regardless of the number of clusters required. As long as at least one cluster survives, the system will function properly; a majority of clusters is not required.

[0130] 10. Simple membership changes. Adding or removing members from the synchronization cluster is easy to handle, without the need for complex membership change methods like the joint consensus proposed by Raft.

[0131] 11. It can effectively limit cross-cluster network traffic. Normal writes and queries are only processed locally in the cluster and do not generate cross-cluster network traffic. Only cross-cluster synchronization will generate cross-cluster network traffic, which can easily limit cross-cluster network traffic.

[0132] In addition, this embodiment uses a method in which the target database cluster periodically actively pulls data from the source database cluster to achieve cross-cluster synchronization, and can also use a method in which the source database cluster periodically actively pushes data to the target database cluster to achieve cross-cluster synchronization.

Claims

1. A distributed database system disaster recovery method based on cross-cluster data synchronization, characterized in that: Applied to a distributed database system, the method includes: The target database cluster pulls source cluster metadata from the source database cluster based on a synchronization period. The target database cluster is any slave database cluster. The source cluster metadata includes full data information and full node information of the source database cluster. The target database cluster compares the target cluster metadata of the target database cluster with the source cluster metadata to determine difference data; The target database cluster determines a number of transactions based on the difference data, and executes a data version synchronization task corresponding to each transaction, wherein the data version synchronization task is used to synchronize data from the source database cluster; The target database cluster determines a number of transactions based on the difference data, including: The target database cluster determines whether a consistency range input by the user is received, where the consistency range includes any one of: table level, database level, and cluster level; If the target database cluster receives the consistency range input by the user, determining a number of transactions based on the consistency range and the difference data; If the target database cluster does not receive the consistency range input by the user, determining a number of transactions based on a default consistency range and the difference data; When the target database cluster receives the consistency range input by the user, determining a number of transactions based on the consistency range and the difference data includes: The consistency range input by the user is used as the target level, and the difference data belonging to the same target level in the difference data are divided into the same transaction, thereby obtaining a plurality of transactions formed by the difference data.

2. The distributed database system disaster recovery method based on cross-cluster data synchronization according to claim 1, characterized in that: The difference data includes: tables or partitions in which the target cluster metadata has missing or outdated data versions compared with the source cluster metadata.

3. The distributed database system disaster recovery method based on cross-cluster data synchronization according to claim 1, characterized in that: The execution of the data version synchronization task corresponding to each transaction includes: The target database cluster sends a data synchronization request to the source database cluster based on the data version synchronization task corresponding to each transaction; After receiving the data synchronization request, the source database cluster suspends recycling of old data versions; After completing the data version synchronization task corresponding to each transaction, the target database cluster submits a transaction completion notification to the source database cluster; After receiving the transaction completion notification, the source database cluster starts recycling the old data version.

4. The method for disaster recovery of a distributed database system based on cross-cluster data synchronization according to claim 1, characterized in that: The method further comprises: When the source database cluster is unavailable, selecting an available slave database cluster as a new source database cluster to complete failover; The new source database cluster sends an on-call message to each slave database cluster; After receiving the taking office message, each slave database cluster synchronizes data with the new source database cluster based on the synchronization period.

5. The method for disaster recovery of a distributed database system based on cross-cluster data synchronization according to claim 4, characterized in that: Synchronizing data between the target database cluster and the new source database cluster includes: The target database cluster pulls new source cluster metadata from the new source database based on the synchronization period, and compares the new source cluster metadata with the target cluster metadata to obtain new difference data; When the data version of the target cluster metadata in the new differential data is higher than that of the new source cluster metadata, the data in the target cluster metadata with a data version higher than that of the new source cluster metadata is deleted, and the deleted data is synchronized again from the new source cluster metadata.

6. The distributed database system disaster recovery method based on cross-cluster data synchronization according to claim 4, characterized in that: After completing the failover, the method further includes: The new source database cluster queries the transaction records synchronized from the source database cluster, and determines the latest transaction record from the transaction records; The application rewrites the data lost during the failover process to the source database cluster based on the latest transaction record.

7. The distributed database system disaster recovery method based on cross-cluster data synchronization according to claim 1, characterized in that: The synchronization period is no longer than the recovery point objective, and the synchronization period is no longer than the duration for which the application retains data.

8. A distributed database system, characterized in that: The system includes: a source database cluster, multiple slave database clusters, and an application; any one of the multiple slave database clusters serves as a target database cluster to execute the distributed database system disaster recovery method based on cross-cluster data synchronization according to any one of claims 1 to 7; The application is used to access the source database cluster; The source database cluster is configured to provide corresponding services based on access by the application; Each slave database is used to synchronize data of the source database cluster based on a synchronization period.

Images