Data processing method and device

Abstract

This specification provides a data processing method and device, wherein the data processing method includes: receiving a data recovery instruction, wherein the data recovery instruction carries a data recovery time; based on the data recovery instruction, determining the backup data and log files of each data node in a distributed database; based on the data recovery time, determining target backup data and target log data from the backup data and log files of each data node; and performing data recovery on each data node based on the target log data and target backup data of each data node.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a data processing method. Background Art

[0002] With the development of the Internet and database technology, stand-alone databases have developed relatively sophisticated backup and recovery technologies to ensure data security. However, for distributed databases, how to perform backup and recovery at any point in time and ensure data consistency for each node in the distributed database after backup and recovery has become an urgent problem that needs to be solved. Summary of the Invention

[0003] In view of this, the embodiments of this specification provide a data processing method. This specification also relates to a data processing apparatus, a computing device, a computer-readable storage medium, and a computer program to address the technical deficiencies in the prior art.

[0004] According to a first aspect of an embodiment of this specification, there is provided a data processing method, including:

[0005] receiving a data recovery instruction, wherein the data recovery instruction carries a data recovery time;

[0006] Determining backup data and log files for each data node in the distributed database based on the data recovery instruction;

[0007] Based on the data recovery time, determining target backup data and target log data from the backup data and log files of each data node;

[0008] Based on the target log data and target backup data of each data node, data recovery is performed on each data node.

[0009] According to a second aspect of the embodiments of this specification, there is provided a data processing device, including:

[0010] a receiving module configured to receive a data recovery instruction, wherein the data recovery instruction carries a data recovery time;

[0011] A first determining module is configured to determine the backup data and log files of each data node in the distributed database based on the data recovery instruction;

[0012] a second determining module configured to determine target backup data and target log data from the backup data and log files of each data node based on the data recovery time;

[0013] The data recovery module is configured to perform data recovery on each data node based on the target log data and target backup data of each data node.

[0014] According to a third aspect of the embodiments of this specification, a computing device is provided, including:

[0015] memory and processor;

[0016] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of any of the data processing methods are implemented.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of any of the data processing methods are implemented.

[0018] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute any step of the data processing method.

[0019] The data processing method provided in this specification includes: receiving a data recovery instruction, wherein the data recovery instruction carries a data recovery time; based on the data recovery instruction, determining the backup data and log files of each data node in a distributed database; based on the data recovery time, determining target backup data and target log data from the backup data and log files of each data node; and performing data recovery on each data node based on the target log data and target backup data of each data node.

[0020] Specifically, the method is based on a data recovery instruction that carries the data recovery time, and determines the target backup data and target log data corresponding to the data recovery time from the backup data and log files of each data node in the distributed database; and performs data recovery on each data node based on the target log data and target backup data, thereby realizing backup and recovery of the distributed database at any time point, and because the target log data and target backup data correspond to the data recovery time, the data consistency of the distributed database is guaranteed after the backup and recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a schematic diagram of backup and recovery of a distributed database provided in an embodiment of this specification;

[0022] Figure 2This is a processing flow chart of a data processing method for a distributed database backup and recovery scenario provided in an embodiment of this specification;

[0023] Figure 3 This is a flow chart of a data processing method provided in one embodiment of this specification;

[0024] Figure 4 This is a schematic diagram of determining TSO for a distributed transaction in a data processing method provided in an embodiment of this specification;

[0025] Figure 5 This is a schematic diagram of a log file in a data processing method provided in an embodiment of this specification;

[0026] Figure 6 This is a schematic diagram of performing log file pruning based on a verification end time in a data processing method provided in an embodiment of this specification;

[0027] Figure 7 This is a schematic diagram of candidate log data after rollback in a data processing method provided in an embodiment of this specification;

[0028] Figure 8 This is a schematic diagram of converting a recovery time into a timestamp in a data processing method provided in an embodiment of this specification;

[0029] Figure 9 This is a processing flow chart of a data processing method for a distributed database backup and recovery scenario provided in an embodiment of this specification;

[0030] Figure 10 This is a structural diagram of a data processing device provided in one embodiment of this specification;

[0031] Figure 11 This is a structural block diagram of a computing device provided in one embodiment of this specification. DETAILED DESCRIPTION

[0032] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0033] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0034] 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 specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0035] First, the terms involved in one or more embodiments of this specification are explained.

[0036] X-Paxos protocol: consistency consensus protocol.

[0037] Xtrabackup: An online hot backup tool.

[0038] Crash Recovery: Fault recovery process.

[0039] apply: A calling function.

[0040] ACID: The abbreviation of the four basic elements for the correct execution of database transactions. The four basic elements include: atomicity (or indivisibility), consistency (consistency), isolation (isolation, also known as independence), and durability (durability).

[0041] pos information: location information.

[0042] GMS: Metadata Management Service.

[0043] Backup and recovery are essential database capabilities for ensuring data security. For stand-alone databases, backup and recovery technologies are relatively mature and mainly include the following three solutions:

[0044] Logical backup solution: database object-level backup, the backup content is database objects such as tables, indexes, stored procedures, etc., such as MySQLmysqldump.

[0045] Physical backup solution: Database file-level backup, the backup content is the database files on the operating system, such as MySQLXtraBackup.

[0046] Snapshot backup: Use snapshot technology to obtain a fully usable copy of a specified data set. You can then choose to maintain the snapshot only on the local machine, or back up the snapshot data across multiple machines, such as the Veritas File System file system, the Linux LVM volume manager, and the storage subsystem.

[0047] However, for distributed databases, data backup and recovery face many challenges, including: point-in-time recovery (PITR) and global consistency;

[0048] Point-in-time recovery (PITR) is the first challenge to address. PITR refers to the ability to restore a database to any point in the past (in seconds) using a backup set. Databases typically implement PITR using a single-machine full and incremental physical backup method, such as MySQL's XtraBackup + Binlog.

[0049] For distributed databases, since data reading and writing involve multiple data nodes and distributed transactions, during the recovery process at any point, in addition to ensuring the data integrity of a single node, it is also necessary to ensure data consistency across multiple nodes. Figure 1 , Figure 1 Schematic diagram of backup and recovery of a distributed database provided in an embodiment of this specification; wherein, Figure 1 The example in the previous section demonstrates global data consistency through a transfer test. A user's account balance table is distributed across two data nodes (DN1 and DN2). At a certain moment, through a distributed transaction, account C transfers 30 yuan to account A, and account D transfers 20 yuan to account C. If the data nodes are restored to that moment, since restoration at any point in time is only accurate to the second, the restored data may show that accounts A and C have completed the transfer, while accounts B and D have not (as in restoration 1). This creates inconsistencies in the balance data, which is unacceptable to the user. The restored data must be either the state before the transfer or the state after the transfer (as in restoration 2).

[0050] Backups are a frequent database maintenance operation, and daily backups are recommended to ensure data security. Given this high frequency, the backup process must be as lossless as possible. Providing lossless database backups while ensuring data consistency is a challenge.

[0051] Distributed databases store far more data than stand-alone databases, typically in the tens or even hundreds of terabytes. Faced with such enormous data volumes, rapid data backup and recovery becomes a pressing challenge. Furthermore, ensuring that backup and recovery speeds scale linearly with data volume, thereby maintaining a relatively stable backup and recovery time, is a crucial issue. For example, if a distributed database holds 10 TB of data, backing up the database takes one hour. If the data size grows to 100 TB, the backup time should still be around one hour, rather than increasing to 10 hours.

[0052] Based on this, see Figure 2 , Figure 2 This is a processing flow chart of a data processing method for a distributed database backup and recovery scenario provided in an embodiment of this specification; Figure 2 It shows that in the data processing method provided in this specification, each data node (DN) of the distributed database performs backup and recovery at any time point. First, each data node performs a scheduled full backup of the data of the data node and an incremental backup of the log through xtrabackup. When the data node needs to be restored to a certain time point A (accurate to the second level), first find the most recent full backup set of the time point A for data recovery, and the full backup set includes the backup data. For example, in the case where the data node performs a data backup once a day, when a certain time point A is 2021-07-2516:14:21, the full backup set corresponding to the time point A can be the full backup set (backup data) of the data node 2021-07-25.

[0053] Then, from all backup log files of each data node, obtain all binlog files corresponding to the time period from the start time of the full backup set 2021-07-25 00:00:00 to the recovery time point 2021-07-2516:14:21, such as Figure 2 Binlog-06...binlog-12. By applying the events (transactions) recorded in this part of the binlog through the MySQL Crash Recovery process, the distributed database data can be restored to the specified time point A.

[0054] In the above backup and recovery process, the two log files at the head and tail of the log file need to be processed separately. The two log files at the head and tail are binlog-06 and binlog-12.

[0055] Binlog-06: Because data nodes are still being written during a full backup, the log file's position information corresponding to the backup time is recorded and stored in the backup set after the full backup is completed. When applying log files, Binlog-06 starts at the position recorded in the full backup set's position information, discarding any log files before the position.

[0056] Binlog-12: Because the recovery time point is arbitrary, the last data change to be recovered may exist at any position in the log file. Therefore, the last log file, binlog-12, needs to be pruned to remove transactions older than the recovery time point.

[0057] In this specification, a data processing method is provided. This specification also relates to a data processing apparatus, a computing device, a computer-readable storage medium, and a computer program, which are described in detail one by one in the following embodiments.

[0058] See also Figure 3 , Figure 3 A flowchart of a data processing method according to an embodiment of the present invention is shown, which specifically includes the following steps:

[0059] Step 302: Receive a data recovery instruction, wherein the data recovery instruction carries a data recovery time.

[0060] Among them, the data recovery instruction can be understood as an instruction received by the distributed database that can instruct the distributed database to perform backup and recovery, and the data recovery time can be understood as the time point to be restored in the process of implementing any point in time recovery (PITR) of the distributed database; this time point can be set according to the actual application scenario, for example, 2021-07-25 16:14:21.

[0061] In actual applications, before a distributed database receives a data recovery instruction, in order to ensure that the distributed database operates intactly, a lossless backup of the database is performed; and to ensure that the backup and recovery speed increases linearly with the growth of data volume, this is achieved through the following method.

[0062] Before receiving the data recovery instruction, the method further includes:

[0063] Generate processing data based on each data node in the distributed database, determine information to be recorded corresponding to the processing data and a processing time corresponding to the information to be recorded, and add the information to be recorded and the corresponding processing time to a processing log;

[0064] Determine a backup node for each data node in the distributed database, and synchronize the processed data and processing log of each data node to the backup node;

[0065] Based on the backup node of each data node in the distributed database, the processed data in each data node and the processing log corresponding to the processed data are backed up to generate the backup data and log file of each data node.

[0066] Among them, processed data can be understood as the data generated by each data node during the operation process in a distributed database; the information to be recorded can be understood as the transactions generated by the data node; in actual applications, when the data node performs operations such as adding and modifying data, data can be generated, and when the operation is completed, the specific content of the operation will be recorded as a transaction (event) in the log file.

[0067] The processing time can be understood as a timestamp, such as a TSO (TimeStamp Oracle) timestamp. Correspondingly, determining the processing time corresponding to the information to be recorded can be understood as the process of timestamping each transaction of the data node.

[0068] The processing log can be understood as a log file that records the transactions of the data node, that is, binlog.

[0069] In the data processing method provided in this specification, the data node adopts the MySQL three-node X-Paxos protocol, including a master node and a backup node (Follower node). The master node is used for data processing, and the backup node is used to synchronize the data of the master node.

[0070] Backup data can be understood as the backup of data in the data node; log data can be understood as the backup of the log file corresponding to the data node.

[0071] Specifically, before the distributed database receives a data recovery instruction, it first needs to back up the data and logs of each data node in the distributed database. The backup process includes:

[0072] In a distributed database, processing data is generated based on each data node in the distributed database, and information to be recorded corresponding to the processing data is determined; the information to be recorded is marked with the corresponding processing time, and the information to be recorded and the processing time are added to the processing log.

[0073] Determine the backup node corresponding to each data node in the distributed database, and synchronize the processed data and processing log in each data node to the backup node; and based on the backup node of each data node, back up the processed data in each data node and the processing log corresponding to the processed data, thereby generating backup data and log files for each data node.

[0074] For example, the application of the data processing method in the scenario of backing up and restoring a distributed database is used to further explain the generation of backup data and log data for each data node.

[0075] Before a distributed database receives a data recovery instruction, it is necessary to back up the running data and log files in the data nodes. In the embodiments of this specification, different backup methods can be set for the distributed database based on the actual application scenario. For example, xtrabackup can be used to perform a scheduled full backup of the data node data every day, and an incremental backup of the log files of each data node.

[0076] In practice, incremental backup of log files can be understood as incrementally backing up the log data (recorded transactions) in the log files. During the incremental backup of log data, the location information of each backed-up log data is recorded, that is, the POS information of the data node. For example, when backing up the log file on February 3, 2021, it is recorded that the log backup starts from the 1001th log file and continues to the 1500th log file data. This determines the amount of log data backed up and the location information of the log data.

[0077] Specifically, in the implementation of TSO distributed transactions in distributed databases, see Figure 4. Figure 4 FIG. 1 is a schematic diagram of determining TSO for a distributed transaction in a data processing method provided in an embodiment of this specification; Figure 4As shown, to provide externally consistent reads and ensure distributed transaction capabilities at the SI isolation level, distributed transactions adopt a TSO timestamp solution and add a CTS (Commit Timestamp) extension to each data node. Based on this CTS extension, two sequence numbers (timestamps) are defined for each distributed transaction: snapshot_seq, the sequence number at transaction startup (used for snapshot reads), and commit_seq, the sequence number at transaction commit. Therefore, during the start and commit phases of a transaction, the GMS uniformly distributes globally unique and monotonically increasing sequence numbers (TSO timestamps) for the transaction start event (Prepare Event) and the transaction commit event (Commit Event). The data commit timestamp (CTS) is used to determine the currently read data version, i.e., snapshot.cts > data.cts in the figure, ensuring snapshot read capabilities.

[0078] When performing operations such as adding and deleting, each data node in the distributed database will generate running data and the distributed transactions corresponding to the running data, and add a corresponding TSO timestamp to each distributed transaction through GMS.

[0079] The distributed transaction and the corresponding TSO timestamp are added to the log file. In addition to the XA StartEvent (a transaction), XAPrepare Event (a transaction), and XACommit Event (a transaction), a CTS Event (a transaction) is also included to identify the start and commit time of the transaction. This CTS Event stores a specific TSO timestamp.

[0080] After determining the running data and the corresponding log files, the backup node of each data node is determined in the distributed database, and the running data and the corresponding log files of each data node are synchronously copied to the backup node. The running data and log files are backed up in the backup node through xtrabackup, thereby obtaining the backup data and backup log files of each data node.

[0081] In the embodiments of this specification, since the backup operation is primarily performed on the follower nodes of the data node, and since the follower nodes do not handle traffic, the impact of the backup process on the operation of the data node can be basically ignored. In addition, since the backup and recovery operations are performed separately for each data node, no heavy coordination operations are required between the data nodes (mainly the issuance and synchronization of the recovery time point, which is a very lightweight operation). Therefore, when the distributed database is expanded from 10TB (10 DNs) to 100TB (100 DNs), the overall backup and recovery time remains close to the backup and recovery time of a single DN, and will not increase rapidly with the increase in data volume.

[0082] Step 304: Based on the data recovery instruction, determine the backup data and log files of each data node in the distributed database.

[0083] Continuing with the above example, the following further explains how to determine the backup data and log data of each data node in a distributed database based on data recovery instructions.

[0084] When the distributed database receives a data recovery instruction, the backup data and backup log files corresponding to each data node in the distributed database are determined based on the data recovery instruction.

[0085] Step 306: Based on the data recovery time, determine target backup data and target log data from the backup data and log files of each data node.

[0086] The target backup data may be understood as the backup data corresponding to the data recovery time, and the target log data may be understood as the log data (distributed transaction) in the backup log file corresponding to the data recovery time that precisely corresponds to the data recovery time.

[0087] In practical applications, the method of determining target backup data and target log data from the backup data and log data of each data node based on the data recovery time further includes step one and step two.

[0088] Step 1: Determine the backup data corresponding to the data recovery time in each data node as the target backup data of each data node.

[0089] Continuing with the above example, we will further explain how to determine the target backup data of each data node based on the data recovery time. After determining all the backup data corresponding to each data node based on the data recovery instruction, based on the data recovery time, such as 2021-07-2516:14:21; obtain the backup data corresponding to the data recovery time from the backup data, for example, the backup data of 2021-07-25 of each data node; and use the backup data of 2021-07-25 as the target backup data.

[0090] Step 2: Process the log file of each data node based on the data recovery time to obtain target log data of each data node.

[0091] In practical applications, the processing of the log file of each data node based on the data recovery time to obtain the target log data of each data node includes:

[0092] Determining an initial log file corresponding to the data recovery time from the log files of each data node;

[0093] The initial log file is pruned based on the data recovery time to obtain target log data corresponding to each data node.

[0094] The initial log file can be understood as a log file in the backup log file corresponding to the data recovery time.

[0095] Continuing with the above example, we will further explain how to determine the target log data of each data node based on the data recovery time. After determining all the log data corresponding to each data node based on the data recovery instruction, based on the data recovery time, such as 2021-07-2516:14:21; obtain the initial log file corresponding to the data recovery time from all log files. For example, the log file involved in the transactions that occurred on each data node between 2021-07-2500:00:00 and 2021-07-2516:14:21 can be one, and the initial log file is trimmed based on the data recovery time to obtain only the transactions that occurred on each data node in the time period from 2021-07-2500:00:00 to 2021-07-2516:14:21.

[0096] In actual applications, after trimming the initial log file according to the data recovery time, we can also obtain a log file that only contains the transactions that occurred on each data node in the time period from 2021-07-25 00:00:00 to 2021-07-25 16:14:21, and then back up and restore the data node based on this log file.

[0097] In another case, if there are multiple initial log files corresponding to the data recovery time, then the head and tail log files in the multiple log files need to be trimmed to obtain the target log data corresponding to each data node, as shown below.

[0098] The processing of the log file of each data node based on the data recovery time to obtain target log data of each data node includes:

[0099] Determining a log file to be processed corresponding to the data recovery time from the log files of each data node, and obtaining log backup information of the log file;

[0100] Trimming the log file to be processed based on the log backup information to obtain the initial log file of each data node;

[0101] The initial log file is pruned based on the data recovery time to obtain target log data corresponding to each data node.

[0102] The log files to be processed can be understood as a plurality of backup log files corresponding to the data recovery time, and the log backup information can be understood as the POS information of each data node.

[0103] Continuing with the above example, we will further explain how to trim log data based on log backup information and data recovery time to obtain the target log data corresponding to each data node.

[0104] After determining all log data corresponding to each data node based on the data recovery instruction, based on the data recovery time, such as 2021-07-2516:14:21; obtain multiple initial log files corresponding to the data recovery time from all log files, for example, multiple log files involved in transactions that occurred on each data node between 2021-07-2500:00:00 and 2021-07-2516:14:21, such as 3 log files, log file A, log file B, and log file C.

[0105] Obtain the log file POS information for the backup log file. Based on this POS information, determine the transaction corresponding to each data node at 2021-07-25 00:00:00. This is the location of the first backup log data entry on 2021-07-25, and the line in log file A where it is written, for example, line 50. Based on this POS information, prune the log data (transactions) in log file A that are smaller than line 50. This yields the log file to be processed.

[0106] After completing the trimming of the head log file, the tail log file is trimmed based on the data recovery time 2021-07-2516:14:21, and the log records in log file C that are greater than 2021-07-2516:14:21 are trimmed to obtain a log file that only contains transactions that occurred between 2021-07-2500:00:00 and 2021-07-2516:14:21 for each data node.

[0107] In a specific implementation process, the to-be-processed log file is trimmed based on the log backup information to obtain the initial log file of each data node, including:

[0108] Determining target backup information corresponding to the data recovery time from the log backup information, wherein the log backup information includes log backup records at each time point;

[0109] The data to be pruned is determined from the log files to be processed based on the target backup information, and pruned is performed on the pruned data to obtain the initial log file of each data node.

[0110] The log backup information can be understood as the location of each data node's log data backup during the log backup process, that is, the POS information of each data node.

[0111] The target backup information can be understood as the POS information corresponding to the data recovery time in the log backup information. For example, when the data recovery time is 2021-07-2516:14:21, the target backup information can be understood as the log record backed up by each data node on 2021-07-25, starting from line 50 of log A to line 70 of log E.

[0112] Continuing with the above example, the pruned data is pruned based on the target backup information to obtain the initial log data of each data node.

[0113] After determining the log data, the POS information corresponding to the data recovery time 2021-07-25 16:14:21 is determined from the POS information of each data node. For example, the POS information of 2021-07-25 starts from line 50 of log A to line 70 of log E.

[0114] Based on the POS information, the log records before line 50 in log A, that is, the head log file, are determined as data to be pruned, and the data to be pruned is pruned to obtain the initial log file of each data node.

[0115] In an embodiment of the present specification, the target backup information corresponding to the data recovery time is determined from the log backup information, and the data to be pruned determined based on the target backup information is pruned, thereby obtaining the initial log file of each data node, thereby facilitating the subsequent acquisition of the target log data of each data node based on the initial log file.

[0116] In a specific implementation process, before trimming the initial log file based on the data recovery time, the method further includes:

[0117] Calculate the verification termination time based on the data recovery time and the preset transaction processing time;

[0118] Accordingly, the pruning of the initial log file based on the data recovery time to obtain the target log data corresponding to each data node includes:

[0119] The initial log file is pruned based on the data recovery time and the verification termination time to obtain target log data corresponding to each data node.

[0120] The preset transaction processing time can be set according to the actual application scenario, for example, 60 seconds.

[0121] Continuing with the above example, we will further explain how to trim the initial log data based on the data recovery time and verification end time to obtain the target log data corresponding to each data node.

[0122] The logic for pruning log files seems simple. It only compares the data recovery time with the timestamp TSO of each transaction in the log and removes the time in the log file. Although transactions obtain TSO in order, due to factors such as different network delays between nodes, the TSO in the log file of each data node during the actual submission process is not strictly ordered. See Figure 5 , Figure 5 This is a schematic diagram of a log file in a data processing method provided in an embodiment of this specification; Figure 5 As shown in the figure, although the commit TSO (100) of transaction 2 is smaller than that of transaction 3, in the log, this transaction is after the commit event of transaction 3. This disorder problem brings problems to our pruning process, that is, when to terminate the pruning process.

[0123] The conventional clipping logic is to traverse backward one by one, and once the first value greater than the comparison TSO appears, the process can be terminated.

[0124] However, this approach is no longer applicable to the log order described above. For example, if the TSO at the time point we need to recover is 100, and we scan event C3, we find that its TSO is 101, which is greater than 100. However, if the pruning logic is terminated at this point, event C2, which should have been submitted, will be missed.

[0125] How do we determine the termination condition for pruning in such an out-of-order situation? Considering that the binlog out-of-order condition is only short-lived, meaning it doesn't exceed the transaction commit timeout. If the transaction fails to commit after this timeout, it will be rolled back instead of committed. Using this condition, we introduce a new variable (to verify the termination time): stop_tso:

[0126] stop_tso = (recovery time point + transaction timeout (default 60s) + delta)

[0127] Among them: delta is an amplification factor, and 60s is used by default.

[0128] With stop_tso, we can terminate the pruning process when the first event with a value greater than this value appears. For example, see Figure 6 , Figure 6 This is a schematic diagram of a data processing method according to an embodiment of the present specification for pruning log files based on the verification end time; the tso at the recovery time point is 100, but the stop_tso is calculated to be 103. According to this condition, the corresponding log files can be pruned. The effect after pruning is as follows: Figure 6 As shown, all three events P3, C3, and C1 need to be eliminated.

[0129] Specifically, the pruning of the initial log file based on the data recovery time and the verification termination time to obtain the target log data corresponding to each data node includes:

[0130] Obtaining location information and processing time of each piece of log data in the initial log file, and comparing the data recovery time with the processing time of each piece of log data based on the location information;

[0131] Determine whether the processing time of each log data is less than or equal to the data recovery time,

[0132] If so, the log data whose processing time is less than or equal to the data recovery time is determined as candidate log data, and the target log data corresponding to each data node is determined based on the candidate log data.

[0133] If not, the process ends when the processing time is greater than or equal to the verification termination time.

[0134] The position information may be understood as the sorting position of each log data in the log file, and the sorting position is arranged based on the time when the log file is written.

[0135] Continuing with the above example, the initial log data is trimmed based on the data recovery time and the verification end time to obtain the target log data corresponding to each data node. This is further explained.

[0136] After trimming the data to be trimmed in the header log file A among the multiple backup files (log file A, log file B, log file C) corresponding to the recovery time point based on the POS information, the location information of the log data (transactions) recorded in log file A, log file B, and log file C, as well as the TSO timestamp of each transaction, are determined.

[0137] According to the location information of each transaction, the TSO timestamp in the first position is compared with the recovery time point. If the TSO timestamp of the transaction is less than or equal to the recovery time point, the transaction is used as candidate log data; if the TSO timestamp of the transaction is greater than the recovery time point, the transaction is skipped and the TSO timestamp of the next transaction after the transaction is compared with the recovery time point until the TSO timestamp of the transaction is greater than or equal to the verification end time stop_tso.

[0138] After the verification is completed, the target log data corresponding to each data node is determined based on all the candidate log data.

[0139] In practical applications, after the TSO timestamp of a transaction is greater than or equal to the verification termination time stop_tso, all candidate log data can be used as the target log data corresponding to each data node.

[0140] In the embodiments of this specification, candidate log data is determined by comparing the data recovery time with the processing time based on the acquired location information. The target log data corresponding to each data node is then determined based on the candidate log data. This avoids the problem of incorrect log files being trimmed due to out-of-order log data export during log file pruning, further ensuring data consistency at each data node during distributed database backup and recovery.

[0141] See also Figure 6After the log file is trimmed and the data node applies the log file, it is found that although the data has reached a consistent state, transaction 1 has been eliminated because of the corresponding C1 event, but the P1 event is still applied. Although the corresponding data changes cannot be seen in the recovered data because the transaction is not committed, this is considered a suspended transaction in the distributed system. These suspended transactions need to be rolled back using XA Rollback (a rollback method) to prevent the execution of subsequent transactions. The specific process is shown below.

[0142] The determining the target log data corresponding to each data node based on the candidate log data includes:

[0143] S1. Determine whether the data type of the i-th data in the candidate log data is the target type. If so, put the i-th data into the candidate data set as candidate data.

[0144] If not, the candidate data associated with the i-th data in the candidate data set is deleted, where i=1;

[0145] S2. Increment i by 1 and continue to execute step S1 until i is greater than the number of candidate log data;

[0146] S3. Delete the candidate log data corresponding to the candidate data in the candidate data set from the candidate log data to obtain the target log data corresponding to each data node.

[0147] Continuing with the above example, the target log data corresponding to each data node is determined based on the candidate log data to further illustrate that after obtaining the subsequent log data, it is determined whether the data type of the first data in the candidate log data is the target type of log data, such as a Prepare type transaction.

[0148] If so, the transaction is written as candidate data into the candidate data set; if not, it means that the first data is not a Prepare type transaction, but a Commit or Rollback type transaction, then the corresponding Prepare type transaction is found in the candidate data set and the Prepare type transaction is deleted from the set.

[0149] Continue to determine whether the data type of the remaining data in the candidate log data is the target type of log data, and perform the same operation as the first data in the candidate log data until all the candidate log data are determined.

[0150] The candidate log data corresponding to the candidate data in the candidate data set are rolled back, and the candidate log data after the rollback operation is used as the target log data corresponding to each data node.

[0151] See also Figure 7 , Figure 7 1 is a schematic diagram of candidate log data after rollback in a data processing method provided in one embodiment of this specification; it can be seen that after determining that P1 is a suspended event, the event is rolled back.

[0152] In the embodiments of this specification, a determination is made as to whether the data type of the i-th data item in the candidate log data is the target type. If so, the i-th data item is placed in the candidate data set as candidate data. If not, the candidate data associated with the i-th data item in the candidate data set is deleted. Furthermore, if i is greater than the number of candidate log data items, the candidate log data items in the candidate log data set that correspond to the candidate data items in the candidate data set are deleted to obtain the target log data item corresponding to each data node. This avoids the problem of dangling transactions in distributed databases and ensures that the execution of subsequent transactions in the distributed database is not affected.

[0153] In the embodiments of this specification, since the TSO of the transaction is recorded in the log file, when a globally consistent recovery to any time point is required, the time point to be recovered (for example: 2021-07-2516:14:21) is first converted into the corresponding TSO timestamp, and then the log file to be applied to each data node is trimmed based on the TSO timestamp, and the transaction events whose transaction commit sequence number (snapshot_seq) is greater than the TSO timestamp are removed. This ensures that the recovered data does not have inconsistencies caused by partial transaction submissions. The specific method of converting the recovery time point into a TSO timestamp is as follows.

[0154] The trimming of the log data of each data node based on the data recovery time to obtain target log data of each data node includes:

[0155] Converting the data recovery time into a target recovery time, wherein the target recovery time is in the same format as the processing time;

[0156] The log file of each data node is pruned based on the target recovery time to obtain target log data of each data node.

[0157] Continuing with the above example, the target conversion object converts the data recovery time into the target recovery time, and further explains how to trim the log file of each data node based on the target recovery time.

[0158] See also Figure 8 , Figure 8 This is a schematic diagram of converting recovery time into a timestamp in a data processing method provided in an embodiment of this specification. Figure 8 The format of the TSO timestamp is given in Figure 8. As can be seen from Figure 8, the TSO timestamp is a 64-bit number composed of the physical timestamp and the logical timestamp. Considering that PITR only needs to be accurate to the second level, we directly shift the timestamp of the time point to be restored (for example: 2021-07-25 16:14:21) left by 42 bits and fill the remaining low-order 22 bits with all 0s to obtain the corresponding TSO timestamp.

[0159] The log file of each data node is pruned based on the TSO timestamp corresponding to the recovery time point to obtain the target log data of each data node.

[0160] Step 308: Perform data recovery on each data node based on the target log data and target backup data of each data node.

[0161] Continuing with the above example, after determining the target log data and target backup data corresponding to each data node, the distributed database's Crash Recovery process is used to apply the transactions of the target log data based on the target backup data, thereby restoring the data of each data node in the distributed database to the specified point in time.

[0162] The data processing method provided in the embodiments of this specification is based on a data recovery instruction that carries the data recovery time, and determines the target backup data and target log data corresponding to the data recovery time from the backup data and log files of each data node in the distributed database; and performs data recovery on each data node based on the target log data and target backup data, thereby realizing backup and recovery of the distributed database at any time point, and because the target log data and target backup data correspond to the data recovery time, the data consistency of the distributed database is guaranteed after the backup and recovery.

[0163] The following combined Figure 9 , taking the application of the data processing method provided in this specification in the scenario of backing up and restoring a distributed database as an example, the data processing method is further explained. Figure 9 A processing flow chart of a data processing method for a distributed database backup and recovery scenario provided in an embodiment of this specification is shown, which specifically includes the following steps:

[0164] Step 902: Receive a data recovery instruction for a distributed database, wherein the data recovery instruction carries a recovery time point.

[0165] Step 904: Obtain the full backup set corresponding to each data node and the recovery time point in the distributed database, and obtain the backup log file corresponding to each data node from the start time of the full backup set to the recovery time point.

[0166] Step 906: Based on the POS information of the full backup set, determine the data to be pruned from the header log file of the backup log file, and remove the data to be pruned.

[0167] The data to be trimmed is the log record before the POS information in the header log file.

[0168] Step 908: Convert the recovery time into a TSO timestamp, and calculate the verification termination time based on the TSO timestamp and the transaction timeout.

[0169] The transaction timeout period can be set according to the actual application scenario, and this manual does not make specific settings for this, for example, 60 seconds.

[0170] Step 910: Based on the TSO timestamp corresponding to the recovery time and the verification end time, determine the out-of-order log records in the backup log file and remove the out-of-order log records.

[0171] Step 912: Determine the dangling transactions in the backup log file, and remove the dangling transactions to obtain a pruned backup log file.

[0172] Step 914: According to the Crash Recovery process of the distributed database, backup and restore each data node based on the full backup set and the pruned backup log file, and restore the data of each data node to the specified time point.

[0173] The data processing method provided in this specification is based on a data recovery instruction that carries a data recovery time. It determines the target backup data and target log data corresponding to the data recovery time from the backup data and log files of each data node in the distributed database; and performs data recovery on each data node based on the target log data and target backup data, thereby realizing backup and recovery of the distributed database at any time point. Moreover, since the target log data and target backup data correspond to the data recovery time, the data consistency of the distributed database is guaranteed after the backup and recovery.

[0174] Corresponding to the above method embodiment, this specification also provides a data processing device embodiment, Figure 10 FIG1 shows a schematic diagram of the structure of a data processing device provided by an embodiment of this specification. Figure 10 As shown, the device includes:

[0175] The receiving module 1002 is configured to receive a data recovery instruction, wherein the data recovery instruction carries a data recovery time;

[0176] A first determining module 1004 is configured to determine the backup data and log files of each data node in the distributed database based on the data recovery instruction;

[0177] A second determining module 1006 is configured to determine target backup data and target log data from the backup data and log files of each data node based on the data recovery time;

[0178] The data recovery module 1008 is configured to perform data recovery on each data node based on the target log data and target backup data of each data node.

[0179] Optionally, the second determining module 1006 is further configured to:

[0180] Determining the backup data corresponding to the data recovery time in each data node as the target backup data of each data node;

[0181] The log file of each data node is processed based on the data recovery time to obtain target log data of each data node.

[0182] Optionally, the second determining module 1006 is further configured to:

[0183] Determining an initial log file corresponding to the data recovery time from the log files of each data node;

[0184] The initial log file is pruned based on the data recovery time to obtain target log data corresponding to each data node.

[0185] Optionally, the second determining module 1006 is further configured to:

[0186] Determining a log file to be processed corresponding to the data recovery time from the log files of each data node, and obtaining log backup information of the log file;

[0187] Trimming the log file to be processed based on the log backup information to obtain the initial log file of each data node;

[0188] The initial log file is pruned based on the data recovery time to obtain target log data corresponding to each data node.

[0189] Optionally, the second determining module 1006 is further configured to:

[0190] Calculate the verification termination time based on the data recovery time and the preset transaction processing time;

[0191] Accordingly, the pruning of the initial log file based on the data recovery time to obtain the target log data corresponding to each data node includes:

[0192] The initial log file is pruned based on the data recovery time and the verification termination time to obtain target log data corresponding to each data node.

[0193] Optionally, the second determining module 1006 is further configured to:

[0194] Determining target backup information corresponding to the data recovery time from the log backup information, wherein the log backup information includes log backup records at each time point;

[0195] The data to be pruned is determined from the log files to be processed based on the target backup information, and pruned is performed on the pruned data to obtain the initial log file of each data node.

[0196] Optionally, the second determining module 1006 is further configured to:

[0197] Obtaining location information and processing time of each piece of log data in the initial log file, and comparing the data recovery time with the processing time of each piece of log data based on the location information;

[0198] In the case where the processing time of the log data is longer than the data recovery time, all log data longer than the data recovery time is pruned to obtain target log data corresponding to each data node.

[0199] Optionally, the second determining module 1006 is further configured to:

[0200] Obtaining location information and processing time of each piece of log data in the initial log file, and comparing the data recovery time with the processing time of each piece of log data based on the location information;

[0201] Determine whether the processing time of each log data is less than or equal to the data recovery time,

[0202] If so, the log data whose processing time is less than or equal to the data recovery time is determined as candidate log data, and the target log data corresponding to each data node is determined based on the candidate log data.

[0203] If not, the process ends when the processing time is greater than or equal to the verification termination time.

[0204] Optionally, the second determining module 1006 is further configured to:

[0205] S1. Determine whether the data type of the i-th data in the candidate log data is the target type. If so, put the i-th data into the candidate data set as candidate data.

[0206] If not, the candidate data associated with the i-th data in the candidate data set is deleted, where i=1;

[0207] S2. Increment i by 1 and continue to execute step S1 until i is greater than the number of candidate log data;

[0208] S3. Delete the candidate log data corresponding to the candidate data in the candidate data set from the candidate log data to obtain the target log data corresponding to each data node.

[0209] Optionally, the second determining module 1006 is further configured to:

[0210] Converting the data recovery time into a target recovery time, wherein the target recovery time is in the same format as the processing time;

[0211] The log file of each data node is pruned based on the target recovery time to obtain target log data of each data node.

[0212] Optionally, the data processing device further includes a backup module configured to:

[0213] Generate processing data based on each data node in the distributed database, determine information to be recorded corresponding to the processing data and a processing time corresponding to the information to be recorded, and add the information to be recorded and the corresponding processing time to a processing log;

[0214] Determine a backup node for each data node in the distributed database, and synchronize the processed data and processing log of each data node to the backup node;

[0215] Based on the backup node of each data node in the distributed database, the processed data in each data node and the processing log corresponding to the processed data are backed up to generate the backup data and log file of each data node.

[0216] The data processing device provided in the embodiments of this specification determines, based on a data recovery instruction carrying a data recovery time, target backup data and target log data corresponding to the data recovery time from the backup data and log files of each data node in a distributed database; and performs data recovery on each data node based on the target log data and target backup data, thereby realizing backup and recovery of the distributed database at any time point, and because the target log data and target backup data correspond to the data recovery time, the data consistency of the distributed database is guaranteed after the backup and recovery.

[0217] The above is a schematic diagram of a data processing device according to this embodiment. It should be noted that the technical solution of the data processing device and the technical solution of the above-mentioned data processing method are based on the same concept. For details not described in detail in the technical solution of the data processing device, please refer to the description of the technical solution of the above-mentioned data processing method.

[0218] Figure 11 The following is a block diagram of a computing device 1100 according to one embodiment of the present disclosure. Components of the computing device 1100 include, but are not limited to, a memory 1110 and a processor 1120. The processor 1120 is connected to the memory 1110 via a bus 1130, and a database 1150 is used to store data.

[0219] The computing device 1100 also includes an access device 1140 that enables the computing device 1100 to communicate via one or more networks 1060. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 1140 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0220] In one embodiment of the present specification, the above components of the computing device 1100 and Figure 11 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 11 The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art may add or replace other components as needed.

[0221] Computing device 1100 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. Computing device 1100 can also be a mobile or stationary server.

[0222] The processor 1120 is configured to execute computer-executable instructions, which, when executed by the processor 1120 , implement any of the steps of the data processing method.

[0223] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the above-mentioned data processing method are of the same concept. For details not described in detail in the technical scheme of the computing device, please refer to the description of the technical scheme of the above-mentioned data processing method.

[0224] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which can implement any of the steps of the data processing method when executed by a processor.

[0225] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the above-mentioned data processing method are based on the same concept. For details not described in detail in the technical scheme of the storage medium, please refer to the description of the technical scheme of the above-mentioned data processing method.

[0226] An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute any step of the data processing method.

[0227] The above is a schematic scheme of a computer program of this embodiment. It should be noted that the schematic scheme of the computer program and the technical scheme of the above-mentioned data processing method are based on the same concept. For details not described in detail in the schematic scheme of the computer program, please refer to the description of the technical scheme of the above-mentioned data processing method.

[0228] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0229] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0230] It should be noted that for the aforementioned method embodiments, for ease of description, they are all expressed as a series of action combinations. However, those skilled in the art should be aware that this specification is not limited to the order of the actions described, because according to this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this specification.

[0231] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0232] The preferred embodiments disclosed above are intended only to help illustrate this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations are possible based on the content of this specification. These embodiments are selected and described in detail in this specification to better explain the principles and practical applications of this specification, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A data processing method, comprising: receiving a data recovery instruction, wherein the data recovery instruction carries a data recovery time; Determining, based on the data recovery instruction, backup data and log files for each data node in the distributed database, wherein the backup data and log files are obtained from a backup node corresponding to the data node, and the backup node is used to synchronize data of the data node; Based on the data recovery time, determining target backup data and target log data from the backup data and log files of each data node, wherein the target log data is determined according to the data recovery time and a verification termination time, and the verification termination time is determined according to the data recovery time and a preset transaction processing time, where the preset transaction processing time refers to a transaction submission timeout period; Based on the target log data and target backup data of each data node, data recovery is performed on each data node.

2. The data processing method according to claim 1, wherein determining target backup data and target log data from the backup data and log files of each data node based on the data recovery time comprises: Determining the backup data corresponding to the data recovery time in each data node as the target backup data of each data node; The log file of each data node is processed based on the data recovery time to obtain target log data of each data node.

3. The data processing method according to claim 2, wherein the processing of the log file of each data node based on the data recovery time to obtain the target log data of each data node comprises: Determining an initial log file corresponding to the data recovery time from the log files of each data node; The initial log file is pruned based on the data recovery time to obtain target log data corresponding to each data node.

4. The data processing method according to claim 2, wherein the processing of the log file of each data node based on the data recovery time to obtain the target log data of each data node comprises: Determining a log file to be processed corresponding to the data recovery time from the log files of each data node, and obtaining log backup information of the log file; Trimming the log file to be processed based on the log backup information to obtain the initial log file of each data node; The initial log file is pruned based on the data recovery time to obtain target log data corresponding to each data node.

5. The data processing method according to claim 3 or 4, before trimming the initial log file based on the data recovery time, further comprising: Calculate the verification termination time based on the data recovery time and the preset transaction processing time; Accordingly, the pruning of the initial log file based on the data recovery time to obtain the target log data corresponding to each data node includes: The initial log file is pruned based on the data recovery time and the verification termination time to obtain target log data corresponding to each data node.

6. The data processing method according to claim 4, wherein the pruning of the log files to be processed based on the log backup information to obtain the initial log files of each data node comprises: Determining target backup information corresponding to the data recovery time from the log backup information, wherein the log backup information includes log backup records at each time point; The data to be pruned is determined from the log files to be processed based on the target backup information, and pruned is performed on the pruned data to obtain the initial log file of each data node.

7. The data processing method according to claim 3 or 4, wherein the pruning of the initial log file based on the data recovery time to obtain the target log data corresponding to each data node comprises: Obtaining location information and processing time of each piece of log data in the initial log file, and comparing the data recovery time with the processing time of each piece of log data based on the location information; In the case where the processing time of the log data is longer than the data recovery time, all log data longer than the data recovery time is pruned to obtain target log data corresponding to each data node.

8. The data processing method according to claim 5, wherein the pruning of the initial log file based on the data recovery time and the verification termination time to obtain the target log data corresponding to each data node comprises: Obtaining location information and processing time of each piece of log data in the initial log file, and comparing the data recovery time with the processing time of each piece of log data based on the location information; Determine whether the processing time of each log data is less than or equal to the data recovery time, If so, the log data whose processing time is less than or equal to the data recovery time is determined as candidate log data, and the target log data corresponding to each data node is determined based on the candidate log data. If not, the process ends when the processing time is greater than or equal to the verification termination time.

9. The data processing method according to claim 8, wherein determining the target log data corresponding to each data node based on the candidate log data comprises: S1. Determine whether the data type of the i-th data in the candidate log data is the target type. If so, put the i-th data into the candidate data set as candidate data. If not, the candidate data associated with the i-th data in the candidate data set is deleted, where i=1; S2. Increment i by 1 and continue to execute step S1 until i is greater than the number of candidate log data; S3. Delete the candidate log data corresponding to the candidate data in the candidate data set from the candidate log data to obtain the target log data corresponding to each data node.

10. The data processing method according to claim 7, wherein the pruning of the initial log file of each data node based on the data recovery time to obtain the target log data of each data node comprises: Converting the data recovery time into a target recovery time, wherein the target recovery time is in the same format as the processing time; The log file of each data node is pruned based on the target recovery time to obtain target log data of each data node.

11. The data processing method according to claim 1, before receiving the data recovery instruction, further comprising: Generate processing data based on each data node in the distributed database, determine information to be recorded corresponding to the processing data and a processing time corresponding to the information to be recorded, and add the information to be recorded and the corresponding processing time to a processing log; Determine a backup node for each data node in the distributed database, and synchronize the processed data and processing log of each data node to the backup node; Based on the backup node of each data node in the distributed database, the processed data in each data node and the processing log corresponding to the processed data are backed up to generate the backup data and log file of each data node.

12. A data processing device comprising: a receiving module configured to receive a data recovery instruction, wherein the data recovery instruction carries a data recovery time; a first determining module configured to determine, based on the data recovery instruction, backup data and log files of each data node in the distributed database, wherein the backup data and log files are obtained from a backup node corresponding to the data node, and the backup node is used to synchronize data of the data node; a second determining module configured to determine target backup data and target log data from the backup data and log files of each data node based on the data recovery time, wherein the target log data is determined according to the data recovery time and a verification termination time, and the verification termination time is determined according to the data recovery time and a preset transaction processing time, wherein the preset transaction processing time refers to a transaction submission timeout period; The data recovery module is configured to perform data recovery on each data node based on the target log data and target backup data of each data node.

13. A computing device comprising: memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the data processing method according to any one of claims 1 to 11 are implemented.

14. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the steps of the data processing method according to any one of claims 1 to 11.

15. A computer program product, characterized in that The method comprises computer instructions, which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

Images