Data synchronization method and apparatus

Abstract

Embodiments of the present disclosure provide a data synchronization method and apparatus. The data synchronization method comprises: when it is determined that a primary database has received a database operation request, executing the database operation request, and determining a target event corresponding to the database operation request; before the primary database completes execution of the database operation request, sending the target event to a standby database corresponding to the primary database, and using the standby database to parse the target event to obtain and execute the database operation request; and on the basis of a first execution result obtained by the primary database executing the database operation request, determining a second execution result obtained by the standby database executing the database operation request. The target event corresponding to the database operation request is transmitted in advance to the standby database for replay, thereby reducing the replication delay for the standby database to execute the database operation request.

Description

Data synchronization method and apparatus

[0001] This disclosure claims priority to Chinese Patent Application No. 202510363844.0, filed with the Chinese Patent Office on March 25, 2025, entitled “Data Synchronization Method and Apparatus”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of database technology, and in particular to a data synchronization method. One or more embodiments of this disclosure also relate to another data synchronization method, two data synchronization devices, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0003] DDL (Data Definition Language) is a heavy operation in databases that requires a long execution time. In a database system, DDL can only be synchronized to the standby database for replay after it has been executed in the primary database. Replay means that the DDL is also executed in the standby database to achieve data synchronization between the primary and standby databases.

[0004] DDL operations can only be synchronized to the standby database for replay after they are executed on the primary database, which causes significant delays in primary-standby replication. Summary of the Invention

[0005] In view of this, the present disclosure provides a data synchronization method. One or more embodiments of the present disclosure also involve another data synchronization method, two data synchronization devices, a computing device, a computer-readable storage medium, and a computer program product, in order to solve the technical defects of master-slave replication delay in the prior art.

[0006] According to a first aspect of the present disclosure, a data synchronization method is provided, comprising:

[0007] If it is determined that the main database has received a database operation request, the database operation request is executed, and the target event corresponding to the database operation request is determined;

[0008] Before the primary database completes the database operation request, the target event is sent to the backup database corresponding to the primary database. The backup database is then used to parse the target event, obtain and execute the database operation request.

[0009] Based on the first execution result of the database operation request executed by the primary database, the second execution result of the database operation request executed by the backup database is determined.

[0010] According to a second aspect of the present disclosure, a data synchronization apparatus is provided, comprising:

[0011] The event determination module is configured to execute the database operation request and determine the target event corresponding to the database operation request when it is determined that the main database has received a database operation request.

[0012] The event replication module is configured to send the target event to the backup database corresponding to the primary database before the primary database completes the database operation request, and use the backup database to parse the target event, obtain and execute the database operation request.

[0013] The result determination module is configured to determine the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the primary database.

[0014] According to a third aspect of the embodiments of this disclosure, another data synchronization method is provided, comprising:

[0015] If it is determined that the primary database has received a database operation request, the database operation request is executed, and the target log event corresponding to the database operation request is determined. The target log event includes a target event and a log event, and the log event is obtained when the primary database has completed the execution of the database operation request.

[0016] The target log event is sent to the backup database corresponding to the primary database. The target worker thread of the backup database is used to parse the target event to obtain the database operation request and the request identifier corresponding to the database operation request.

[0017] When the target worker thread is used to execute the database operation request, the request identifier corresponding to the database operation request is added to the target execution set of the backup database.

[0018] If the original worker thread of the backup database is used to parse the log events to obtain the request identifier corresponding to the database operation request, and the target execution set is found to contain the request identifier, the execution of the database operation request will be skipped.

[0019] Based on the first execution result of the database operation request executed by the primary database, the second execution result of the database operation request executed by the backup database is determined.

[0020] According to a fourth aspect of the present disclosure, another data synchronization apparatus is provided, comprising:

[0021] The event determination module is configured to, upon determining that the main database has received a database operation request, execute the database operation request and determine the target log event corresponding to the database operation request, wherein the target log event includes a target event and a log event, and the log event is obtained when the main database has completed executing the database operation request;

[0022] The event parsing module is configured to send the target log event to the backup database corresponding to the primary database, and use the target worker thread of the backup database to parse the target event to obtain the database operation request and the request identifier corresponding to the database operation request.

[0023] The event replication module is configured to add the request identifier corresponding to the database operation request to the target execution set of the backup database when the database operation request is executed using the target worker thread. This is so that when the log event is parsed using the original worker thread of the backup database to obtain the request identifier corresponding to the database operation request, and the execution of the database operation request is skipped if the request identifier exists in the target execution set.

[0024] The result determination module is configured to determine the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the primary database.

[0025] According to a fifth aspect of the present disclosure, a computing device is provided, comprising:

[0026] Memory and processor;

[0027] The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above-described data synchronization method.

[0028] According to a sixth aspect of the present disclosure, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described data synchronization method.

[0029] According to a seventh aspect of the present disclosure, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data synchronization method.

[0030] This disclosure provides a data synchronization method in one embodiment. Upon determining that the primary database has received a database operation request, the method executes the database operation request and determines the target event corresponding to the database operation request. Before the primary database completes the execution of the database operation request, the method sends the target event to a backup database corresponding to the primary database. The backup database parses the target event to obtain and execute the database operation request. That is, the backup database parses and executes the same database operation request as the primary database. By determining the second execution result of the database operation request in the backup database based on the first execution result of the primary database's execution of the database operation request, the method ensures eventual consistency between the primary and backup databases. Compared to transmitting log events to the backup database only after the primary database has completed the database operation request, this method reduces the replication delay of the backup database's execution of the database operation request by transmitting the target event corresponding to the database operation request to the backup database for replay in advance. Attached Figure Description

[0031] Figure 1 is a schematic diagram of a data synchronization method provided in an embodiment of this disclosure;

[0032] Figure 2 is a flowchart of a data synchronization method provided in an embodiment of this disclosure;

[0033] Figure 3 is a flowchart of another data synchronization method provided in an embodiment of this disclosure;

[0034] Figure 4a is a schematic diagram showing a comparison of effects provided by an embodiment of this disclosure;

[0035] Figure 4b is a schematic diagram of the processing procedure of a data synchronization method provided in an embodiment of this disclosure;

[0036] Figure 5 is a schematic diagram of the structure of a data synchronization device provided in an embodiment of this disclosure;

[0037] Figure 6 is a schematic diagram of another data synchronization device provided in an embodiment of the present disclosure;

[0038] Figure 7 is a structural block diagram of a computing device provided in an embodiment of this disclosure. Detailed Implementation

[0039] Numerous specific details are set forth in the following description to provide a full understanding of this disclosure. However, this disclosure can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this disclosure. Therefore, this disclosure is not limited to the specific implementations disclosed below.

[0040] The terminology used in one or more embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this disclosure. The singular forms “a,” “the,” and “the” as used in one or more embodiments of this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this disclosure refers to and includes any or all possible combinations of one or more associated listed items.

[0041] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this disclosure, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this disclosure, and similarly, second may also be referred to as first. Depending on the context, the word “if” as used herein may be interpreted as “when”, “in response to a determination”, or “when…”.

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

[0043] First, the terms and concepts involved in one or more embodiments of this disclosure will be explained.

[0044] Binlog: Binary Log, a logical log file of a database system used for data replication. It records all data change operations and is stored in a dedicated file.

[0045] Binlog event: A binlog event is a component of the binlog. Each transaction records several binlog events in the binlog. The master database transmits binlog events to the standby database, and the standby database applies the binlog events to replay the master database transactions, ensuring data consistency between the master and standby databases. One DDL statement corresponds to one transaction.

[0046] Relaylog: The relay log, also known as the logical log of a database system, is used for data replication. The binlog events received by the backup database from the master database are written to the Relaylog.

[0047] SQL thread: The backup database read thread, used to read binlog events from the Relaylog file and assign them to the Worker thread for replay.

[0048] Worker thread: The worker thread for the backup database, used to replay binlog events.

[0049] Brr_item_event: A new event type added in this embodiment, namely the project event in this embodiment. Events corresponding to this event type will not be recorded in Binlog.

[0050] DDL is a heavy operation in databases that requires a long execution time. In MySQL (a database system), DDL can only be synchronized to the standby database for replay after it has been executed on the primary database, which will cause significant master-slave replication delay.

[0051] Specifically, the existing data synchronization method is explained as follows: After the DDL execution is completed, the master database transmits the binlog events recorded in the binlog to the standby database (binlog events include GTID events and Query events); the standby database receives the binlog events from the master database and writes them to the Relaylog; the SQL thread reads the binlog events in the Relaylog and assigns them to the Worker thread for replay; the Worker thread replays the binlog events to complete the data synchronization.

[0052] To eliminate this adverse effect and ensure high availability, embodiments of this disclosure implement a method for applying DDL in real time to a standby database, thereby solving the problem of master-slave replication latency caused by DDL.

[0053] This disclosure provides a data synchronization method, and also relates to another data synchronization method, two data synchronization devices, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0054] Referring to Figure 1, Figure 1 shows a schematic diagram of a data synchronization method provided according to an embodiment of the present disclosure.

[0055] Specifically, this data synchronization method is applied to a database system, and the end device 102 is used to send a database operation request to the database system 104, such as a DDL statement.

[0056] Database system 104 includes a primary database and a backup database. The database operation request is a database operation request for the primary database. When it is determined that the primary database has received the database operation request, the database operation request is executed, and the target event corresponding to the database operation request is determined. Before the primary database finishes executing the database operation request, the target event is sent to the backup database corresponding to the primary database. The backup database parses the target event, obtains and executes the database operation request. Based on the first execution result of the primary database executing the database operation request, the second execution result of the backup database executing the database operation request is determined, and the first execution result of the primary database is returned to the end device 102.

[0057] The edge device 102 may include a browser, an app (application), or a web application such as an H5 (Hypertext Markup Language 5) application, a lightweight application (also known as a mini-program), or a cloud application. The edge device can be developed based on a software development kit (SDK) provided by the server, such as a real-time communication (RTC) SDK. The edge device can be deployed in an electronic device and depends on the device's operation or certain apps within the device to run. The electronic device may have a display screen and support information browsing, such as a personal mobile terminal like a mobile phone, tablet, or personal computer. Various other types of applications can also be configured in the electronic device, such as human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, and social media platform software.

[0058] The data synchronization method provided in this disclosure, upon determining that the primary database has received a database operation request, executes the database operation request and determines the target event corresponding to the database operation request; before the primary database completes the execution of the database operation request, the target event is sent to the backup database corresponding to the primary database, and the backup database parses the target event to obtain and execute the database operation request; that is, the same database operation request as in the primary database is parsed and executed in the backup database. By determining the second execution result of the database operation request in the backup database based on the first execution result of the database operation request executed by the primary database, the eventual consistency between the primary and backup databases is ensured. Compared to transmitting log events to the backup database only after the primary database has completed the database operation request, this method reduces the replication delay of the database operation request execution in the backup database by transmitting the target event corresponding to the database operation request to the backup database in advance for replay.

[0059] Referring to Figure 2, which shows a flowchart of a data synchronization method provided in an embodiment of the present disclosure, the method specifically includes the following steps.

[0060] Step 202: If it is determined that the main database has received a database operation request, execute the database operation request and determine the target event corresponding to the database operation request.

[0061] The primary database (hereinafter referred to as the primary database) can be understood as a database instance in the database system that can accept write operations (such as INSERT, UPDATE, DELETE, DDL, etc.). All data changes (such as transactions, DDL operations, etc.) are first executed on the primary database, and then these changes are synchronized to the backup database (hereinafter referred to as the backup database) through a certain mechanism (such as binlog).

[0062] A backup database can be understood as a copy of the primary database, typically used for read-only operations (such as SELECT queries). The backup database maintains data consistency with the primary database by receiving events sent by the primary database and replaying these events. The main function of the backup database is to provide data redundancy and failover capabilities. The essence of an event is an atomic unit of operation, with each event corresponding to an independent operation (such as executing a query statement or modifying a row of data).

[0063] A database operation request can be understood as a request to perform operations on the primary database, including but not limited to adding or deleting database tables. A target event can be understood as the relevant information corresponding to the database operation request. These events are not recorded in the binary file of the primary database, but are stored in the Temp Relaylog of the standby database.

[0064] Specifically, when the primary database receives a DDL operation request, it executes the DDL operation request. Each DDL operation corresponds to a transaction, and each transaction has a unique GTID (Global Transaction Identifier) ​​to identify the transaction. Therefore, the target event corresponding to the DDL operation request can be obtained. This target event not only contains detailed information about the DDL operation, such as the GTID event (Global Transaction Identifier event) and the Query event (query event, recording the DDL statement), but also includes the item event Brr_item_event newly added in this embodiment of the disclosure. Brr_item_event includes Brr_item_event(gtid_executed), which is used to help the standby database determine the replay timing of the DDL operation; for example, DDL operation request 1 will be executed after DDL operation request 2.

[0065] In fact, Brr_item_event also includes Brr_item_event(message), which contains the result information of the primary database's DDL execution (execution successful or failed). The standby database will use this information to decide whether to commit or roll back the DDL operation. It should be noted that because the target event is sent to the standby database while the primary database is executing the database operation request, the result information of the primary database's DDL execution cannot be determined at this time if the primary database has not completed the database operation request. Therefore, the target event does not contain the information of Brr_item_event(message); instead, it is sent to the standby database after the primary database has completed the database operation request and obtained the result information of the primary database's DDL execution.

[0066] In one or more embodiments of this disclosure, the data synchronization method provided does not change the existing data synchronization method. Therefore, after the primary database completes the database operation request, it still records binlog events in the binary file of the primary database and sends the binlog events to the backup database. The backup database records the received binlog events in the relay log file. Specific implementation methods are as follows:

[0067] After determining that the primary database has received a database operation request, and executing the database operation request, the process further includes:

[0068] If the main database completes the database operation request and the execution is successful, the log events related to the database operation request will be stored in the main log file corresponding to the main database.

[0069] The log event is retrieved from the main log file and sent to the backup log file of the backup database.

[0070] Specifically, in existing database systems, data synchronization between the primary and secondary databases is achieved through the transmission and replay of log events. In particular, after the primary database executes a database operation request (such as a DDL operation) and the execution is successful, it records these operations in the primary log file (i.e., binlog). Then, it sends these log events to the secondary database, which records these events in the secondary log file (i.e., relaylog). Finally, data synchronization is achieved by replaying these events.

[0071] The binlog is the binary log file of the master database, used to record all write operations to the master database. Each operation generates one or more log events, such as the GTID Event (Global Transaction Identifier event, used to uniquely identify a transaction) and the Query Event (recording the specific SQL statement, such as INSERT, UPDATE, etc.).

[0072] In fact, after the standby database receives the log events sent by the master database, it writes these events into the Relaylog. The Relaylog is a log file unique to the standby database, used to store the log events received from the master database. The structure of the Relaylog is similar to that of the binlog. The Relaylog is an intermediate file used by the standby database for data synchronization.

[0073] The data synchronization method provided in this embodiment does not change the existing data synchronization method. That is, after the primary database completes the database operation request and the execution is successful, the log events in the corresponding primary log file of the primary database will still be sent to the backup database to ensure data synchronization. This avoids the situation where the data synchronization method provided in this embodiment fails and data synchronization cannot be achieved, resulting in data inconsistency between the primary and backup databases.

[0074] Step 204: Before the primary database completes the database operation request, the target event is sent to the backup database corresponding to the primary database. The backup database is used to parse the target event, obtain and execute the database operation request.

[0075] Specifically, by sending the target event to the backup database, the backup database receives the target event, parses it, understands the operations performed by the primary database, and prepares to replay these operations. That is, by parsing the target event, the SQL statement is extracted, and the corresponding database operations (such as inserting data, updating data, modifying table structure, etc.) are executed based on the parsed SQL statement, thereby maintaining data consistency with the primary database.

[0076] In one or more embodiments of this disclosure, during the execution of the database operation request in the primary database, the target event is sent to the backup database and stored in the backup database's temporary relay log. Specific implementation details are as follows:

[0077] The step of sending the target event to the backup database corresponding to the primary database before the primary database completes the database operation request includes:

[0078] During the execution of the database operation request by the primary database, the target event is sent to the backup database corresponding to the primary database, and the target event is stored in the temporary log cache of the backup database.

[0079] The temporary log cache can be understood as the temporary relay log in the above embodiment. The temporary relay log is a temporary log file in the backup database, used to temporarily store target events received from the primary database until the backup database thread is able to process these events.

[0080] Specifically, when the primary database executes a database operation request, it generates target events. For example, when the primary database executes an ALTER TABLE operation, it generates a GTID Event and a Query Event. These events constitute the target events. The primary database sends these target events to the backup database. After receiving the target events, the backup database stores them in the Temp Relaylog, waiting for further processing.

[0081] It should be noted that the primary database actually sends two sets of events to the standby database. One set is the target event, which is sent to the standby database's Temp Relaylog during the execution of the database operation request on the primary database. The target event includes GTID Event, Query Event, and the newly added item event Brr_item_event. The other set is the log event in the primary log file, which is sent to the standby database's Relaylog after the primary database has completed the database operation request and the execution is successful. The log event includes GTID Event and Query Event.

[0082] The data synchronization method provided in this disclosure transmits the target event corresponding to the database operation request to the standby database in real time. Compared with the existing data synchronization methods, it can apply the target event in the standby database in advance, thereby reducing the replication delay of DDL execution between the primary and standby databases.

[0083] In one or more embodiments of this disclosure, the Temp Relaylog corresponds to a target worker thread. Specifically, the target worker thread obtains the target event from the Temp Relaylog and executes the database operation request corresponding to the target event, thereby enabling the pre-execution of the database operation request in the backup database. Specific implementation details are as follows:

[0084] The step of parsing the target event using the backup database to obtain and execute the database operation request includes:

[0085] Using the target worker thread of the backup database, the target event is obtained from the temporary log cache, the target event is parsed, and the database operation request is obtained and executed.

[0086] The target worker thread can be understood as an additional worker thread (Extra Worker thread) added on the basis of the original worker thread (Worker thread) in this embodiment of the disclosure. This additional worker thread is used to read target events from Temp Relaylog.

[0087] Specifically, the target worker thread in the backup database reads and parses the target events from the Temp Relaylog, extracts the SQL statements and operation information, and executes the corresponding database operations based on the parsed SQL statements. That is, it executes the same database operation requests as the master database to achieve data synchronization.

[0088] The data synchronization method provided in this disclosure adds an extra worker thread on top of the original worker thread, and sets the extra worker thread to read target events from the Temp Relaylog, so as not to affect the logic of the original data synchronization processing, and can also use the extra worker thread to execute the corresponding database operation request while the main database is executing the database operation request.

[0089] In one or more embodiments of this disclosure, to avoid conflicts between the original worker thread and the additional worker thread, database operation requests already executed by the additional worker thread will be skipped by the worker thread. Therefore, a target execution set is needed to coordinate the operations between the additional worker thread and the original worker thread. Specific implementation methods are described below:

[0090] The step of parsing the target event using the backup database to obtain and execute the database operation request includes:

[0091] Using the target worker thread of the backup database, the target event is parsed to obtain the database operation request and the request identifier corresponding to the database operation request;

[0092] When the database operation request is executed using the target worker thread, the request identifier is added to the target execution set of the backup database, wherein the target execution set is used to record the request identifiers of database operation requests that have been executed in the backup database.

[0093] The target execution set can be understood as a set in the backup database (which can be called gt id_set), used to record the request identifiers of database operation requests that have been executed, so as to avoid duplicate execution.

[0094] Specifically, the target worker thread in the backup database reads the target event from the Temp Relaylog, and obtains the database operation request (such as SQL statement) and the corresponding request identifier (such as GTID) by parsing the target event. The target worker thread executes the database operation request and adds the request identifier of the operation to the target execution set to indicate that the operation request has been executed, thereby ensuring that the corresponding database operation request will not be executed repeatedly by the original worker thread.

[0095] In fact, the target worker thread obtains the corresponding database operation request through the Query event and the corresponding request identifier through the GTID event.

[0096] The data synchronization method provided in this disclosure parses target events through a target worker thread, obtains database operation requests and request identifiers, and after executing the operation, adds the request identifier to the target execution set to record the executed operation. The target execution set ensures that the backup database will not execute the same operation repeatedly, thus guaranteeing the accuracy and consistency of data synchronization.

[0097] In one or more embodiments of this disclosure, the target event includes Brr_item_event(gtid_executed), used to determine the replay timing of the database operation request, and to correctly replay the database operation request according to the replay timing, i.e., to execute the database operation request. Specific implementation methods are described below:

[0098] Before executing the database operation request using the target worker thread, the method further includes:

[0099] Using the target worker thread of the backup database, the project events in the target event are parsed to obtain the execution order corresponding to the database operation request;

[0100] The step of using the target worker thread to execute the database operation request includes:

[0101] The database operation request is executed using the target worker thread according to the execution order.

[0102] The execution order can be understood as the order in which the standby database replays the database operation requests in the primary database. This execution order is obtained through the project event Brr_item_event(gtid_executed), meaning that the target event includes Brr_item_event(gtid_executed). This information is used to instruct the standby database to follow the GTID execution order when replaying the operation. gtid_executed represents the set of GTIDs of transactions that have been executed by the primary database. The standby database uses this information to determine when to execute the current database operation request (replay timing).

[0103] Specifically, the target worker thread of the backup database parses the target event, obtains the database operation request through Query event, and obtains the execution order of the database operation request through Brr_item_event(gtid_executed). The target worker thread executes the database operation request according to the execution order to ensure that the operation order of the backup database is consistent with that of the primary database.

[0104] For example, the target worker thread reads the target events corresponding to two different database operation requests from the Temp Relaylog:

[0105] Target event 1: INSERT INTO users(name)VALUES('Alice'); GTID is GTID1.

[0106] Target event 2: UPDATE users SET name='Bob'WHERE id=1; GTID is GTID2.

[0107] In `Brr_item_event(gtid_executed)`, GTID1 occurs before GTID2, therefore the execution order of these two operations is GTID1 before GTID2. Thus, the target worker thread first executes the operation corresponding to GTID1: `INSERT INTO users(name) VALUES('Alice')`; then it executes the operation corresponding to GTID2: `UPDATE users SET name='Bob'WHERE id=1`.

[0108] The data synchronization method provided in this disclosure involves a target worker thread replaying database operation requests corresponding to a target event according to the parsed execution order. This execution order is consistent with the order in which database operation requests are executed in the main database, thus ensuring data consistency between the main and backup databases.

[0109] In one or more embodiments of this disclosure, if the additional worker thread fails to execute the database operation request due to a fault or other reasons, and the target execution set of the backup database does not contain a request identifier corresponding to the database operation request, the existing worker thread is used to execute the database operation request. Specific implementation methods are described below:

[0110] The step of parsing the target event using the backup database to obtain and execute the database operation request includes:

[0111] The log event is retrieved from the backup log file using the backup database's read thread, and then sent to the backup database's original worker thread.

[0112] The original worker thread is used to parse the log events to obtain the database operation request and the request identifier corresponding to the database operation request.

[0113] If it is determined that the request identifier does not exist in the target execution set of the backup database, the database operation request is executed using the original worker thread.

[0114] The backup database read thread can be understood as the SQL thread in the above embodiment, which is used to obtain log events from the relay log; the original worker thread can be understood as the Worker thread in the above embodiment, which is used to parse log events and execute database operation requests.

[0115] Specifically, similar to existing data synchronization methods, the SQL thread of the backup database reads log events from the backup log file (Relaylog) and sends them to the Worker thread. The Worker thread parses the log events to obtain database operation requests (such as SQL statements) and corresponding request identifiers (such as GTID).

[0116] However, before the Worker thread executes the database operation request, the Worker thread needs to check the request identifier. That is, the Worker thread checks the target execution set to confirm whether the request identifier already exists in the target execution set. If the request identifier does not exist in the target execution set of the backup database, the Worker thread will execute the database operation request.

[0117] In practice, if the request identifier does not exist in the target execution set, the worker thread executes the database operation request and adds the request identifier to the target execution set.

[0118] The data synchronization method provided in this disclosure does not affect the processing of the original SQL thread and Worker thread. That is, after the primary database completes the database operation request, it still sends the log events in the binary file to the relay log of the backup database. However, before the Worker thread actually executes the database operation request, by checking the target execution set, it can avoid the duplicate execution of the database operation request by the additional worker thread and the Worker thread.

[0119] In one or more embodiments of this disclosure,

[0120] After using the original worker thread to parse the log events and obtain the database operation request and the request identifier corresponding to the database operation request, the method further includes:

[0121] If the request identifier is found in the target execution set of the backup database, the execution of the database operation request is skipped.

[0122] Specifically, if a request identifier exists in the target execution set of the backup database, it means that the database operation request corresponding to the request identifier has already been processed and executed. Therefore, the Worker thread does not need to execute it again. In this case, the Worker thread skips the execution of the database operation request, thus avoiding the conflict between the extra worker thread and the Worker thread.

[0123] The data synchronization method provided in this disclosure coordinates additional worker threads and worker threads through a target execution set, ensuring that worker threads can skip replaying binlog events in the relaylog.

[0124] Step 206: Based on the first execution result of the database operation request executed by the primary database, determine the second execution result of the database operation request executed by the backup database.

[0125] Specifically, to ensure that the execution results of the backup database are consistent with those of the primary database and to avoid data inconsistencies, the backup database determines the second execution result of the corresponding database operation request based on the first execution result of the primary database.

[0126] In one or more embodiments of this disclosure, to ensure data consistency between the primary and backup databases and to avoid data inconsistency in the backup database due to primary database operation failure, a corresponding second execution result is determined in the backup database based on the first execution result of the primary database. Specific implementation methods are as follows:

[0127] The step of determining the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the primary database includes:

[0128] Obtain the first execution result of the database operation request executed by the primary database, and send the first execution result to the temporary log cache of the backup database;

[0129] Using the target worker thread of the backup database, the first execution result is obtained from the temporary log cache, and based on the first execution result, the second execution result of the backup database executing the database operation request is determined.

[0130] Specifically, after executing a database operation request, the primary database generates an execution result (success or failure) and sends this result to the standby database. Based on the primary database's execution result, the standby database decides whether to commit or roll back the corresponding database operation request. That is, if the primary database executes successfully, the standby database commits the corresponding operation; if the primary database fails, the standby database rolls back the corresponding operation.

[0131] In practical applications, while the target worker thread is executing database operation requests on the primary database and the standby database, once the primary database obtains the first execution result, the target worker thread acquires that result and performs corresponding processing for the corresponding database operation request. Specifically, the target event includes a project event `Brr_item_event(message)`, used to determine the first execution result of the database operation request on the primary database. The target worker thread parses `Brr_item_event(message)` to obtain the first execution result of the database operation request, thereby enabling it to submit or rollback the corresponding database operation request based on `Brr_item_event(message)`.

[0132] By sending the first execution result to the temporary log cache of the backup database, it is ensured that the target worker thread of the backup database can obtain the first execution result from the temporary log cache, and based on the first execution result, the second execution result of the backup database executing the database operation request is determined.

[0133] In fact, because the data synchronization method provided in this embodiment of the present disclosure replays the database operation request in the backup database during the execution of the database operation request in the master database, and the execution result of the master database may be successful or unsuccessful, the second execution result of the database operation request executed by the backup database is determined based on the first execution result of the database operation request executed by the master database.

[0134] In existing data synchronization methods, if the database operation request is successfully executed in the master database, it will be replayed in the standby database. If the execution fails, master-slave replication will not be performed, and the data will not be replayed in the standby database.

[0135] Specifically, the first execution result includes execution success or execution failure, and the second execution result includes execution success or execution failure;

[0136] After determining the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the primary database, the method further includes:

[0137] If the first execution result and the second execution result are successful, the updated primary database and the updated backup database are obtained after the database operation request is executed, wherein the data in the updated primary database and the updated backup database are consistent;

[0138] If the first execution result or the second execution result indicates an execution failure, the database operation requests for the primary database and the backup database shall be rolled back.

[0139] Specifically, if the execution results in both the primary and standby databases are successful, the data in both databases will be updated, ensuring consistency between the updated primary and standby databases. If the execution result in either the primary or standby database is unsuccessful, both databases will roll back the operation to ensure data consistency.

[0140] In practical applications, when the primary database successfully executes a database operation request and the data is updated, the primary database generates the first execution result as "execution successful" and sends this result to the backup database. The backup database then performs the same operation based on the primary database's first execution result, and the data is updated and remains consistent with the primary database.

[0141] If the primary database fails to execute a database operation request (such as a syntax error or constraint conflict), and the data is not updated, the primary database will generate an initial execution result of "execution failed" and send this result to the backup database. The backup database will roll back the operation based on the primary database's initial execution result. That is, since the backup database has already executed the operation in the same way as the primary database, it will roll back the operation. At this point, the data in both the primary and backup databases has not been updated and remains consistent.

[0142] The data synchronization method provided in this disclosure ensures data synchronization between the primary database and the backup database, avoiding data inconsistency due to operation failure.

[0143] The data synchronization method provided in this disclosure reduces the replication delay of DDL execution between the primary and backup by transmitting the target events of DDL to the backup application in advance; the new type of target events used are not recorded in the binlog file, ensuring that the downstream ecosystem that depends on binlog is not affected; and additional worker threads are used to replay DDL, avoiding complex worker thread allocation.

[0144] Referring to Figure 3, Figure 3 shows a flowchart of another data synchronization method provided in an embodiment of the present disclosure, which specifically includes the following steps.

[0145] Step 302: If it is determined that the main database has received a database operation request, execute the database operation request and determine the target log event corresponding to the database operation request. The target log event includes a target event and a log event, and the log event is obtained when the main database has completed the execution of the database operation request.

[0146] Specifically, the primary database sends two events to the standby database. One is the target event, which is sent to the standby database's temporary log cache during the primary database's execution of the database operation request. The other is the log event, which is retrieved from the primary log file and sent to the standby database's standby log file after the primary database has completed the database operation request.

[0147] For detailed implementation methods, please refer to the above embodiments, which will not be repeated here.

[0148] Step 304: Send the target log event to the backup database corresponding to the primary database, and use the target worker thread of the backup database to parse the target event to obtain the database operation request and the request identifier corresponding to the database operation request.

[0149] Step 306: When executing the database operation request using the target worker thread, add the request identifier corresponding to the database operation request to the target execution set of the backup database.

[0150] If the original worker thread of the backup database is used to parse the log events, obtain the request identifier corresponding to the database operation request, and determine that the target execution set contains the request identifier, then the execution of the database operation request is skipped.

[0151] Step 308: Based on the first execution result of the database operation request executed by the primary database, determine the second execution result of the database operation request executed by the backup database.

[0152] For details on the specific implementation of this data synchronization method, please refer to the above embodiments, which will not be repeated here.

[0153] Referring to Figure 4a, Figure 4a shows a schematic diagram comparing the effects provided by an embodiment of the present disclosure.

[0154] Specifically, in the existing master-slave synchronization mechanism of a database, data synchronization between the master database (which can also be regarded as the master node) and the slave database (which can also be regarded as the slave node) is achieved through binlog (binary log). When the master database executes database operations (such as DDL statements), it records these operations in the binlog, forming log events, and transmits them to the slave database via the network after the DDL is executed. After receiving these log events, the slave database writes them to the relay log (relay log), and then the SQL thread of the slave database reads these events and assigns them to the worker threads for replay, thereby achieving data synchronization.

[0155] In this embodiment of the disclosure, for DDL operations, the primary database sends two events to the secondary database:

[0156] Target events (not recorded in the binlog, but sent to the standby database during execution on the primary database): These include GTID events (Global Transaction Identifier events) and Query events, and a new item event, Brr_item_event, which will be written to the standby database's Temp Relaylog.

[0157] Log events (recorded in binlog and sent to the standby database after execution): including GTID events and Query events, which are written to the standby database's Relaylog.

[0158] In this embodiment, the target event of the DDL is sent to the standby database for replay during the execution phase of the DDL in the primary database. After receiving the target event, the standby database uses an additional worker thread to start the replay, achieving the effect of synchronous execution of the DDL by the primary and standby databases. After the primary database finishes executing the DDL, it sends the execution result to the standby database. The standby database performs operations based on the execution result of the primary database. If the primary database fails to execute the DDL, it rolls back the DDL; if the primary database succeeds, it commits the DDL.

[0159] Specifically, an additional worker thread is implemented in the standby database to replay the DDL in real time. The workflow of the additional worker thread and its interaction with the SQL thread and the Worker thread are shown in Figure 4b. Figure 4b shows a schematic diagram of the processing of a data synchronization method provided in an embodiment of this disclosure.

[0160] Referring to the above embodiment, the primary database sends two sets of events to the secondary database. One set of target events is stored in the Temp Relaylog, and the other set of log events is stored in the Relaylog. Compared to the Realylog, the Temp Relaylog adds Brr_item_event(gtid_executed) to help additional worker threads determine the replay timing, and Brr_item_event(message) to contain the primary database's DDL execution results. The target event is sent to the secondary database during the execution of the DDL operation on the primary database, while the log event is sent to the secondary database after the primary database has completed the DDL operation and it has been successfully executed. Therefore, the primary database first sends the target event to the Temp Relaylog, and then sends the log event to the Realylog.

[0161] The additional worker threads in the standby database read target events from the Temp Relaylog and determine the timing of DDL replay based on Brr_item_event(gtid_executed), and replay the DDL. When the additional worker threads replay the DDL, the gtid corresponding to the DDL is added to the target execution set.

[0162] When the primary database completes a DDL operation, the standby database's SQL thread reads binlog events from the Relay log and assigns them to worker threads for replay. The worker thread uses the binlog events to determine the GTID corresponding to the currently processed DDL, checks if that GTID exists in the target execution set, and if it does, skips replaying the DDL; otherwise, it replays it. In other words, the target execution set coordinates the work of additional worker threads and worker threads, ensuring that worker threads can skip replaying the binlog events for that DDL in the Relay log.

[0163] After the primary database completes the DDL execution, it sends the execution result to the standby database. The standby database then populates the execution result into the Brr_item_event(message) field of the Temp Relaylog, allowing additional worker threads to commit or roll back the DDL based on the Brr_item_event(message). In other words, the standby database operates based on the execution result of the primary database. If the primary database's DDL execution fails, the DDL is rolled back in the standby database; if the primary database's execution succeeds, the DDL is committed in the standby database.

[0164] The data synchronization method provided in this disclosure avoids master-slave replication delay caused by DDL by transmitting DDL to the backup database in real time and replaying DDL in real time with an additional worker thread.

[0165] Corresponding to the above method embodiments, this disclosure also provides a data synchronization device embodiment. Figure 5 shows a schematic diagram of the structure of a data synchronization device provided in one embodiment of this disclosure. As shown in Figure 5, the device includes:

[0166] The event determination module 502 is configured to execute the database operation request and determine the target event corresponding to the database operation request when it is determined that the main database has received a database operation request.

[0167] The event replication module 504 is configured to send the target event to the backup database corresponding to the primary database before the primary database finishes executing the database operation request, and use the backup database to parse the target event, obtain and execute the database operation request.

[0168] The result determination module 506 is configured to determine the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the master database.

[0169] Optionally, the event copying module 504 is further configured to:

[0170] During the execution of the database operation request by the primary database, the target event is sent to the backup database corresponding to the primary database, wherein the target event is stored in the temporary log cache of the backup database.

[0171] Optionally, the event copying module 504 is further configured to:

[0172] Using the target worker thread of the backup database, the target event is obtained from the temporary log cache, the target event is parsed, and the database operation request is obtained and executed.

[0173] Optionally, the event copying module 504 is further configured to:

[0174] Using the target worker thread of the backup database, the target event is parsed to obtain the database operation request and the request identifier corresponding to the database operation request;

[0175] When the database operation request is executed using the target worker thread, the request identifier is added to the target execution set of the backup database, wherein the target execution set is used to record the request identifiers of database operation requests that have been executed in the backup database.

[0176] Optionally, the event copying module 504 is further configured to:

[0177] Using the target worker thread of the backup database, the project events in the target event are parsed to obtain the execution order corresponding to the database operation request;

[0178] The database operation request is executed using the target worker thread according to the execution order.

[0179] Optionally, the result determination module 506 is further configured to:

[0180] Obtain the first execution result of the database operation request executed by the primary database, and send the first execution result to the temporary log cache of the backup database;

[0181] Using the target worker thread of the backup database, the first execution result is obtained from the temporary log cache, and based on the first execution result, the second execution result of the backup database executing the database operation request is determined.

[0182] The device further includes:

[0183] The data processing module is configured to, if the first execution result and the second execution result are successful, obtain the updated primary database and the updated backup database after executing the database operation request, wherein the data in the updated primary database and the updated backup database are consistent; if the first execution result and the second execution result are unsuccessful, roll back the database operation request for the primary database and the backup database.

[0184] The device further includes:

[0185] The log event sending module is configured to, when the primary database completes the database operation request and the execution is successful, store the log events related to the database operation request in the primary log file corresponding to the primary database; retrieve the log events from the primary log file and send the log events to the backup log file of the backup database.

[0186] Optionally, the event copying module 504 is further configured to:

[0187] The log event is retrieved from the backup log file using the backup database's read thread, and then sent to the backup database's original worker thread.

[0188] The original worker thread is used to parse the log events to obtain the database operation request and the request identifier corresponding to the database operation request.

[0189] If it is determined that the request identifier does not exist in the target execution set of the backup database, the database operation request is executed using the original worker thread.

[0190] If the request identifier is found in the target execution set of the backup database, the execution of the database operation request is skipped.

[0191] The data synchronization apparatus provided in this disclosure executes a database operation request when the primary database receives such a request, and determines the target event corresponding to the database operation request. During execution, the target event is sent to a backup database corresponding to the primary database. The backup database parses the target event to obtain and execute the database operation request. That is, the same database operation request as the primary database is parsed and executed in the backup database. Based on the first execution result of the primary database executing the database operation request, and determining the second execution result of the backup database executing the database operation request, eventual consistency between the primary and backup databases is ensured. Compared to transmitting log events to the backup database only after the primary database has completed executing the database operation request, transmitting the target event corresponding to the database operation request to the backup database in advance for replay reduces the replication delay of the backup database executing the database operation request.

[0192] The above is an illustrative scheme of a data synchronization device according to this embodiment. It should be noted that the technical solution of this data synchronization device and the technical solution of the data synchronization method described above belong to the same concept. For details not described in detail in the technical solution of the data synchronization device, please refer to the description of the technical solution of the data synchronization method described above.

[0193] Corresponding to the above method embodiments, this disclosure also provides another data synchronization device embodiment. FIG6 shows a schematic diagram of the structure of another data synchronization device provided in an embodiment of this disclosure. As shown in FIG6, the device includes:

[0194] The event determination module 602 is configured to execute the database operation request when it is determined that the main database has received the database operation request, and determine the target log event corresponding to the database operation request. The target log event includes a target event and a log event, and the log event is obtained when the main database has completed the execution of the database operation request.

[0195] The event parsing module 604 is configured to send the target log event to the backup database corresponding to the primary database, and use the target worker thread of the backup database to parse the target event to obtain the database operation request and the request identifier corresponding to the database operation request.

[0196] The event replication module 606 is configured to add the request identifier corresponding to the database operation request to the target execution set of the backup database when the database operation request is executed using the target worker thread, so that when the log event is parsed using the original worker thread of the backup database to obtain the request identifier corresponding to the database operation request, and the target execution set is found to contain the request identifier, the execution of the database operation request is skipped.

[0197] The result determination module 608 is configured to determine the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the master database.

[0198] The above is an illustrative scheme of a data synchronization device according to this embodiment. It should be noted that the technical solution of this data synchronization device and the technical solution of the data synchronization method described above belong to the same concept. For details not described in detail in the technical solution of the data synchronization device, please refer to the description of the technical solution of the data synchronization method described above.

[0199] Figure 7 shows a structural block diagram of a computing device 700 according to an embodiment of the present disclosure. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0200] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., a network interface controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0201] In one embodiment of this disclosure, the aforementioned components of the computing device 700, as well as other components not shown in FIG. 7, may be interconnected, for example, via a bus. It should be understood that the computing device block diagram shown in FIG. 7 is merely for illustrative purposes and is not intended to limit the scope of this disclosure. Those skilled in the art can add or replace other components as needed.

[0202] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 700 can also be a mobile or stationary server.

[0203] The processor 720 is used to execute the following computer program / instructions, which, when executed by the processor, implement the steps of the above-described data synchronization method.

[0204] The various embodiments in this disclosure are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the computing device embodiments are basically similar to the data synchronization method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the data synchronization method embodiments.

[0205] An embodiment of this disclosure also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described data synchronization method.

[0206] The various embodiments in this disclosure are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the computer-readable storage medium embodiments are basically similar to the data synchronization method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the data synchronization method embodiments.

[0207] An embodiment of this disclosure also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described data synchronization method.

[0208] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the data synchronization method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the data synchronization method described above.

[0209] The foregoing has described specific embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

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

[0211] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this disclosure are not limited to the described order of actions, because according to the embodiments of this disclosure, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this disclosure.

[0212] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0213] The preferred embodiments disclosed above are merely illustrative of this disclosure. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments of this disclosure. These embodiments are selected and specifically described in this disclosure to better explain the principles and practical applications of the embodiments of this disclosure, thereby enabling those skilled in the art to better understand and utilize this disclosure. This disclosure is limited only by the claims and their full scope and equivalents.

Claims

1. A data synchronization method, comprising: If it is determined that the main database has received a database operation request, the database operation request is executed, and the target event corresponding to the database operation request is determined; Before the primary database completes the database operation request, the target event is sent to the backup database corresponding to the primary database. The backup database is then used to parse the target event, obtain and execute the database operation request. Based on the first execution result of the database operation request executed by the primary database, the second execution result of the database operation request executed by the backup database is determined.

2. The data synchronization method according to claim 1, characterized in that, The target events include the global transaction identifier event, the query event, and the newly added item event.

3. The data synchronization method according to claim 1 or 2, wherein sending the target event to the backup database corresponding to the primary database before the primary database completes the database operation request includes: During the execution of the database operation request by the primary database, the target event is sent to the backup database corresponding to the primary database, wherein the target event is stored in the temporary log cache of the backup database.

4. The data synchronization method according to claim 3, characterized in that, The temporary log cache is a temporary relay log in the backup database, used to temporarily store the target event received from the primary database until the target worker thread of the backup database processes the target event.

5. The data synchronization method according to any one of claims 1-4, wherein the step of parsing the target event using the backup database to obtain and execute the database operation request includes: Using the target worker thread of the backup database, the target event is obtained from the temporary log cache, the target event is parsed, and the database operation request is obtained and executed.

6. The data synchronization method according to claim 5, characterized in that, The target worker thread is an additional worker thread added to the backup database based on the original worker threads, used to read and process the target event from the temporary log cache.

7. The data synchronization method according to any one of claims 1-6, wherein the step of parsing the target event using the backup database to obtain and execute the database operation request includes: Using the target worker thread of the backup database, the target event is parsed to obtain the database operation request and the request identifier corresponding to the database operation request; When the database operation request is executed using the target worker thread, the request identifier is added to the target execution set of the backup database, wherein the target execution set is used to record the request identifiers of database operation requests that have been executed in the backup database.

8. The data synchronization method according to claim 7, characterized in that, The request identifier is the global transaction identifier of the transaction corresponding to the database operation request, and the target execution set is the set of global transaction identifiers in the backup database, which is used to record the global transaction identifiers corresponding to the executed database operation requests.

9. The data synchronization method according to claim 7 or 8, further comprising, before executing the database operation request using the target worker thread: Using the target worker thread of the backup database, the project events in the target event are parsed to obtain the execution order corresponding to the database operation request; The step of using the target worker thread to execute the database operation request includes: The database operation request is executed using the target worker thread according to the execution order.

10. The data synchronization method according to any one of claims 1-9, wherein determining the second execution result of the backup database executing the database operation request based on the first execution result of the primary database executing the database operation request comprises: Obtain the first execution result of the database operation request executed by the primary database, and send the first execution result to the temporary log cache of the backup database; Using the target worker thread of the backup database, the first execution result is obtained from the temporary log cache, and based on the first execution result, the second execution result of the backup database executing the database operation request is determined.

11. The data synchronization method according to any one of claims 1-10, wherein the first execution result includes execution success or execution failure, and the second execution result includes execution success or execution failure; After determining the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the primary database, the method further includes: If the first execution result and the second execution result are successful, the updated primary database and the updated backup database are obtained after the database operation request is executed, wherein the data in the updated primary database and the updated backup database are consistent; If the first execution result or the second execution result indicates an execution failure, the database operation requests for the primary database and the backup database shall be rolled back.

12. The data synchronization method according to any one of claims 1-11, further comprising, after determining that the master database has received a database operation request and executing the database operation request, the method further includes: If the main database completes the database operation request and the execution is successful, the log events related to the database operation request will be stored in the main log file corresponding to the main database. The log event is retrieved from the main log file and sent to the backup log file of the backup database.

13. The data synchronization method according to claim 12, wherein parsing the target event using the backup database to obtain and execute the database operation request includes: The log event is retrieved from the backup log file using the backup database's read thread, and then sent to the backup database's original worker thread. The original worker thread is used to parse the log events to obtain the database operation request and the request identifier corresponding to the database operation request. If it is determined that the request identifier does not exist in the target execution set of the backup database, the database operation request is executed using the original worker thread.

14. The data synchronization method according to claim 13, after parsing the log events using the original worker thread to obtain the database operation request and the request identifier corresponding to the database operation request, further includes: If the request identifier is found in the target execution set of the backup database, the execution of the database operation request is skipped.

15. A data synchronization method, comprising: If it is determined that the primary database has received a database operation request, the database operation request is executed, and the target log event corresponding to the database operation request is determined. The target log event includes a target event and a log event, and the log event is obtained when the primary database has completed the execution of the database operation request. The target log event is sent to the backup database corresponding to the primary database. The target worker thread of the backup database is used to parse the target event to obtain the database operation request and the request identifier corresponding to the database operation request. When the target worker thread is used to execute the database operation request, the request identifier corresponding to the database operation request is added to the target execution set of the backup database. If the original worker thread of the backup database is used to parse the log events to obtain the request identifier corresponding to the database operation request, and the target execution set is found to contain the request identifier, the execution of the database operation request will be skipped. Based on the first execution result of the database operation request executed by the primary database, the second execution result of the database operation request executed by the backup database is determined.

16. A data synchronization device, comprising: The event determination module is configured to execute the database operation request and determine the target event corresponding to the database operation request when it is determined that the main database has received a database operation request. The event replication module is configured to send the target event to the backup database corresponding to the primary database before the primary database completes the database operation request, and use the backup database to parse the target event, obtain and execute the database operation request. The result determination module is configured to determine the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the primary database.

17. A data synchronization device, comprising: The event determination module is configured to, upon determining that the main database has received a database operation request, execute the database operation request and determine the target log event corresponding to the database operation request, wherein the target log event includes a target event and a log event, and the log event is obtained when the main database has completed executing the database operation request; The event parsing module is configured to send the target log event to the backup database corresponding to the primary database, and use the target worker thread of the backup database to parse the target event to obtain the database operation request and the request identifier corresponding to the database operation request. The event replication module is configured to add the request identifier corresponding to the database operation request to the target execution set of the backup database when the database operation request is executed using the target worker thread. This is so that when the log event is parsed using the original worker thread of the backup database to obtain the request identifier corresponding to the database operation request, and the execution of the database operation request is skipped if the request identifier exists in the target execution set. The result determination module is configured to determine the second execution result of the database operation request executed by the backup database based on the first execution result of the database operation request executed by the primary database.

18. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the data synchronization method according to any one of claims 1 to 15.

19. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the data synchronization method according to any one of claims 1 to 15.

20. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the data synchronization method according to any one of claims 1 to 15.

Images