Data synchronization method, data proxy device and data synchronization system

Abstract

The embodiment of the present application relates to the technical field of database, and discloses a data synchronization method, a data proxy device and a data synchronization system, the method is applied to a data proxy node, the data proxy node manages a plurality of database nodes, the plurality of database nodes include a master database node and at least one slave database node, the method comprises the following steps: a first pre-execution request is sent to the master database node, and when the first pre-execution result of the master database node is successful, a second pre-execution request is sent to the slave database node, when the number of slave database nodes with successful second pre-execution results reaches a preset threshold, a first commit request is sent to the master database node, and when the first commit result of the master database node is successful, a second commit request is sent to the slave database node. Through the above mode, the embodiment of the present application realizes that the data of the master database node and the slave database node is better kept consistent.

Description

Technical Field

[0001] This application relates to the field of database technology, specifically to a data synchronization method, a data proxy device, and a data synchronization system. Background Technology

[0002] In web applications, databases are frequently used to store business data, such as MySQL, Oracle, or SQL Server. In complex systems, deploying only one database application may lead to slow database response or system crashes due to a large number of requests. To ensure high availability, multiple databases are usually deployed to store the same data, such as database master-slave or clustering.

[0003] By configuring master and slave database nodes, in complex systems, the master node is responsible for writing data, while the slave nodes are responsible for reading data. This allows multiple database nodes to share the load and improve performance during periods of high request volume. Currently, master and slave nodes primarily achieve data synchronization through master-slave replication. However, existing master-slave replication is prone to data consistency issues. When writing to the master node, if the master node crashes or fails after committing the transaction, the logs may not be synchronized to the slave nodes, leading to data inconsistency between the master and slave nodes. Summary of the Invention

[0004] In view of the above problems, embodiments of this application provide a data synchronization method, a data proxy device, and a data synchronization system to solve the problem of data inconsistency in the prior art.

[0005] According to one aspect of the embodiments of this application, a data synchronization method is provided, applied to a data proxy node, the data proxy node managing multiple database nodes, the multiple database nodes including a master database node and at least one slave database node, the method comprising:

[0006] Receive a data write request, the data write request including data operation information;

[0007] According to the data write request, a first pre-execution request is sent to the master database node. The first pre-execution request includes the data operation information, so that the master database node performs pre-execution verification on the data operation information according to the first pre-execution request and obtains a first pre-execution result.

[0008] Receive a first pre-execution completion message sent by the master database node, wherein the first pre-execution completion message includes the first pre-execution result;

[0009] When the first pre-execution result is successful, a second pre-execution request is sent to the slave database node according to the data write request. The second pre-execution request includes the data operation information, so that the slave database node performs pre-execution verification on the data operation information according to the second pre-execution request and obtains the second pre-execution result.

[0010] Receive the second pre-execution completion message sent from the database node, the second pre-execution completion message including the second pre-execution result;

[0011] The number of database nodes whose pre-execution result is successful is determined based on the second pre-execution completion message;

[0012] If the number of slave database nodes that are successful according to the second pre-execution result reaches a preset threshold, a first commit request is sent to the master database node. The first commit request includes the data operation information so that the master database node writes data according to the data operation information and obtains the first commit result.

[0013] Receive a first commit completion message sent by the master database node, the first commit completion message including the first commit result;

[0014] If the first submission result is successful, a second submission request is sent to the slave database node. The second submission request includes the data operation information, so that the slave database node writes data according to the data operation information and obtains the second submission result.

[0015] Receive the second commit completion message sent from the database node, the second commit completion message including the second commit result.

[0016] In one alternative approach, receiving the second pre-execution completion message sent from the database node includes:

[0017] Wait for a first preset time, and determine the number of database nodes whose second pre-execution result is successful, corresponding to the second pre-execution completion message received within the first preset time.

[0018] If the number of slave database nodes that are successful according to the second pre-execution result is less than the preset threshold, a rollback request is sent to the master database node and the slave database nodes so that the master database node and the slave database nodes roll back the data operation information according to the rollback request.

[0019] In an alternative embodiment, after receiving the second commit complete message sent from the database node, the method further includes:

[0020] If the second submission result is a failure or the second submission completion message is not received within a second preset time, the identifier corresponding to the database node and the data operation information are recorded in the log document, and the identifier is used to identify each database node.

[0021] In an alternative approach, after receiving the first commit complete message sent by the master database node, the method further includes:

[0022] When the first submission result is successful, it is determined that the slave database node has not received the second pre-execution completion message or the second pre-execution result is failed within the first preset time. The identifier corresponding to the slave database node and the data operation information are recorded in the log document. The identifier is used to identify each database node.

[0023] In an alternative approach, after recording the identifier corresponding to the database node and the data operation information in the log document, the method further includes:

[0024] According to the identifier in the log document, the corresponding data operation information is sent to the corresponding slave database node so that the slave database node can perform data synchronization according to the data operation information;

[0025] Receive the synchronization completion message sent from the database node, the synchronization completion message including the synchronization result and the identifier;

[0026] If the synchronization result is a failure or the synchronization completion message is not received within the first preset time, the above operation is repeated until the synchronization result is a success or the number of repetitions reaches the preset number.

[0027] When the number of repetitions reaches the preset number, if the synchronization result is a failure or the synchronization completion message is not received within the first preset time, the slave database node is marked as faulty.

[0028] In an alternative embodiment, after receiving the data write request, the method further includes:

[0029] Send detection messages to multiple database nodes;

[0030] Receive response messages sent by each of the database nodes, wherein the response messages include identifiers corresponding to each of the database nodes;

[0031] The corresponding database node is marked as normal based on the identifier in the response message;

[0032] If the response message sent by the database node is not received within the fourth preset time, the database node will be marked as faulty.

[0033] The master and slave database nodes are determined based on the priority of the database nodes marked as normal.

[0034] In an alternative approach, after determining the master and slave database nodes based on the priority of the database nodes marked as normal, the method further includes:

[0035] The detection message is periodically sent to each of the database nodes;

[0036] Receive the response messages sent by each of the database nodes;

[0037] The corresponding database node is marked as normal based on the identifier in the response message;

[0038] If the response message sent by the database node is not received within the fourth preset time, the database node will be marked as faulty.

[0039] If no response message is received from the master database node within the fourth preset time, the master database node will be re-determined based on the priority of the database node marked as normal.

[0040] In one alternative approach, after marking the database node as faulty, the method further includes:

[0041] If a slave database node that was marked as faulty is remarked as normal, the corresponding data operation information in the log document is sent to the remarked slave database node according to the identifier of the slave database node, so that the slave database node can perform data synchronization according to the data operation information.

[0042] According to another aspect of the embodiments of this application, a data proxy apparatus is provided. The apparatus is used to manage multiple database nodes, including a master database node and at least one slave database node, comprising:

[0043] A receiving unit is configured to receive a data write request, wherein the data write request includes data operation information;

[0044] The sending unit is configured to send a first pre-execution request to the master database node according to the data write request. The first pre-execution request includes the data operation information, so that the master database node performs pre-execution verification on the data operation information according to the first pre-execution request and obtains a first pre-execution result.

[0045] The receiving unit is further configured to receive a first pre-execution completion message sent by the master database node, wherein the first pre-execution completion message includes the first pre-execution result;

[0046] The sending unit is further configured to send a second pre-execution request to the slave database node according to the data write request when the first pre-execution result is successful. The second pre-execution request includes the data operation information, so that the slave database node performs pre-execution verification on the data operation information according to the second pre-execution request and obtains the second pre-execution result.

[0047] The receiving unit is further configured to receive the second pre-execution completion message sent from the database node, the pre-execution completion message including the second pre-execution result;

[0048] The processing unit is configured to determine the number of slave database nodes whose pre-execution result is successful based on the second pre-execution completion message;

[0049] The sending unit is further configured to send a first submission request to the master database node when the number of slave database nodes whose second pre-execution result is successful reaches a preset threshold. The first submission request includes the data operation information, so that the master database node writes data according to the data operation information and obtains the first submission result.

[0050] The receiving unit is further configured to receive a first commit completion message sent by the master database node, wherein the first commit completion message includes the first commit result;

[0051] The sending unit is further configured to send a second submission request to the slave database node when the first submission result is successful. The second submission request includes the data operation information, so that the slave database node writes data according to the data operation information and obtains the second submission result.

[0052] The receiving unit is further configured to receive the second commit completion message sent from the database node, the second commit completion message including the second commit result.

[0053] According to another aspect of the embodiments of this application, a data synchronization system is provided, the system including a data proxy node and a plurality of database nodes managed by the data proxy node;

[0054] The plurality of database nodes includes one master database node and at least one slave database node;

[0055] The data proxy node is used to receive data write requests, the data write requests including data operation information, and to send a first pre-execution request to the main database node according to the data write requests, the first pre-execution request including the data operation information;

[0056] The master database node is used to receive the first pre-execution request sent by the data proxy node, perform pre-execution verification on the data operation information according to the first pre-execution request, obtain the first pre-execution result, and send a first pre-execution completion message to the data proxy node, wherein the first pre-execution completion message includes the first pre-execution result;

[0057] The data proxy node is also configured to receive the first pre-execution completion message sent by the master database node, and when the first pre-execution result is successful, send a second pre-execution request to the slave database node according to the data write request, wherein the second pre-execution request includes the data operation information;

[0058] The database node is used to receive the second pre-execution request sent by the data proxy node, perform pre-execution verification on the data operation information according to the second pre-execution request, obtain the second pre-execution result, and send a second pre-execution completion message to the data proxy node, wherein the second pre-execution completion message includes the second pre-execution result;

[0059] The data proxy node is also configured to receive the second pre-execution completion message sent by the slave database node, determine the number of slave database nodes whose pre-execution result is successful based on the second pre-execution completion message, and send a first submission request to the master database node when the number of slave database nodes reaches a preset threshold, wherein the first submission request includes the data operation information;

[0060] The master database node is also configured to receive the first submission request sent by the data proxy node, write data according to the data operation information in the first submission request, obtain the first submission result, and send a first submission completion message to the data proxy node, wherein the first submission completion message includes the first submission result;

[0061] The data proxy node is also configured to receive the first commit completion message sent by the master database node, and when the first commit result is successful, send a second commit request to the slave database node, the second commit request including the data operation information;

[0062] The database node is further configured to receive the second submission request sent by the data proxy node, write data according to the data operation information in the second submission request, obtain the second submission result, and send a second submission completion message to the data proxy node, wherein the second submission completion message includes the second submission result;

[0063] The data broker node is also used to receive the second commit completion message sent from the database node.

[0064] The above embodiments manage the master and slave database nodes by setting up data proxy nodes, monitoring and controlling the data synchronization process between them. This eliminates the need for the master database node to initiate data synchronization, reducing its load and accelerating the synchronization process. Furthermore, the data proxy nodes can monitor the data synchronization status of each database node in real time, ensuring greater data consistency between the master and slave nodes. In addition, both the master and slave nodes monitor data operation information before committing it, effectively preventing accidental events and further enhancing data consistency.

[0065] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0066] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0067] Figure 1 This illustration shows a schematic diagram of the interaction process of database master-slave replication involved in an embodiment of this application;

[0068] Figure 2 A schematic diagram of the framework of the data synchronization system provided in an embodiment of this application is shown;

[0069] Figure 3 A flowchart illustrating the data synchronization method provided in an embodiment of this application is shown;

[0070] Figure 4 A flowchart illustrating another data synchronization method provided in an embodiment of this application is shown;

[0071] Figure 5 A schematic diagram of the structure of the data proxy device provided in an embodiment of this application is shown;

[0072] Figure 6 This application provides an embodiment of a data synchronization system with a schematic diagram of the interaction process.

[0073] Figure 7 A schematic diagram of the structure of the data proxy device provided in an embodiment of this application is shown. Detailed Implementation

[0074] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0075] The inventors of this application have noted that in complex systems, to ensure the system can operate normally under heavy requests, multiple databases are typically set up, and database master-slave replication is used to ensure data consistency across these databases. The database can be, but is not limited to, MySQL, Oracle, or SQL Server; this application uses MySQL as an example for illustration. MySQL master-slave replication refers to the replication of data from one MySQL database master node to one or more slave nodes. MySQL master-slave replication is an asynchronous replication process, primarily based on the binary log functionality built into the MySQL database. One or more MySQL databases (slaves) replicate logs from another MySQL database (master), then parse the logs and apply them to themselves, ultimately ensuring data consistency between the slave and master databases.

[0076] Specifically, such as Figure 1 As shown, Figure 1This diagram illustrates the interaction of database master-slave replication according to an embodiment of this application. The master database records data changes in its own binary log. Specifically, when data changes on the master database, the changes are written to the binary log. A dedicated log dump thread is created on the master database to monitor the binary log. When the log dump thread detects a change in the binary log, it notifies the slave node to retrieve the data. The slave database has a dedicated I / O thread to request data from the binary log. When the I / O thread receives a notification from the log dump thread, it requests a certain range of data from the binary log. After retrieving the required range of data from the master database, the slave database writes the data to the relay log. A dedicated SQL thread on the slave database monitors the relay log. When the relay log changes, the SQL thread reads the binary log from the relay log and updates the data, ensuring consistency between the data in the slave and master databases.

[0077] However, during MySQL master-slave replication, data consistency issues may arise due to the asynchronous nature of data transmission. For example, when writing data to the master database, if the master database crashes or fails after committing the data, the contents of the master's binary log may not be synchronized to the slave database's relay log, leading to inconsistencies between the data in the slave and master databases. Furthermore, data synchronization between the master and slave databases is initiated by the master database, with the slave node receiving the data and then saving the updates. This high dependence on the master database means that if the master database experiences certain failures and cannot proactively initiate data synchronization requests to the slave database, inconsistencies will occur between the two databases.

[0078] To address the issue of data inconsistency between the master and slave databases, the inventors of this application, after in-depth research, designed a data synchronization method. This method involves setting up data proxy nodes to manage multiple database nodes, including one master database node and at least one slave database node. Specifically, after obtaining data write information, the data proxy node sends a pre-execution request to the master database node to enable the master database to check the data write information. If the master database passes the check, the data proxy node then sends a pre-execution request to the slave database nodes to enable them to also check the data write information. Only when most slave database nodes pass the check is a commit request sent to the master database node. This process ensures that both the master and slave database nodes can execute the data write information correctly, thereby maintaining data consistency between them. When both the master database node and most slave database nodes fail the check, a commit request is sent to the master database node. Upon successful commit by the master database node, a commit request is sent to the slave database nodes, ensuring that both the master and slave database nodes commit the data write information, thus updating the data across the entire system.

[0079] The above method, by setting up a data proxy node, changes the data synchronization process from being initiated by the master database node to being controlled by the data proxy node, thus reducing the load on the master database node and speeding up the data synchronization. Both the master and slave database nodes first check the data write information before committing, which can better ensure that the data on the master and slave database nodes are consistent.

[0080] like Figure 2 As shown, Figure 2This diagram illustrates the framework of a data synchronization system provided in an embodiment of this application. A data proxy node manages multiple database nodes, including a master database node and at least one slave database node. These database nodes can be, but are not limited to, MySQL, Oracle, SQL Server, etc. The data proxy node can be located on the same server as the one or more database nodes it manages, or it can be located on a separate server. The multiple database nodes can be located separately on different servers, partially on the same server, or all on the same server. The server can be a server including one or more processors. These processors may be a central processing unit (CPU), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this invention; no limitation is made here. The one or more processors included in the server can be of the same type, such as one or more CPUs; or they can be of different types, such as one or more CPUs and one or more ASICs; no limitation is made here. The data proxy node can synchronize data among multiple database nodes and can also elect a master server among multiple database nodes, thereby achieving high availability and fault tolerance of the system. Data proxy nodes are based on the database master-slave replication mechanism. When a master database node fails, it can quickly elect a slave database node as the master database node, solving the single point of failure problem. It can also initiate and complete data synchronization between multiple database nodes without the master database node's participation. By pre-executing and verifying the data operation information before submitting it, it ensures the consistency and reliability of data across multiple database nodes.

[0081] Figure 3 This illustration shows a flowchart of a data synchronization method provided in an embodiment of this application. The method consists of... Figure 2 The data proxy node shown executes. For example... Figure 3 As shown, the method includes the following steps:

[0082] Step 110: Receive a data write request, which includes data operation information.

[0083] Data operation information can include statements that write new data to a database node, statements that modify existing data in a database node, and statements that delete data. Any statement that can modify the existing content in a database node can be used as data operation information, without any restrictions.

[0084] Step 120: Send a first pre-execution request to the master database node according to the data write request. The first pre-execution request includes data operation information so that the master database node can perform pre-execution verification on the data operation information according to the first pre-execution request and obtain the first pre-execution result.

[0085] The first pre-execution request is used to enable the master database node to perform pre-execution verification on the data operation information, that is, to verify whether the data operation information can be executed normally in the database node.

[0086] Step 130: Receive the first pre-execution completion message sent by the master database node. The first pre-execution completion message includes the first pre-execution result.

[0087] Step 140: When the first pre-execution result is successful, a second pre-execution request is sent to the slave database node according to the data write request. The second pre-execution request includes data operation information so that the slave database node can perform pre-execution verification on the data operation information according to the second pre-execution request and obtain the second pre-execution result.

[0088] If the first pre-execution result is successful, it indicates that the master database node can execute the data operation information normally, meaning the master database node can update the data in the master database node according to the data operation information. However, successful pre-execution by the master database node does not guarantee that the data operation information is correct. There may be accidental events that cause the master database node to succeed in pre-execution, but the data operation information contains errors. Therefore, the slave database node also needs to perform pre-execution verification of the data operation information. If the first pre-execution result is unsuccessful, it indicates that the data operation information may contain errors. An error message is directly returned to the application, and the data synchronization operation is terminated.

[0089] Step 150: Receive a second pre-execution completion message sent from the database node. The second pre-execution completion message includes the second pre-execution result.

[0090] Step 160: Determine the number of database nodes whose pre-execution result is successful based on the second pre-execution completion message.

[0091] Due to various reasons (such as network latency, incorrect data operation information, database failure, etc.), the pre-execution verification may fail or not return a pre-execution verification result. Therefore, it is necessary to determine the number of slave database nodes whose pre-execution completion result is successful based on the second pre-execution completion message, so as to determine whether to send the first commit request to the master database node.

[0092] Step 170: If the number of successful slave database nodes reaches a preset threshold, a first commit request is sent to the master database node. The first commit request includes data operation information so that the master database node can write data according to the data operation information and obtain the first commit result.

[0093] The preset threshold is used to determine whether a majority of the slave database nodes can successfully execute data operations and complete data updates. The specific value of the preset threshold can vary; it can be obtained by multiplying the number of slave database nodes by one-half or by multiplying them by two-thirds. The specific value is set according to actual needs. When the number of slave database nodes with a successful second execution result reaches the preset threshold, it indicates that a majority of slave database nodes can successfully execute data operations, meaning the data operations are correct. This effectively avoids accidental events, such as errors in the data operations themselves, while a few database nodes happen to execute them successfully, thus judging the data operations as correct and causing most database nodes to fail to update data, leading to data inconsistency.

[0094] Step 180: Receive the first commit completion message sent by the master database node. The first commit completion message includes the first commit result.

[0095] By checking whether the master database node has successfully committed its data, we can determine whether the slave database nodes need to synchronize data operation information. If the master database node commits successfully, it means that the master database node has completed the data update, and the slave database nodes need to update their data in a timely manner to maintain data consistency. If the master database node commits unsuccessfully, it means that the master database node has not updated its data, and the slave database nodes also do not need to update their data.

[0096] Step 190: If the first commit result is successful, a second commit request is sent to the slave database node. The second commit request includes data operation information so that the slave database node can write data according to the data operation information and obtain the second commit result.

[0097] If the primary database node commits successfully, the secondary database nodes need to update the data promptly to ensure data consistency between the primary and secondary database nodes.

[0098] Step 200: Receive a second commit complete message sent from the database node. The second commit complete message includes the second commit result.

[0099] Due to various reasons (such as network latency, incorrect data operation information, database failure, etc.), the slave database node may fail to submit data operation information or fail to receive the second submission request. In other words, the slave database node may not update the data, resulting in inconsistency between the data on the slave database node and the data on the master database node. It is necessary to record and detect the above-mentioned slave database nodes to prevent the application from obtaining incorrect data from the slave database nodes.

[0100] The above embodiments manage the master and slave database nodes by setting up data proxy nodes, monitoring and controlling the data synchronization process between them. This eliminates the need for the master database node to initiate data synchronization, reducing its load and accelerating the synchronization process. Furthermore, the data proxy nodes can monitor the data synchronization status of each database node in real time, ensuring greater data consistency between the master and slave nodes. In addition, both the master and slave nodes monitor data operation information before committing it, effectively preventing accidental events and further enhancing data consistency.

[0101] In the embodiments of this application, multiple slave database nodes may simultaneously perform pre-execution verification on data operation information. If one of the slave database nodes is blocked, the entire process will be blocked. To avoid abnormalities in the data synchronization operation process due to data node blocking, in some embodiments of this application, step 150 specifically includes:

[0102] Step 151: Wait for a first preset time, and determine the number of successful database nodes corresponding to the second pre-execution completion message received within the first preset time.

[0103] By setting a time threshold, the entire data synchronization process can be prevented from being blocked due to some database nodes. There are multiple ways to set the first preset time, which can be set according to the actual application, and no limitation is made here.

[0104] Step 152: If the number of successful slave database nodes in the second pre-execution result is less than a preset threshold, a rollback request is sent to the master database node and slave database nodes so that the master database node and slave database nodes can roll back the data operation information according to the rollback request.

[0105] If the number of slave database nodes whose second pre-execution result is successful is less than a preset threshold within the first preset time, it means that only a small number of slave database nodes can execute data operation information normally, while most slave database nodes cannot execute data operation information normally. That is, most slave database nodes cannot update data. In order to maintain data consistency, the database nodes whose pre-execution verification is successful need to roll back the data operation information so that the data in the master database node and the slave database nodes are consistent.

[0106] In the above embodiments, data operation information that can be executed normally by the master database node but cannot be executed by most slave database nodes is rolled back. That is, the database nodes that have been pre-executed and successfully verified are rolled back to the state of not executing data operation information, so as to keep the data in the master database node and slave database nodes consistent. By setting a time threshold, the data synchronization process can be executed normally without sending blocking messages.

[0107] When the master data node successfully submits data operation information, if the slave database node fails to submit data operation information normally, inconsistencies will occur between the slave and master database nodes. To ensure data consistency between the slave and master database nodes, in some embodiments of this application, after step 200, the method further includes:

[0108] Step 210a: If the second submission result is a failure or the second submission completion message is not received within the second preset time, the identifier and data operation information corresponding to the database node will be recorded in the log file. The identifier is used to identify each database node.

[0109] If submitting data operation information from a database node fails or does not return a submission result, it indicates that the database node was unable to update the data. This means that the data on the database node is inconsistent with the data on the master database node, suggesting a possible fault in the database node. The data operation information that the database node needs to update should be recorded so that the database node can directly update the data using the data operation information in the log file when it recovers. This effectively avoids data inconsistencies between the database node and the master database node caused by the database node's inability to update data due to faults or network latency.

[0110] When the master database node successfully commits, the slave database nodes that encountered errors during pre-execution verification will be unable to execute data operation information normally, resulting in data inconsistency between the master database node and some slave database nodes. In order to keep the data of the slave database nodes and the master database node consistent, in some embodiments of this application, after step 180, the method further includes:

[0111] Step 210b: When the first submission result is successful, determine the slave database node that has not received the second pre-execution completion message or whose second pre-execution result is failed within the first preset time. Record the identifier and data operation information corresponding to the slave database node in the log file. The identifier is used to identify each database node.

[0112] When the master database node successfully submits data operation information and completes the data update, if a slave database node fails to perform pre-execution verification of the data operation information or does not return a pre-execution verification result within the first preset time, it can be considered that the slave database node may be faulty. It is necessary to record the data operation information that the slave database node needs to update, so that the slave database node can directly update the data through the data operation information in the log file when it recovers to normal. This can effectively avoid the problem of data inconsistency between the slave database node and the master database node caused by the slave database node being unable to execute data operation information to update the data due to failure or network latency.

[0113] Slave database nodes may experience temporary unavailability due to network fluctuations or latency. Directly marking these slave database nodes as faulty would affect the normal operation of the entire system. To ensure system stability, in some embodiments of this application, after step 210a or 210b, the method further includes:

[0114] Step 211: Send the corresponding data operation information to the corresponding slave database node according to the identifier in the log document, so that the slave database node can synchronize data according to the data operation information.

[0115] The slave database node that needs to be synchronized is identified based on the identifier in the log file. The corresponding data operation information is sent to the slave database node, which then updates the relevant data by executing the corresponding data operation information to ensure that the data of the slave database node is consistent with the data of the master database node.

[0116] Step 212: Receive the synchronization completion message sent from the database node. The synchronization completion message includes the synchronization result and an identifier.

[0117] Obtain the results of data synchronization from the database node to determine whether it is necessary to repeatedly send data operation information to the database node to perform data synchronization multiple times, or whether it is necessary to mark the database node as faulty.

[0118] Step 213: If the synchronization result is a failure or a synchronization completion message is not received within the first preset time, repeat the above operation until the synchronization result is a success or the number of repetitions reaches the preset number.

[0119] The preset number of times is the number of times the database node will resynchronize when synchronization fails. It can be set to 3, 4, 5, etc., and can be set according to actual needs. There is no limit here.

[0120] Step 214: When the number of repetitions reaches the preset number, if the synchronization results are all failures or no synchronization completion message is received within the first preset time, the database node will be marked as faulty.

[0121] If the result is still unsuccessful after repeated attempts, the slave database node may be faulty. The slave database node should be marked as faulty and access should be prohibited to prevent erroneous data from being read from the faulty slave database node.

[0122] The above embodiment repeatedly sends data operations from the log document to the slave database node, enabling the slave database node to perform multiple synchronization operations when a failure is possible. Only when multiple synchronization operations fail is the slave database node marked as faulty, rather than directly judging the slave database node as faulty when it cannot complete normal interaction with the data proxy node or cannot update data. This avoids directly judging slave database nodes that are temporarily unusable due to network latency, temporary network outages, etc., as faulty database nodes that cannot be used for a long time, thereby ensuring the stability of the entire system.

[0123] In existing database master-slave replication processes, a single database node is often designated as the fixed master node. When the master node fails, the entire system cannot function properly. To ensure high availability and flexibility of the entire system, some embodiments of this application, such as... Figure 4 As shown, Figure 4 This paper illustrates a flowchart of another data synchronization method provided in an embodiment of this application. After step 110, the method further includes:

[0124] Step 1101: Send detection messages to multiple database nodes.

[0125] The detection message is used to check whether the database node is normal. If the database node is normal, it will return a response message to the data proxy node after receiving the detection message. If the database node is faulty, it will not be able to return a response message to the data proxy node based on the detection message.

[0126] Step 1102: Receive the response messages sent by each database node. The response messages include the identifiers corresponding to each database node.

[0127] The identifier is used to identify database nodes. Based on the identifier included in the response message, it can be determined which database nodes are usable and which are faulty and cannot be used normally.

[0128] Step 1103: Mark the corresponding database node as normal based on the identifier in the response message.

[0129] Step 1104: If no response message is received from the database node within the fourth preset time, the database node is marked as faulty.

[0130] Marking database nodes based on response messages ensures that only healthy database nodes are accessed, thus avoiding the acquisition of incorrect data from faulty database nodes.

[0131] Step 1105: Determine the master database node and slave database node based on the priority of the database nodes marked as normal.

[0132] Among them, the primary database node is determined based on the priority of the database nodes. The primary database node can be a database node with a higher priority or a database node with a lower priority. If there are database nodes with the same priority, the primary database node can also be determined based on their registration time and registration ID on the database proxy node.

[0133] In the above embodiments, the system detects whether the database nodes are usable by detecting messages, and selects one of the usable database nodes as the master database node, instead of directly setting a fixed master database node. This prevents the entire system from failing due to the failure of a fixed master database node, thus improving the availability and flexibility of the entire system. In addition, the determination of the master database node is coordinated by the data proxy node, rather than by the database node's own mechanism, making the master database node selection method simpler and more efficient.

[0134] If the primary database node fails during the data operation process, the data synchronization process will not be able to proceed normally. To ensure that data synchronization can still be performed normally when the primary database node fails, in some embodiments of this application, after step 1105, the method further includes:

[0135] Step 1106: Periodically send detection messages to each database node.

[0136] Periodically check each database node to promptly identify faulty database nodes and prevent applications from retrieving erroneous data from faulty database nodes.

[0137] Step 1107: Receive response messages sent by each database node.

[0138] Step 1108: Mark the corresponding database node as normal based on the identifier in the response message.

[0139] Step 1109: If no response message is received from the database node within the fourth preset time, the database node is marked as faulty.

[0140] Step 1110: If no response message is received from the primary database node within the fourth preset time, the primary database node is re-determined based on the priority of the database nodes marked as normal.

[0141] When the primary database node fails, a new primary database node is selected, and relevant data operations are performed to ensure that the normal database nodes in the system can update data normally, thereby ensuring the high availability of the system.

[0142] During data synchronization, if a slave database node fails, data synchronization cannot proceed normally. When the slave database node recovers, the data on it will differ from the data on the master database node, requiring timely data updates. To enable timely data updates for recovered slave database nodes, in some embodiments of this application, after step 214, the method further includes:

[0143] Step 215: If a slave database node marked as faulty is remarked as normal, the corresponding data operation information in the log file is sent to the remarked slave database node according to the slave database node's identifier, so that the slave database node can synchronize data based on the data operation information.

[0144] When a faulty slave database node recovers, the data operation information that the database node needs to synchronize is sent to the corresponding slave database node according to the information in the log file, so that the slave database node can update the data and ensure that the data of the normal database nodes in the system are consistent.

[0145] Figure 5 A schematic diagram of the structure of a data proxy device provided in an embodiment of this application is shown. According to a second aspect of an embodiment of this application, a data proxy device is provided, such as… Figure 5 As shown, the device 500 includes a receiving unit 501, a sending unit 502, and a processing unit 503. The device 500 is used to manage multiple database nodes, including a master database node and at least one slave database node.

[0146] The receiving unit 501 is used to receive a data write request, which includes data operation information.

[0147] The sending unit 502 is used to send a first pre-execution request to the master database node according to the data write request. The first pre-execution request includes data operation information, so that the master database node performs pre-execution verification on the data operation information according to the first pre-execution request and obtains a first pre-execution result.

[0148] The receiving unit 501 is also configured to receive a first pre-execution completion message sent by the master database node, the first pre-execution completion message including a first pre-execution result;

[0149] Sending unit 502 is also configured to send a second pre-execution request to the slave database node according to the data write request when the first pre-execution result is successful. The second pre-execution request includes data operation information, so that the slave database node performs pre-execution verification on the data operation information according to the second pre-execution request and obtains the second pre-execution result.

[0150] The receiving unit 501 is further configured to receive a second pre-execution completion message sent from the database node, the pre-execution completion message including the second pre-execution result;

[0151] Processing unit 503 is used to determine the number of database nodes whose pre-execution result is successful based on the second pre-execution completion message;

[0152] The sending unit 502 is also used to send a first submission request to the master database node when the number of slave database nodes whose second pre-execution result is successful reaches a preset threshold. The first submission request includes data operation information so that the master database node can write data according to the data operation information and obtain the first submission result.

[0153] The receiving unit 501 is also configured to receive a first commit completion message sent by the master database node, the first commit completion message including the first commit result;

[0154] The sending unit 502 is also configured to send a second submission request to the slave database node when the first submission result is successful. The second submission request includes data operation information so that the slave database node can write data according to the data operation information and obtain the second submission result.

[0155] The receiving unit 501 is also configured to receive a second commit completion message sent from the database node, the second commit completion message including a second commit result.

[0156] The above embodiments manage the master and slave database nodes by setting up data proxy nodes, monitoring and controlling the data synchronization process between them. This eliminates the need for the master database node to initiate data synchronization, reducing its load and accelerating the synchronization process. Furthermore, the data proxy nodes can monitor the data synchronization status of each database node in real time, ensuring greater data consistency between the master and slave nodes. In addition, both the master and slave nodes monitor data operation information before committing it, effectively preventing accidental events and further enhancing data consistency.

[0157] Figure 6 This application illustrates a schematic diagram of the interaction flow of a data synchronization system provided in an embodiment of the present application. According to a third aspect of the embodiments of the present application, a data synchronization system is provided, such as... Figure 6 As shown, the system includes a data proxy node and multiple database nodes managed by the data proxy node. The multiple database nodes include a master database node and at least one slave database node.

[0158] The data broker node is used to receive data write requests, which include data operation information, and to send a first pre-execution request to the main database node based on the data write request. The first pre-execution request also includes data operation information.

[0159] The master database node is used to receive the first pre-execution request sent by the data broker node, perform pre-execution verification on the data operation information according to the first pre-execution request, obtain the first pre-execution result, and send the first pre-execution completion message to the data broker node. The first pre-execution completion message includes the first pre-execution result.

[0160] The data broker node is also used to receive the first pre-execution completion message sent by the master database node, and when the first pre-execution result is successful, to send a second pre-execution request to the slave database node according to the data write request. The second pre-execution request includes data operation information.

[0161] The database node receives the second pre-execution request sent by the data broker node, performs pre-execution verification on the data operation information according to the second pre-execution request, obtains the second pre-execution result, and sends a second pre-execution completion message to the data broker node, which includes the second pre-execution result.

[0162] The data proxy node is also used to receive a second pre-execution completion message sent from the database node, determine the number of database nodes whose pre-execution result is successful based on the second pre-execution completion message, and send a first commit request to the master database node when the number of database nodes reaches a preset threshold. The first commit request includes data operation information.

[0163] The primary database node is also used to receive the first commit request sent by the data broker node, write data according to the data operation information in the first commit request, obtain the first commit result, and send a first commit completion message to the data broker node, which includes the first commit result.

[0164] The data broker node is also used to receive the first commit completion message sent by the master database node, and when the first commit result is successful, send a second commit request to the slave database node. The second commit request includes data operation information.

[0165] The database node is also used to receive a second commit request sent by the data broker node, write data according to the data operation information in the second commit request, obtain the second commit result, and send a second commit completion message to the data broker node, which includes the second commit result.

[0166] The data broker node is also used to receive the second commit complete message sent from the database node.

[0167] The above embodiments manage the master and slave database nodes by setting up data proxy nodes, monitoring and controlling the data synchronization process between them. This eliminates the need for the master database node to initiate data synchronization, reducing its load and accelerating the synchronization process. Furthermore, the data proxy nodes can monitor the data synchronization status of each database node in real time, ensuring greater data consistency between the master and slave nodes. In addition, both the master and slave nodes monitor data operation information before committing it, effectively preventing accidental events and further enhancing data consistency.

[0168] Figure 7 The diagram shows a structural schematic of a data proxy device provided in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the data proxy device.

[0169] like Figure 7 As shown, the data proxy device may include: a processor 402, a communications interface 404, a memory 406, and a communications bus 408.

[0170] The processor 402, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other network elements such as clients or other servers. The processor 402 executes program 410, specifically performing the relevant steps described in the data synchronization method embodiment.

[0171] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0172] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The data proxy device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0173] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0174] Specifically, program 410 can be called by processor 402 to cause the data proxy device to perform the following operations:

[0175] Receive a data write request, which includes data operation information;

[0176] According to the data write request, a first pre-execution request is sent to the master database node. The first pre-execution request includes data operation information, so that the master database node can perform pre-execution verification on the data operation information according to the first pre-execution request and obtain the first pre-execution result.

[0177] Receive the first pre-execution completion message sent by the master database node. The first pre-execution completion message includes the first pre-execution result.

[0178] If the first pre-execution result is successful, a second pre-execution request is sent to the slave database node according to the data write request. The second pre-execution request includes data operation information, so that the slave database node can perform pre-execution verification on the data operation information according to the second pre-execution request and obtain the second pre-execution result.

[0179] Receive a second pre-execution completion message sent from the database node, the second pre-execution completion message including the second pre-execution result;

[0180] The number of database nodes whose pre-execution result was successful is determined based on the second pre-execution completion message;

[0181] If the number of successful slave database nodes reaches a preset threshold, a first commit request is sent to the master database node. The first commit request includes data operation information so that the master database node can write data according to the data operation information and obtain the first commit result.

[0182] Receive the first commit completion message sent by the master database node. The first commit completion message includes the first commit result.

[0183] If the first commit is successful, a second commit request is sent to the slave database node. The second commit request includes data operation information so that the slave database node can write data according to the data operation information and obtain the second commit result.

[0184] Receive a second commit complete message sent from the database node. The second commit complete message includes the second commit result.

[0185] The above embodiments manage the master and slave database nodes by setting up data proxy nodes, monitoring and controlling the data synchronization process between them. This eliminates the need for the master database node to initiate data synchronization, reducing its load and accelerating the synchronization process. Furthermore, the data proxy nodes can monitor the data synchronization status of each database node in real time, ensuring greater data consistency between the master and slave nodes. In addition, both the master and slave nodes monitor data operation information before committing it, effectively preventing accidental events and further enhancing data consistency.

[0186] This application provides a computer-readable storage medium storing executable instructions that, when executed on a data proxy device, cause the data proxy device to perform the data synchronization method described in any of the above method embodiments.

[0187] Specifically, the executable instructions can be used to cause the data proxy device to perform the following operations:

[0188] Receive a data write request, which includes data operation information;

[0189] According to the data write request, a first pre-execution request is sent to the master database node. The first pre-execution request includes data operation information, so that the master database node can perform pre-execution verification on the data operation information according to the first pre-execution request and obtain the first pre-execution result.

[0190] Receive the first pre-execution completion message sent by the master database node. The first pre-execution completion message includes the first pre-execution result.

[0191] If the first pre-execution result is successful, a second pre-execution request is sent to the slave database node according to the data write request. The second pre-execution request includes data operation information, so that the slave database node can perform pre-execution verification on the data operation information according to the second pre-execution request and obtain the second pre-execution result.

[0192] Receive a second pre-execution completion message sent from the database node, the second pre-execution completion message including the second pre-execution result;

[0193] The number of database nodes whose pre-execution result was successful is determined based on the second pre-execution completion message;

[0194] If the number of successful slave database nodes reaches a preset threshold, a first commit request is sent to the master database node. The first commit request includes data operation information so that the master database node can write data according to the data operation information and obtain the first commit result.

[0195] Receive the first commit completion message sent by the master database node. The first commit completion message includes the first commit result.

[0196] If the first commit is successful, a second commit request is sent to the slave database node. The second commit request includes data operation information so that the slave database node can write data according to the data operation information and obtain the second commit result.

[0197] Receive a second commit complete message sent from the database node. The second commit complete message includes the second commit result.

[0198] The above embodiments manage the master and slave database nodes by setting up data proxy nodes, monitoring and controlling the data synchronization process between them. This eliminates the need for the master database node to initiate data synchronization, reducing its load and accelerating the synchronization process. Furthermore, the data proxy nodes can monitor the data synchronization status of each database node in real time, ensuring greater data consistency between the master and slave nodes. In addition, both the master and slave nodes monitor data operation information before committing it, effectively preventing accidental events and further enhancing data consistency.

[0199] This application provides a computer program that can be invoked by a processor to cause a data proxy device to execute the data synchronization method in any of the above method embodiments.

[0200] This application provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed on a computer, cause the computer to perform the data synchronization method described in any of the above method embodiments.

[0201] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0202] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0203] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various aspects of the invention, features of the embodiments of this application are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of this application. However, this method of disclosure should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim.

[0204] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0205] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A data synchronization method, characterized in that, It is applied to a data proxy node, which manages multiple database nodes, including a master database node and at least one slave database node; The method includes: Receive a data write request, the data write request including data operation information; According to the data write request, a first pre-execution request is sent to the master database node. The first pre-execution request includes the data operation information, so that the master database node performs pre-execution verification on the data operation information according to the first pre-execution request and obtains a first pre-execution result. Receive a first pre-execution completion message sent by the master database node, wherein the first pre-execution completion message includes the first pre-execution result; When the first pre-execution result is successful, a second pre-execution request is sent to the slave database node according to the data write request. The second pre-execution request includes the data operation information, so that the slave database node performs pre-execution verification on the data operation information according to the second pre-execution request and obtains the second pre-execution result. Receive the second pre-execution completion message sent from the database node, the second pre-execution completion message including the second pre-execution result; The number of database nodes whose pre-execution result is successful is determined based on the second pre-execution completion message; If the number of slave database nodes that are successful according to the second pre-execution result reaches a preset threshold, a first commit request is sent to the master database node. The first commit request includes the data operation information so that the master database node writes data according to the data operation information and obtains the first commit result. Receive a first commit completion message sent by the master database node, the first commit completion message including the first commit result; If the first submission result is successful, a second submission request is sent to the slave database node. The second submission request includes the data operation information, so that the slave database node writes data according to the data operation information and obtains the second submission result. Receive the second commit completion message sent from the database node, the second commit completion message including the second commit result.

2. The data synchronization method according to claim 1, characterized in that, Receiving the second pre-execution completion message sent from the database node includes: Wait for a first preset time, and determine the number of database nodes whose second pre-execution result is successful, corresponding to the second pre-execution completion message received within the first preset time. If the number of slave database nodes that are successful according to the second pre-execution result is less than the preset threshold, a rollback request is sent to the master database node and the slave database nodes so that the master database node and the slave database nodes roll back the data operation information according to the rollback request.

3. The data synchronization method according to claim 1, characterized in that, After receiving the second commit complete message sent from the database node, the method further includes: If the second submission result is a failure or the second submission completion message is not received within a second preset time, the identifier corresponding to the database node and the data operation information are recorded in the log document, and the identifier is used to identify each database node.

4. The data synchronization method according to claim 2, characterized in that, After receiving the first commit complete message sent by the master database node, the method further includes: When the first submission result is successful, it is determined that the slave database node has not received the second pre-execution completion message or the second pre-execution result is failed within the first preset time. The identifier corresponding to the slave database node and the data operation information are recorded in the log document. The identifier is used to identify each database node.

5. The data synchronization method according to claim 3 or 4, characterized in that, After recording the identifier corresponding to the database node and the data operation information in the log document, the method further includes: According to the identifier in the log document, the corresponding data operation information is sent to the corresponding slave database node so that the slave database node can perform data synchronization according to the data operation information; Receive the synchronization completion message sent from the database node, the synchronization completion message including the synchronization result and the identifier; If the synchronization result is a failure or the synchronization completion message is not received within the first preset time, the above operation is repeated until the synchronization result is a success or the number of repetitions reaches the preset number. When the number of repetitions reaches the preset number, if the synchronization result is a failure or the synchronization completion message is not received within the first preset time, the slave database node is marked as faulty.

6. The data synchronization method according to claim 5, characterized in that, After receiving the data write request, the method further includes: Send detection messages to multiple database nodes; Receive response messages sent by each of the database nodes, wherein the response messages include identifiers corresponding to each of the database nodes; The corresponding database node is marked as normal based on the identifier in the response message; If the response message sent by the database node is not received within the fourth preset time, the database node will be marked as faulty. The master and slave database nodes are determined based on the priority of the database nodes marked as normal.

7. The data synchronization method according to claim 6, characterized in that, After determining the master and slave database nodes based on the priority of the database nodes marked as normal, the method further includes: The detection message is periodically sent to each of the database nodes; Receive the response messages sent by each of the database nodes; The corresponding database node is marked as normal based on the identifier in the response message; If the response message sent by the database node is not received within the fourth preset time, the database node will be marked as faulty. If no response message is received from the master database node within the fourth preset time, the master database node will be re-determined based on the priority of the database node marked as normal.

8. The data synchronization method according to claim 7, characterized in that, After marking the database node as faulty, the process further includes: If a slave database node that was marked as faulty is remarked as normal, the corresponding data operation information in the log document is sent to the remarked slave database node according to the identifier of the slave database node, so that the slave database node can perform data synchronization according to the data operation information.

9. A data proxy device, characterized in that, The device is used to manage multiple database nodes, including a master database node and at least one slave database node; The device includes: A receiving unit is configured to receive a data write request, wherein the data write request includes data operation information; The sending unit is configured to send a first pre-execution request to the master database node according to the data write request. The first pre-execution request includes the data operation information, so that the master database node performs pre-execution verification on the data operation information according to the first pre-execution request and obtains a first pre-execution result. The receiving unit is further configured to receive a first pre-execution completion message sent by the master database node, wherein the first pre-execution completion message includes the first pre-execution result; The sending unit is further configured to send a second pre-execution request to the slave database node according to the data write request when the first pre-execution result is successful. The second pre-execution request includes the data operation information, so that the slave database node performs pre-execution verification on the data operation information according to the second pre-execution request and obtains the second pre-execution result. The receiving unit is further configured to receive the second pre-execution completion message sent from the database node, the pre-execution completion message including the second pre-execution result; The processing unit is configured to determine the number of slave database nodes whose pre-execution result is successful based on the second pre-execution completion message; The sending unit is further configured to send a first submission request to the master database node when the number of slave database nodes whose second pre-execution result is successful reaches a preset threshold. The first submission request includes the data operation information, so that the master database node writes data according to the data operation information and obtains the first submission result. The receiving unit is further configured to receive a first commit completion message sent by the master database node, wherein the first commit completion message includes the first commit result; The sending unit is further configured to send a second submission request to the slave database node when the first submission result is successful. The second submission request includes the data operation information, so that the slave database node writes data according to the data operation information and obtains the second submission result. The receiving unit is further configured to receive the second commit completion message sent from the database node, the second commit completion message including the second commit result.

10. A data synchronization system, characterized in that, The system includes: a data proxy node and multiple database nodes managed by the data proxy node; The plurality of database nodes includes one master database node and at least one slave database node; The data proxy node is used to receive data write requests, the data write requests including data operation information, and to send a first pre-execution request to the main database node according to the data write requests, the first pre-execution request including the data operation information; The master database node is used to receive the first pre-execution request sent by the data proxy node, perform pre-execution verification on the data operation information according to the first pre-execution request, obtain the first pre-execution result, and send a first pre-execution completion message to the data proxy node, wherein the first pre-execution completion message includes the first pre-execution result; The data proxy node is also configured to receive the first pre-execution completion message sent by the master database node, and when the first pre-execution result is successful, send a second pre-execution request to the slave database node according to the data write request, wherein the second pre-execution request includes the data operation information; The database node is used to receive the second pre-execution request sent by the data proxy node, perform pre-execution verification on the data operation information according to the second pre-execution request, obtain the second pre-execution result, and send a second pre-execution completion message to the data proxy node, wherein the second pre-execution completion message includes the second pre-execution result; The data proxy node is also configured to receive the second pre-execution completion message sent by the slave database node, determine the number of slave database nodes whose pre-execution result is successful based on the second pre-execution completion message, and send a first submission request to the master database node when the number of slave database nodes reaches a preset threshold, wherein the first submission request includes the data operation information; The master database node is also configured to receive the first submission request sent by the data proxy node, write data according to the data operation information in the first submission request, obtain the first submission result, and send a first submission completion message to the data proxy node, wherein the first submission completion message includes the first submission result; The data proxy node is also configured to receive the first commit completion message sent by the master database node, and when the first commit result is successful, send a second commit request to the slave database node, the second commit request including the data operation information; The database node is further configured to receive the second submission request sent by the data proxy node, write data according to the data operation information in the second submission request, obtain the second submission result, and send a second submission completion message to the data proxy node, wherein the second submission completion message includes the second submission result; The data broker node is also used to receive the second commit completion message sent from the database node.

Images