Data synchronization method and related device

Abstract

The present application belongs to the technical field of databases. Provided are a data synchronization method and a related device. The method implements data synchronization between a source database cluster and a target database cluster on the basis of logical replication, wherein during the execution of an existing transaction, the source database cluster individually starts an autonomous transaction to submit a new generated version of metadata, and after the autonomous transaction is submitted, the target database cluster performs logical decoding on a physical log of the transaction on the basis of the new version of metadata and then performs playback, so as to achieve data synchronization. Compared with the prior art, the method realizes decoupling between physical layers of two database clusters, and supports real-time logical decoding of transaction logs during the execution of hybrid transactions.

Description

A data synchronization method and related equipment

[0001] This application claims priority to Chinese Patent Application No. 202411463889.7, filed on October 18, 2024, entitled "A Data Synchronization Method and Related Device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of database technology, and in particular to a data synchronization method and related equipment. Background Technology

[0003] For complex database systems comprising two database clusters, data needs to be synchronized from the source cluster to the target cluster. When data synchronization is required between the two clusters, there are typically two methods: physical replication and logical replication. Physical replication requires the two clusters to be physically identical, leading to strong coupling and potential failures when using heterogeneous versions. Logical replication typically involves using a third-party Change Data Capture (CDC) tool to obtain and logically decode the physical logs generated by the source cluster. The target cluster then synchronizes with the source cluster by replaying the decoded logs. However, logical replication suffers from drawbacks. Since logical decoding relies on metadata generated during transaction execution, to ensure correct metadata is used, logical decoding of the transaction's physical logs usually must wait until the transaction is complete. This results in significant latency and poor data synchronization performance between the two clusters. Summary of the Invention

[0004] For complex database systems comprising two database clusters, data needs to be synchronized from the source cluster to the target cluster. To achieve physical decoupling between the two clusters, logical replication is typically used for data synchronization. When using logical replication, the physical logs of the source cluster are first logically decoded based on metadata to obtain the logical logs. Then, the target cluster replays these logical logs to achieve data synchronization. However, in existing technologies, to ensure the correct metadata is used for logical decoding of the source cluster's physical logs, logical decoding of the physical logs generated during transaction execution must wait until the transaction is completed. This results in poor flexibility in logical decoding, thus impacting the performance of data synchronization between the two database clusters.

[0005] To address the aforementioned issues, this application provides a data synchronization method and related equipment.

[0006] Firstly, this application provides a data synchronization method. The method includes: a source database cluster executing a first transaction, the first transaction including data processing operations on the database; during the execution of the first transaction, the source database cluster generating a physical log corresponding to the first transaction; the source database cluster initiating a second transaction for the first transaction, the second transaction including metadata update operations caused by the first transaction, the metadata update operations being used to write the new version of metadata generated during the execution of the first transaction into a metadata dictionary; the source database cluster executing the second transaction and committing the second transaction after its execution; a decoding device acquiring the physical log corresponding to the first transaction and the new version of metadata generated during the execution of the first transaction; after the source database cluster commits the second transaction, the decoding device logically decoding the physical log corresponding to the first transaction based on the new version of metadata generated during the execution of the first transaction, obtaining a logical log corresponding to the physical log, wherein the logical log is used to be replayed by a target database cluster to achieve data synchronization with the source database cluster.

[0007] In this method, a second transaction is started separately during the execution of the first transaction to commit the new version of metadata generated during the execution of the first transaction. This allows the decoding device to perform logical decoding of the physical logs generated during the execution of the first transaction without necessarily waiting for the first transaction to finish. This improves the flexibility of logical decoding. Furthermore, when the logically decoded logs are used for replay by the target database cluster, this method can further improve the performance of data synchronization between the source and target database clusters.

[0008] In one possible implementation, the first transaction executed by the source database cluster is a hybrid transaction, which refers to a transaction that includes both Data Definition Language (DDL) and Data Manipulation Language (DML) data processing operations. Specifically, when the first transaction is a hybrid transaction, it includes one or more DDL data processing operations and one or more DML data processing operations. In this implementation, the data synchronization method of this application supports the synchronization of data generated during the execution of the hybrid transaction.

[0009] In one possible implementation, the source database cluster only initiates the second transaction if it determines that the first transaction is a mixed transaction. This approach, where the source database cluster selectively initiates the second transaction, helps alleviate performance pressure on the source database cluster.

[0010] In one possible implementation, the first transaction is still executing after the second transaction is committed. In this implementation, after the source database cluster determines that the second transaction has been committed during the execution of the first transaction, it logically decodes the physical log corresponding to the first transaction based on the new version of metadata generated during the execution of the first transaction to obtain the corresponding logical log. In this implementation, the data synchronization method of this application has already logically decoded the physical log corresponding to the first transaction to obtain the corresponding logical log during the execution of the first transaction, improving the timeliness of logical decoding and thus improving the efficiency of data synchronization.

[0011] Specifically, the second transaction includes metadata update operations caused by the first target data processing operation in the first transaction. The first target data processing operation includes one or more DDL data processing operations preceding the last DDL data processing operation in the first transaction. Correspondingly, the data synchronization method of this application can specifically achieve real-time decoding of the physical logs corresponding to the second target data processing operation in the first transaction during the execution of the first transaction. The second target data processing operation includes one or more DML data processing operations following the first target data processing operation and preceding the last DDL data processing operation.

[0012] In one possible implementation, the first transaction includes multiple DDL data processing operations. During the execution of the first transaction, the source database cluster writes multiple new versions of metadata, along with the correspondence between the metadata and version number of each version, into a metadata dictionary. In this implementation, the decoding device needs to obtain not only the new version's metadata but also the aforementioned correspondence. Accordingly, before logically decoding the physical log based on the new version's metadata, the decoding device first determines the new version's metadata from the multiple versions of metadata based on the physical log's version identifier and the aforementioned correspondence. In this implementation, the metadata dictionary stores metadata versions generated at various historical points in time, enabling the data synchronization method of this application to support not only the logical decoding of physical logs generated in real-time during the execution of the first transaction but also the logical decoding of historically archived physical logs, thereby synchronizing historically archived data. For example, the source database cluster backs up the physical logs generated in real-time during the execution of the first transaction to storage space. Later, when another database cluster needs to synchronize data, it retrieves the historically archived physical logs from storage space and logically decodes the physical logs based on the historical metadata versions in the metadata dictionary.

[0013] In one possible implementation, the version identifier of the physical log includes the physical log sequence number (LSN); in another possible implementation, the version identifier of the physical log includes the commit sequence number (CSN) of the first transaction and the command identifier (CID) of the first transaction. Both implementations, by directly using information from the existing database data recording mechanism as the version identifier of the physical log, make the data synchronization method of this application easier to implement.

[0014] In one possible implementation, the data synchronization method of this application further includes: replaying the logical log corresponding to the first transaction in the target database cluster. In this implementation, the data synchronization method of this application synchronizes the data corresponding to the first transaction to the target database cluster.

[0015] In one possible implementation, the decoding device is deployed within the target database cluster. In this approach, the target database cluster itself performs logical decoding on the physical logs of the source database cluster to obtain logical logs and then replays them. This eliminates the time required for the decoding device to transmit the decoded logical logs to the target database cluster, thereby helping to reduce the latency of data synchronization between the target and source database clusters.

[0016] In one possible implementation, after generating the physical log corresponding to the first transaction, the source database cluster synchronously sends the physical log to the decoding device. This implementation, compared to the decoding device asynchronously copying the physical log corresponding to the first transaction to obtain the physical log, further reduces the latency of data synchronization between the target and source database clusters.

[0017] Secondly, this application provides a data synchronization system for implementing the data synchronization method provided in the first aspect or any possible implementation thereof. It should be noted that the beneficial technical effects of this data synchronization system compared to existing systems in various implementations of the second aspect can be found in the description of the relevant content in the first aspect, and will not be repeated here.

[0018] The data synchronization system includes a source database cluster and a decoding device. The source database cluster is used to: execute a first transaction, which includes data processing operations on the database; generate a physical log corresponding to the first transaction; initiate a second transaction for the first transaction, which includes metadata update operations caused by the first transaction, wherein the metadata update operations are used to write the new version of metadata generated during the execution of the first transaction into a metadata dictionary; and execute the second transaction and commit the second transaction after its execution is completed. The decoding device is used to: obtain the physical log and the new version of metadata; and, after the source database cluster commits the second transaction, logically decode the physical log according to the new version of metadata to obtain a logical log corresponding to the physical log, wherein the logical log is used to be replayed by the target database cluster to achieve data synchronization with the source database cluster.

[0019] In one possible implementation, the source database cluster is used to execute hybrid transactions, which refer to transactions that include both Data Definition Language (DDL) and Data Manipulation Language (DML) data processing operations. Specifically, when the first transaction is a hybrid transaction, it includes one or more DDL data processing operations and one or more DML data processing operations.

[0020] In one possible implementation, the source database cluster is specifically used to initiate a second transaction only if it is determined that the first transaction is a mixed transaction.

[0021] In one possible implementation, the source database cluster is specifically used to: after determining that the second transaction has been committed during the execution of the first transaction, logically decode the physical log corresponding to the first transaction based on the new version of metadata generated during the execution of the first transaction to obtain the corresponding logical log.

[0022] Specifically, the source database cluster is used to initiate a second transaction for the first transaction. The second transaction includes metadata update operations caused by the first target data processing operation in the first transaction. The first target data processing operation includes one or more DDL data processing operations before the last DDL data processing operation in the first transaction.

[0023] In one possible implementation, the source database cluster is specifically used to execute the target first transaction. This target first transaction includes multiple DDL data processing operations, and during the execution of the first transaction, the source database cluster writes multiple new versions of metadata, along with the correspondence between the metadata and version number of each version, into a metadata dictionary. In this implementation, the decoding device is used not only to obtain the new version's metadata but also to obtain the aforementioned correspondence. Accordingly, before logically decoding the physical log based on the new version's metadata, the decoding device first determines the new version's metadata from the multiple versions of metadata based on the physical log's version identifier and the aforementioned correspondence.

[0024] In one possible implementation, the source database cluster uses the log sequence number (LSN) of the physical log as the version identifier of the physical log; in another possible implementation, the source database cluster uses the commit sequence number (CSN) of the first transaction and the command identifier (CID) of the first transaction together as the version identifier of the physical log.

[0025] In one possible implementation, the data synchronization system of this application further includes a target database cluster, which is used to replay logical logs.

[0026] In one possible implementation, the decoding device is deployed in the target database cluster in the data synchronization system of this application.

[0027] In one possible implementation, after the source database cluster generates the physical log corresponding to the first transaction, it synchronously sends the physical log to the decoding device.

[0028] Thirdly, this application provides a computing device cluster including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the data synchronization method provided by the first aspect or any possible implementation of the first aspect.

[0029] Fourthly, this application provides a computer program product containing instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform a data synchronization method as provided in the first aspect or any possible implementation thereof.

[0030] Fifthly, this application provides a computer-readable storage medium including computer program instructions that, when executed by a cluster of computing devices, enable the cluster of computing devices to perform a data synchronization method as provided in the first aspect or any possible implementation thereof. Attached Figure Description

[0031] Figure 1 is a schematic diagram of the structure of a database system provided in an embodiment of this application.

[0032] Figure 2 is a flowchart of an implementation method for a data synchronization method provided in an embodiment of this application.

[0033] Figure 3 is one of the schematic diagrams of the process of synchronizing the data of a specific transaction R according to an embodiment of this application.

[0034] Figure 4 is a second schematic diagram of the process of synchronizing the data of a specific transaction R according to an embodiment of this application.

[0035] Figure 5 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application.

[0036] Figure 6 is a schematic diagram of a connection method for a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0037] The technical solutions provided in this application will now be described in detail with reference to the accompanying drawings. Although some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the accompanying drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0038] In the description of embodiments of this application, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0039] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0040] For complex database systems comprising two database clusters, it is necessary to synchronize data from the source database cluster to the target database cluster. When data synchronization is required between two database clusters, there are typically two methods: physical replication and logical replication.

[0041] When using physical replication for data synchronization, the source database cluster directly sends its physical logs to the target database cluster. The target database cluster then synchronizes with the source database cluster by fully applying the physical logs. However, this data synchronization method requires the two database clusters to be physically identical, resulting in strong coupling between them and making them prone to failure when using heterogeneous versions.

[0042] When using logical replication to achieve data synchronization, a third-party Change Data Capture (CDC) tool is typically required to first obtain the physical logs generated by the source database cluster and logically decode them. The target database cluster then synchronizes with the source cluster by replaying the decoded logical logs. However, in this data synchronization method, because logical decoding relies on metadata generated during transaction execution, to ensure the correct metadata is used for decoding, logical decoding of the transaction's physical logs usually must wait until the transaction execution is complete. This results in significant latency in logical decoding and poor performance for data synchronization between the two database clusters.

[0043] To address at least one of the aforementioned problems, this application provides a data synchronization method that enables real-time logical decoding of transaction logs. Furthermore, when using this method for data synchronization, the source database cluster and the target database cluster can be completely decoupled, thereby improving the performance of data synchronization between the two database clusters.

[0044] Figure 1 is a schematic diagram of the architecture of a database system provided by this application. To better understand the data synchronization method provided by this application, the application scenario of the data synchronization method will first be introduced with reference to Figure 1. The data synchronization method provided by this application is implemented under the system architecture shown in Figure 1.

[0045] In Figure 1, source database cluster 100 and target database cluster 200 achieve data synchronization through logical replication. Source database cluster 100 is responsible for responding to business needs and producing data; therefore, it is also referred to as the database production cluster. After synchronizing the data produced by source database cluster 100, target database cluster 200 can provide data processing capabilities based on the synchronized data. In one possible embodiment, source database cluster 100 is the cluster that executes transactions and produces data, while target database cluster 200 is the cluster that performs data analysis on the synchronized data. In another possible embodiment, source database cluster 100 and target database cluster 200 together form a highly available database system. Target database cluster 200 is a disaster recovery cluster responsible for establishing a disaster recovery relationship with source database cluster 100. In this way, when the database production cluster fails, business can be switched to the database disaster recovery cluster, which will continue to provide database services.

[0046] The source database cluster 100 is a cluster of computing devices used to provide database services, including at least one data node (DN). Figure 1 exemplarily illustrates a source database cluster 100 containing three DNs. In this application, the data node DN is also simply referred to as a node. A DN is a computing device with deployed computing instances. A DN can be implemented by one or more computing devices, which can be physical machines, virtual machines (VMs), containers, Elastic Cloud Servers (ECS), etc. In the example shown in Figure 1, the source database cluster 100 has a primary-secondary architecture, including primary node 101, secondary node 111, and secondary node 112, where primary node 101 is the primary database instance. It should be noted that when the data synchronization method is described later, the specific execution entity of the data synchronization method in the source database cluster will be described using primary node 101 as an example.

[0047] Similarly, the composition and architecture of the target database cluster 200 can be referenced from the source database cluster, and will not be repeated here. The architecture of the target database cluster 200 and the source database cluster 100 can be the same or different. In the example shown in Figure 1, the target database cluster 200 has a one-master-two-standby architecture, including master node 201, standby node 211, and standby node 212, where master node 201 is the primary database instance. It should be noted that when the data synchronization method is described later, the specific execution entity of the data synchronization method in the target database cluster 200 will be described using master node 201 as an example.

[0048] The master node 101 is responsible for producing data, including the database server 1011 and the log sending module 1012.

[0049] Database server 1011 is responsible for executing transactions to process table data, such as inserting a row of data into the table, updating a row of data in the table, or inserting a column into the table. Database server 1011 responds to transaction processing requests from database client 400 by executing transactions. During transaction execution, it records the data processing operations performed within the transaction, i.e., generates a transaction log, and returns the execution result to database client 400 after the transaction is completed. Specifically, in this application, the transaction log in master node 101 is a physical log, such as a WAL log. In Figure 1, master node 101 writes the generated physical log to the master node's physical log file for storage. During transaction execution, when the data processing operations in the transaction cause changes to the table structure, the database server also needs to update the metadata corresponding to the transaction, i.e., generate a new version of metadata, which includes the table's structure definition information. In this application, master node 101 is also responsible for writing the new version of metadata generated during transaction execution into a metadata dictionary. Here, the metadata dictionary refers to a file that stores metadata; its specific implementation is not limited in this application. For example, the metadata dictionary can be a table.

[0050] The log sending module 1012 includes one or more log sending threads responsible for sending the physical logs of the master node 101 to the decoding device 300. Specifically, the log sending module 1012 reads physical logs from the physical log file and sends them to the decoding device 300. For example, multiple log sending threads continuously read newly written physical logs from the physical log file and send them in a queue-like manner.

[0051] The decoding device 300 is responsible for logically decoding the physical logs of the master node 101, and includes a log receiving module 3001 and a log decoding module 3002. The decoding device 300 maintains a metadata file, which stores the metadata synchronized from the master node 101.

[0052] The log receiving module 3001 is responsible for receiving physical logs sent by the master node 101 and saving the physical logs to the physical log file of the decoding device. The log decoding module 3002 includes at least one log reading thread and at least one decoding thread. To implement logical decoding, the log decoding module 3002 first uses the log reading thread to read multiple physical logs from the physical log file and distributes the multiple physical logs to multiple decoding threads. Then, each decoding thread reads the metadata that the physical log depends on from the metadata file and decodes the physical log according to the metadata to obtain the logical log. The logical log is stored in the logical log file.

[0053] The log decoding module 3002 can distribute multiple physical logs to multiple decoding threads using a round-robin method or by elastically allocating them based on the actual load of each decoding thread.

[0054] The master node 201 is responsible for synchronizing data generated by the source database cluster, including the log receiving module 2011 and the database server 2012. The log receiving module 2011 receives logical logs from the decoding device 300 and sends them to the database server 2012. The database server 2012 replays the logical logs to achieve data synchronization between the target database cluster 200 and the source database cluster 100. Specifically, when replaying the logical logs, the database server 2012 generates the same table data and physical log files as the master node 101.

[0055] It should be noted that in Figure 1, the decoding device 300 is displayed independently outside of the source database cluster 100 and the target database cluster 200, but this does not limit the deployment form of the decoding device 300. In one possible embodiment A, the decoding device 300 is a third entity independent of the source database cluster 100 and the target database cluster 200; in another possible embodiment B, the decoding device 300 is deployed in the target database cluster 200. For example, the decoding device 300 and the master node 201 are the same entity, that is, the decoding device 300 is part of the master node 201. In embodiment B, the source database cluster 100 directly sends the generated physical logs to the master node 201 of the target database cluster 200. Then, the master node 201 performs logical decoding and replay of the physical logs to achieve data synchronization between the target database cluster 200 and the source database cluster 100.

[0056] The implementation process of the data synchronization method of this application will be described below with reference to Figure 2, including steps S201-S212.

[0057] S201, Database client 400 sends a transaction processing request to source database cluster 100.

[0058] A database user sends a transaction request to the master node 101 through database client 400. For example, the transaction request includes one or more Structured Query Language (SQL) statements. Specifically, the SQL statements are Data Definition Language (DDL) statements or Data Manipulation Language (DML) statements.

[0059] S202, Source database cluster 100 executes the first transaction, which includes data processing operations on the database.

[0060] After receiving a transaction processing request, the master node 101 initiates a first transaction. This first transaction contains the data processing operations corresponding to the SQL statements in the transaction processing request. In this application, the data processing operations corresponding to DDL statements are called DDL data processing operations (DDL operations for short), and the data processing operations corresponding to DML statements are called DML data processing operations (DML operations for short). The number of data processing operations contained in the first transaction depends on the number of SQL statements in the transaction processing request; one SQL statement corresponds to one data processing operation. Specifically, the data synchronization method of this application supports the synchronization of data generated by mixed transactions; that is, the first transaction can be a mixed transaction including both DDL and DML operations.

[0061] S203, Source database cluster 100 generates the physical log corresponding to the first transaction.

[0062] During the execution of the first transaction, master node 101 generates a physical log for each data processing operation it performs. The physical logs corresponding to the data processing operations within the first transaction are collectively referred to as the physical logs for the first transaction. When the first transaction contains multiple data processing operations, the physical logs corresponding to the first transaction also consist of multiple physical logs. The physical logs corresponding to DDL operations are called DDL logs, and the physical logs corresponding to DML operations are called DML logs.

[0063] S204, Source database cluster 100 starts a second transaction for the first transaction. The second transaction includes the metadata update operation caused by the first transaction. The metadata update operation is used to write the new version of metadata generated during the execution of the first transaction into the metadata dictionary.

[0064] In this application, when the master node 101 responds to a transaction processing request, in addition to starting a first transaction to execute the data processing operation corresponding to the transaction processing request, it also starts a second transaction for the first transaction to separately write the new version of metadata generated during the execution of the first transaction into the metadata dictionary.

[0065] In one possible embodiment, when the first transaction is a mixed transaction containing both DDL and DML operations, the master node 101 selects to start a second transaction for the first transaction.

[0066] During the execution of the first transaction, each DDL operation causes changes to the table structure, so a new version of metadata is generated each time a DDL operation is executed. In this application, each time a new version of metadata is generated during the execution of the first transaction, the master node 101 writes the new version of metadata into the metadata dictionary, while the old version of metadata remains unchanged.

[0067] In one possible embodiment, the first transaction contains multiple DDL operations, and the metadata dictionary stores multiple versions of metadata generated during the execution of the first transaction. For each version of metadata, the metadata dictionary stores the correspondence between metadata and version number.

[0068] Since the metadata dictionary stores metadata versions generated at various times during the transaction execution process, the data synchronization method of this application can not only support the decoding of online physical logs, but also the decoding of historical physical logs or archived physical logs.

[0069] In this application, the version number is a sequence number used to uniquely identify the execution order of data processing operations in the first transaction, and its implementation is not limited. Considering that the master node 101 generates corresponding DDL logs when executing DDL operations and assigns a Log Sequence Number (LSN) to each DDL log, in one possible embodiment, the LSN of the DDL log can be selected as the version number of the metadata. Considering that the master node 101 assigns a Commit Sequence Number (CSN) to the transaction when executing the transaction, and assigns a Command ID (CID) to each data processing operation in the transaction, in one possible embodiment, the CSN of the first transaction and the CID of the DDL operation in the first transaction can be selected together as the version number of the DDL operation in the first transaction. In this embodiment, the version number is recorded as "CSN+CID".

[0070] In this application, the second transaction includes a metadata update operation caused by a target data processing operation in the first transaction, wherein the target data processing operation includes one or more DDL operations prior to the last DDL operation in the first transaction.

[0071] In one possible embodiment, the master node 101 opens a second transaction for each DDL operation in the first transaction. In this case, the second transaction is used to write the new version of the metadata generated by executing a DDL operation into the metadata dictionary.

[0072] In one possible embodiment, the master node 101 will start a second transaction for all DDL operations in the first transaction. In this case, the second transaction is used to write one or more new versions of metadata generated by all DDL operations in the first transaction into the metadata dictionary.

[0073] S205, the source database cluster 100 executes the second transaction and commits it after the second transaction is completed.

[0074] In this application, by opening a second transaction separately for the first transaction, the metadata generated during the execution of the first transaction is independently committed, improving the flexibility of metadata storage. Furthermore, since the target database cluster 200 can only replay the logical log to achieve data synchronization with the source database cluster 100 after logically decoding the physical log based on the metadata, opening and committing a second transaction separately for the first transaction can improve the flexibility of data synchronization.

[0075] Specifically, the storage of metadata generated during the execution of the first transaction does not depend on the completion of the first transaction. As long as the second transaction is successfully committed, even if the first transaction is still being executed or a rollback of the DDL operation occurs during the execution, the metadata generated by the DDL operation can still be stored. This allows for logical decoding of the physical log corresponding to the first transaction based on the metadata generated by the DDL operation during the transaction execution process, improving the timeliness of logical decoding and further improving the timeliness of data synchronization.

[0076] S206, Decoding device 300 obtains the physical log corresponding to the first transaction.

[0077] In one possible embodiment, the decoding device 300 asynchronously copies the physical logs generated by the master node 101 and stores the physical logs in a physical log file of the decoding device 300. For example, the decoding device 300 is a CDC tool used to capture the physical logs generated by the master node 101.

[0078] In one possible embodiment, after generating the physical log, the master node 101 synchronously sends the physical log to the decoding device 300 using the log sending thread in the log sending module 1012. Upon receiving the physical log, the log receiving module 3001 in the decoding device 300 stores the physical log in the physical log file of the decoding device. This embodiment, compared to asynchronous copying, further improves the timeliness of the decoding device in obtaining the physical log.

[0079] S207, Decoding device 300 obtains the metadata of the new version generated during the execution of the first transaction.

[0080] Specifically, the master node 101 will synchronize the new version of the metadata stored in the metadata dictionary to the decoding device 300. The decoding device will then store the synchronized metadata in its own metadata file.

[0081] In one possible embodiment, the master node 101 further includes a metadata sending module, which includes at least one metadata sending thread. Similar to the way the decoding device 300 obtains physical logs, after writing the new version of metadata into the metadata dictionary, the master node 101 uses the metadata sending thread to synchronously send the new version of metadata to the decoding device 300. In particular, this metadata acquisition method can be used when the decoding device 300 is deployed in the manner of embodiment A.

[0082] In one possible embodiment, the decoding device 300 obtains the new version's metadata by physically replaying the DDL log.

[0083] In one possible embodiment, the decoding device 300 obtains the new version of metadata by logically replaying the DDL logs. Specifically, this metadata acquisition method can be used when the decoding device 300 is deployed in the manner described in Embodiment B. In this embodiment, the master node 201 directly obtains the physical logs of the master node 101 and performs logical decoding. After obtaining the DDL logs and decoding them into corresponding logical logs, the master node 201 replays the DDL logical logs to generate the new version of metadata, and then writes the new version of metadata into the master node 201's metadata dictionary. Correspondingly, when the master node 101's metadata dictionary stores multiple versions of metadata, in order to achieve metadata synchronization with the master node 101, after obtaining the DDL logs, the master node 201 generates the new version of metadata by logically replaying the DDL logs, and then writes the new version of metadata and the corresponding version number into the master node 201's metadata dictionary.

[0084] When multiple versions of metadata are generated during the execution of the first transaction, the decoding device 300 needs to obtain the mapping relationship between metadata and version numbers stored in the metadata dictionary of the master node 101 when acquiring the metadata of the new version. Specifically, the master node 101 will synchronize the new version's metadata and the mapping relationship between metadata and version numbers stored in its metadata dictionary to the decoding device 300. The decoding device will store the synchronized metadata and the aforementioned mapping relationship in its own metadata file. The specific implementation method of the master node 101 synchronizing the metadata and mapping relationship to the decoding device 300 can be referred to the synchronization method when only metadata is synchronized above, and will not be repeated here.

[0085] S208, after the source database cluster 100 completes the second transaction, the decoding device 300 performs logical decoding on the physical log based on the new version of the metadata to obtain the logical log corresponding to the physical log.

[0086] Specifically, logically decoding DML logs requires relying on the new version of metadata generated after the most recent DDL operation preceding the DML operation. In other words, the decoding device 300 performs logical decoding on all DML operations between DDL operation P and the next DDL operation Q following DDL operation P, based on the new version of metadata generated after the execution of a DDL operation P.

[0087] In one possible embodiment, the first transaction includes multiple DDL operations. During the execution of the first transaction, multiple versions of metadata are generated. Therefore, for each DML log, after obtaining the DML log, the decoding device 300 needs to first retrieve the new version of metadata that the DML log depends on from the multiple versions of metadata, based on the version identifier of the DML log and the correspondence between version number and metadata. The version identifier of the DML log is used to indicate the version of the metadata that the DML log depends on.

[0088] Corresponding to the implementation method of metadata version number, when the version number of metadata uses the LSN of DDL log, the version identifier of DML log uses the LSN of DML log; when the CSN of the first transaction and the CID of DDL operation in the first transaction are used together as the version number of DDL operation, the version identifier of DML log uses the CSN of the first transaction and the CID of DML operation in the first transaction.

[0089] When both the version number of the metadata and the version identifier of the DML log use LSN, the rule for determining the new version of the metadata that the DML log depends on from multiple versions of metadata is: query the metadata of the version number that is less than and closest to the LSN of the DML log from multiple versions of metadata as the metadata that is logically decoded by the DML log.

[0090] When both the version number of the metadata and the version identifier of the DML log use "CSN+CID", the rule for determining the new version of the metadata that the DML log depends on from multiple versions of metadata is as follows: query the metadata of a target version from multiple versions of metadata as the metadata that the DML log depends on for logical decoding. The CSN of the target version is the same as the CSN of the DML log, and the CID of the target version is less than and closest to the CID of the DML log.

[0091] S209, Target database cluster 200 retrieves logical logs.

[0092] When the decoding device adopts the deployment configuration of Example A, the decoding device sends the decoded logical log to the master node 201.

[0093] When the decoding device 300 adopts the deployment configuration of Embodiment B, the master node 201 is also the decoding device 300. The master node 201 obtains the logical log after logically decoding the physical log. That is to say, in this case, the master node 201 and the master node 101 each maintain a metadata dictionary, and the metadata dictionary in the master node 201 stores the same metadata synchronized from the master node 101.

[0094] When the decoding device 300 adopts the deployment configuration of Embodiment B, the data synchronization method of this application can support the realization of data synchronization between the source database cluster 100 and the target database cluster 200 with Recovery Point Objective (RPO) = 0.

[0095] S210, target database cluster 200 replay logic log.

[0096] S211, Source database cluster 100 commits the first transaction after the first transaction is executed.

[0097] S212, the source database cluster 100 returns the execution result of the first transaction to the database client 400.

[0098] In summary, this application provides a more flexible data synchronization method with the following advantages: This method achieves physical layer decoupling between the source and target database clusters, allowing the source and target database clusters to use different versions, thus making the deployment of the entire database system more flexible; this method supports the synchronization of data generated during mixed transaction execution and supports real-time decoding of ongoing transactions; this method helps improve the timeliness of logical decoding of physical logs and the efficiency of data synchronization between the source and target database clusters.

[0099] To help those skilled in the art better understand the data synchronization method of this application, the following describes, with reference to Figures 3 and 4, the process of synchronizing data generated during the execution of a specific transaction R using the data synchronization method of this application. In the embodiments concerning transaction R below, the decoding device 300 adopts the deployment configuration of embodiment B above, that is, the master node 201 directly performs logical decoding and replays the WAL log generated by the master node 101.

[0100] Transaction R includes 9 data processing operations on table T1. "Create T1" and "Alter T1" represent DDL operations, which respectively represent creating table T1 and adding a column to table T1. "DML T1" represents a DML operation on a row of data in T1. The DML operation can be any of the insert, update, or delete operations.

[0101] During the execution of transaction R, master node 101 generates a corresponding WAL log for each data processing operation and stores it in the WAL log file. Furthermore, for each DDL operation, master node 101 starts an autonomous transaction. This autonomous transaction is used to write the new version of metadata generated after the DDL operation—that is, the new table structure definition—into the metadata dictionary. In Figure 3, the WAL log corresponding to the "Create T1" operation is represented by "T1-Create", the WAL log corresponding to the Xth DML operation is represented by "T1-DMLX", and the WAL log corresponding to the Xth "Alter T1" operation is represented by "T1-AlterX".

[0102] As shown in Figure 3, three autonomous transactions r1, r2, and r3 are initiated during the execution of transaction R. After autonomous transaction r1 is executed, the metadata dictionary stores the metadata of version V0 generated after the "Create T1" operation. The metadata of version V0 includes the initial table structure definition of T1. After autonomous transaction r2 is executed, in addition to the metadata of version V0, the metadata dictionary further stores the metadata of version V1 generated after the first "Alter T1" operation. The metadata of version V1 includes the table structure definition of T1 after the addition of the first column. After autonomous transaction r3 is executed, in addition to the metadata of versions V0 and V1, the metadata dictionary further stores the metadata of version V2 generated after the second "Alter T1" operation. The metadata of version V2 includes the table structure definition of T1 after the addition of the second column. For each autonomous transaction, once the metadata and the corresponding version number are written to the metadata dictionary, the master node 101 commits the autonomous transaction. By initiating separate autonomous transactions for transaction R, the separate commit of the new version metadata generated during the execution of transaction R is achieved.

[0103] It should be noted that the version number and metadata format in the metadata dictionary shown in Figure 3 are merely logical representations and do not represent the actual storage format used in applications. This application does not limit the storage format of the version number and metadata. The same consideration should be adopted for WAL log files.

[0104] On the one hand, compared with existing technologies, the data synchronization method of this application can achieve real-time decoding of the WAL log of transaction R during the execution of transaction R. When executing transaction R using existing technologies, transaction R can only be committed after the last data operation (i.e., the sixth DML operation) is completed, and logical decoding can only be performed after transaction R is committed. Therefore, even if the metadata dictionary already stores the metadata of versions V0 and V1, it is impossible to decode the WAL logs corresponding to the previous 5 DML operations before the execution of the sixth DML operation is completed. For example, in the existing technology, after the sixth DML operation is completed, the master node 201 can only perform logical decoding of the WAL log corresponding to the second DML operation based on the metadata of version V0, resulting in large latency in logical decoding and low efficiency in data synchronization. However, with the data synchronization method of this application, the master node 101 can perform logical decoding of the WAL log corresponding to the second DML operation at the same time as executing the first "Alter T1" operation, thus improving the timeliness of logical decoding. Furthermore, once the sixth DML operation is completed and master node 101 commits transaction R, master node 201 can immediately obtain the WAL log corresponding to the second DML operation and replay it to obtain the same table data after the second DML operation is executed as master node 101, thereby improving the efficiency of data synchronization.

[0105] On the other hand, compared with existing technologies, the data synchronization method of this application can ensure that even if the DDL operation in a transaction is rolled back, the new version of metadata generated after the DDL operation is executed is not lost, thereby improving the timeliness of logical decoding of the WAL log in the case of transaction rollback. For example, when executing transaction R using existing technology, if the second "Alter T1" operation and the sixth DML operation are rolled back, since the autonomous transaction r3 has already written the V2 version of metadata generated during the execution of the second "Alter T1" operation into the metadata dictionary and committed, then the master node 201 can logically decode the WAL log corresponding to the sixth DML operation to obtain the logical log corresponding to the sixth DML operation during the re-execution of the sixth DML operation by the master node 101, thus improving the timeliness of logical decoding.

[0106] After receiving the WAL log of transaction R from master node 101, master node 201 stores the WAL log in its WAL log file. Then, master node 201 uses at least one log reading thread to read the WAL log from the WAL log file and distribute it to the decoding thread.

[0107] Figure 4 illustrates the scenario where the WAL log of transaction R is distributed to four decoding threads in a round-robin fashion. For each decoding thread, the thread decodes its assigned WAL log sequentially. Upon receiving the DDL log, the decoding thread logically replays the DDL log and writes the newly generated metadata and its version number into the metadata dictionary of master node 201. Upon receiving the DML log, the decoding thread first retrieves the metadata that the decoding of the DML log depends on from the metadata dictionary based on the DML log's version identifier. For example, after replaying the "T1-Alter1" log, decoding thread 1 writes the metadata of version V1 into the metadata dictionary and uses the LSN of the "T1-Alter1" log as the version number V1; after replaying the "T1-Create" log, decoding thread 2 writes the metadata of version V0 into the metadata dictionary and uses the LSN of the "T1-Create" log as the version number V0. In one possible embodiment, before decoding thread 3 performs logical decoding on the "T1-DML4" log, decoding threads 1 and 2 have already written the metadata of versions V1 and V0 into the metadata dictionary, respectively. Then, when decoding thread 3 logically decodes the "T1-DML4" log, it queries the metadata dictionary to determine that the metadata of version V1, whose version number is less than and closest to the LSN of the "T1-DML4" log, is the metadata that "T1-DML4" depends on. Afterward, decoding thread 3 reads the metadata of version V1 from the metadata dictionary to perform logical decoding on the "T1-DML4" log to obtain the corresponding logical log.

[0108] It should be understood that, in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0109] This application also provides a data synchronization system capable of implementing all or part of the data synchronization method provided in any possible implementation of the above-described method embodiments. For example, the data synchronization system includes at least one of the source database cluster 100, the decoding device 300, and the target database cluster 200 in the database system shown in FIG1.

[0110] Specifically, the specific implementation of various operations of the data synchronization method by the above data synchronization system can be found in the description of the relevant content in the above method embodiments, and will not be repeated here.

[0111] In this application, the source database cluster 100 or the target database cluster 200 may be a database cluster deployed on the cloud, including infrastructure managed by a cloud management platform for providing cloud database services. The infrastructure includes computing resources and storage resources. The computing resources include at least one of CPU, NPU or GPU, and the storage resources include at least one of memory and persistent storage media.

[0112] In this embodiment, any one of the source database cluster 100, the decoding device 300, and the target database cluster 200 can be implemented by software or hardware. The implementation of the source database cluster 100 is described below as an example; the implementation of the decoding device 300 and the target database cluster 200 are similar.

[0113] Source database cluster 100, as an example of a software functional unit, may include code running on compute instances. These compute instances can be at least one of physical hosts, virtual machines, containers, or other computing devices. Further, the aforementioned computing devices may be one or more. For example, source database cluster 100 may include code running on multiple hosts, virtual machines, or containers. It should be noted that the multiple hosts, virtual machines, or containers used to run the code can be distributed within the same Availability Zone (AZ) or in different AZs, with each AZ including one or more geographically proximate data centers. The multiple hosts, virtual machines, or containers used to run the code can also be distributed within the same region or in different regions. Typically, a region may include multiple AZs, with VPCs set up within a single region. Cross-region communication between two VPCs within the same region, and between VPCs in different regions, requires a communication gateway to be set up within each VPC, enabling interconnection between VPCs.

[0114] Similarly, multiple hosts, virtual machines, or containers used to run this code can be distributed within the same VPC or across multiple VPCs. Typically, a region can include multiple Availability Zones (AZs).

[0115] The source database cluster 100, as an example of a hardware functional unit, may include at least one computing device, such as a server. Alternatively, the source database cluster 100 may also be a device implemented using an ASIC or a PLD. The aforementioned PLD may be implemented using a CPLD, FPGA, GAL, or any combination thereof.

[0116] The source database cluster 100 includes multiple computing devices that can be distributed within the same Availability Zone (AZ) or in different AZs. Similarly, the modules include multiple computing devices that can be distributed within the same region or in different regions. Likewise, the modules include multiple computing devices that can be distributed within the same Virtual Private Cloud (VPC) or multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0117] This application also provides a computing device cluster, as shown in Figure 5, which is a schematic diagram of the computing device cluster. This computing device cluster can implement the data synchronization method described in the above embodiments. As shown in Figure 5, the computing device cluster includes at least one computing device 500.

[0118] The computing device 500 can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone. The computing device 500 includes a bus 502, a processor 504, a memory 506, and a communication interface 508. The processor 504, the memory 506, and the communication interface 508 communicate with each other via the bus 502. The computing device 500 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memory in the computing device 500.

[0119] Bus 502 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 5, but this does not imply that there is only one bus or one type of bus. Bus 502 can include pathways for transmitting information between various components of computing device 500 (e.g., memory 506, processor 504, communication interface 508).

[0120] Processor 504 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0121] Memory 506 may include volatile memory, such as random access memory (RAM). Memory 506 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0122] The memory 506 stores executable program code, and the processor 504 executes the executable program code to implement the function of at least one module in the aforementioned data synchronization system, thereby partially or completely implementing the data synchronization method of this application.

[0123] In some possible implementations, each computing device 500 in the computing device cluster stores a complete set of instructions for executing the data synchronization method in its memory 506. When at least one computing device in the computing device cluster executes these instructions, the computing device cluster can implement the data synchronization method as described in the method embodiments.

[0124] In some other possible implementations, the memory 506 of one or more computing devices 500 in the computing device cluster respectively stores partial instructions for executing the data synchronization method. In other words, a combination of one or more computing devices 500 can jointly implement the data synchronization method of this application.

[0125] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 6 illustrates one possible implementation. As shown in Figure 6, two computing devices 500A and 500B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 506 in computing device 500A stores instructions for performing part of the functions of the data synchronization system, while the memory 506 in computing device 500B stores instructions for performing another part of the functions of the data synchronization system.

[0126] It should be understood that the functions of computing device 500A shown in Figure 6 can also be performed by multiple computing devices 500. Similarly, the functions of computing device 500B can also be performed by multiple computing devices 500.

[0127] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the data synchronization method of this application.

[0128] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct a computing device to execute the data synchronization method of this application, or instruct a computing device to execute the data synchronization method of this application.

[0129] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described in this application can all be referred to the corresponding processes in the method embodiments, and will not be repeated here.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data synchronization method, characterized in that, The method includes: The source database cluster executes the first transaction, which includes data processing operations on the database. The source database cluster generates the physical log corresponding to the first transaction; The source database cluster initiates a second transaction for the first transaction. The second transaction includes a metadata update operation caused by the first transaction. The metadata update operation is used to write the new version of metadata generated during the execution of the first transaction into the metadata dictionary. The source database cluster executes the second transaction and commits the second transaction after its execution is complete; The decoding device obtains the physical log and the metadata of the new version; After the source database cluster submits the second transaction, the decoding device performs logical decoding on the physical log according to the new version of the metadata to obtain the logical log corresponding to the physical log. The logical log is used to be replayed by the target database cluster to achieve data synchronization with the source database cluster.

2. The method according to claim 1, characterized in that, The first transaction includes Data Definition Language (DDL) data processing operations and Data Manipulation Language (DML) data processing operations.

3. The method according to claim 1 or 2, characterized in that, The method further includes: after the second transaction is committed, the first transaction is still in the process of execution.

4. The method according to any one of claims 1-3, characterized in that, The second transaction includes a metadata update operation caused by a target data processing operation in the first transaction, the target data processing operation including one or more DDL data processing operations preceding the last DDL data processing operation in the first transaction.

5. The method according to any one of claims 1-4, characterized in that, The metadata dictionary stores metadata for multiple versions generated during the execution of the first transaction. For each version of metadata, the metadata dictionary stores the correspondence between metadata and version number.

6. The method according to claim 5, characterized in that, The method further includes: the decoding device acquiring the correspondence.

7. The method according to claim 6, characterized in that, The physical log has a version identifier, which is used to indicate the version of the metadata that the physical log depends on; The decoding device obtains the metadata of the new version, including: The decoding device obtains the metadata of the new version based on the version identifier of the physical log and the corresponding relationship.

8. The method according to claim 7, characterized in that, The version identifier includes the log sequence number (LSN) of the physical log, or the version identifier includes the commit sequence number (CSN) of the first transaction and the command identifier (CID) of the first transaction.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: The target database cluster replays the logical logs.

10. The method according to any one of claims 1-9, characterized in that, The decoding device is deployed in the target database cluster.

11. The method according to any one of claims 1-10, characterized in that, The decoding device acquires the physical log, including: The decoding device receives the physical log, wherein the physical log is generated by the source database cluster and then synchronously sent to the decoding device after generating the physical log corresponding to the first transaction.

12. A data synchronization system, characterized in that, The system includes a source database cluster and decoding equipment, wherein, The source database cluster is used to: execute a first transaction, the first transaction including data processing operations on the database; generate a physical log corresponding to the first transaction; start a second transaction for the first transaction, the second transaction including metadata update operations caused by the first transaction, the metadata update operations being used to write the new version of metadata generated during the execution of the first transaction into the metadata dictionary; and execute the second transaction, and commit the second transaction after the execution of the second transaction is completed. The decoding device is used to: acquire the physical log and the metadata of the new version; and, after the source database cluster has committed the second transaction, to logically decode the physical log according to the metadata of the new version to obtain the logical log corresponding to the physical log, wherein the logical log is used to be replayed by the target database cluster to achieve data synchronization with the source database cluster.

13. The system according to claim 12, characterized in that, The source database cluster is specifically used to execute the first transaction, which includes Data Definition Language (DDL) data processing operations and Data Manipulation Language (DML) data processing operations.

14. The system according to claim 12 or 13, characterized in that, The source database cluster is specifically used to submit the second transaction during the execution of the first transaction.

15. The system according to any one of claims 12-14, characterized in that, The source database cluster is specifically used to: execute the second transaction, the second transaction including metadata update operations caused by target data processing operations in the first transaction, the target data processing operations including one or more DDL data processing operations prior to the last DDL data processing operation in the first transaction.

16. The system according to any one of claims 12-15, characterized in that, The source database cluster is used to write the metadata of multiple versions generated during the execution of the first transaction, as well as the correspondence between each metadata and version number, into the metadata dictionary.

17. The system according to claim 16, characterized in that, The decoding device is also used to obtain the correspondence.

18. The system according to claim 17, characterized in that, The decoding device is specifically used to: obtain the metadata of the new version according to the version identifier of the physical log and the corresponding relationship, wherein the version identifier is used to indicate the metadata version on which the physical log depends.

19. The system according to claim 18, characterized in that, The source database cluster is specifically used to: use the log sequence number (LSN) of the physical log as the version identifier of the physical log, or use the commit sequence number (CSN) of the first transaction and the command identifier (CID) of the first transaction together as the version identifier of the physical log.

20. The system according to any one of claims 12-19, characterized in that, The system also includes a target database cluster, which is used to replay the logical logs.

21. The system according to any one of claims 12-20, characterized in that, The decoding device is deployed in the target database cluster.

22. The system according to any one of claims 12-21, characterized in that, The source database cluster is also used to: synchronously send the physical log to the decoding device after generating the physical log corresponding to the first transaction.

23. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the data synchronization method as described in any one of claims 1-11.

24. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster performs the data synchronization method as described in any one of claims 1-11.

25. A computer-readable storage medium, characterized in that, It includes computer program instructions, which, when executed by a cluster of computing devices, enable the cluster of computing devices to perform the data synchronization method as described in any one of claims 1-11.

Images