Database recovery method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present disclosure provide a database recovery method and device, electronic equipment and storage medium, relating to the field of databases, which can be used in the field of distributed databases, for example. The method comprises: determining a target time to be recovered and an upstream database; obtaining at least one target log record related to the target time from a plurality of log files backed up by the upstream database; determining a downstream storage node corresponding to the target log record; sending each target log record to the corresponding downstream storage node through multiple threads; and storing, by the downstream storage node, a target log record with the largest transaction identifier among a plurality of target log records received for the same row index, based on the transaction identifier in each target log record among the plurality of target log records, so as to restore the downstream database to the upstream database at the target time. The embodiments of the present disclosure improve the efficiency of data recovery.

Description

Technical Field

[0001] This disclosure relates to the field of database technology, and more specifically, to a database recovery method, apparatus, electronic device, and storage medium. Background Technology

[0002] PiTR (Point-in-Time Recovery) is a database recovery method designed to restore a database to a specified point in time. Current technologies typically implement PiTR capabilities by sequentially replaying data logs, resulting in relatively low recovery efficiency. Summary of the Invention

[0003] This disclosure provides a database recovery method, apparatus, electronic device, and storage medium, which can solve the problem of low recovery efficiency in the prior art. The technical solution provided by this disclosure is as follows:

[0004] According to one aspect of the present disclosure, a database recovery method is provided, the method comprising:

[0005] Determine the target time and upstream database to be recovered;

[0006] At least one associated log file related to the target time is obtained from multiple log files backed up through the upstream database; at least one target log record to be recovered is determined from the at least one associated log file; wherein, the log file includes at least one log record for recording the transaction commit operation of a write transaction; the log record includes a transaction identifier corresponding to the write transaction, a row index of the data row targeted by the write transaction, and the current version data corresponding to the write transaction; the transaction identifier includes the transaction number of the write transaction and the transaction commit timestamp of the transaction commit operation of the write transaction; the current version data is the data in the data row after being updated by the write transaction;

[0007] For each target log record, determine the downstream storage node corresponding to the target log record from at least one downstream storage node of the downstream database;

[0008] Each target log record is sent to its corresponding downstream storage node via multiple threads. For each downstream storage node in the downstream database, based on the transaction identifier in each of the multiple target log records with the same row index that have been received, the target log record with the largest transaction identifier is stored, so that the downstream database can be restored to the upstream database at the target time.

[0009] Optionally, each log file corresponds to a file time interval; the file time interval includes the start and end times of recording all log records in the log file;

[0010] The step of obtaining at least one associated log file related to the target time from multiple log files backed up through the upstream database includes:

[0011] Based on the target time, a target database snapshot related to the target time is determined from multiple database snapshots corresponding to the upstream database;

[0012] Based on the generation time of the target database snapshot and the target time, determine the time interval to be restored;

[0013] Based on the file time interval corresponding to each log file and the time interval to be recovered, at least one associated log file is determined from each log file.

[0014] Optionally, determining at least one target log record to be recovered from the at least one associated log file includes:

[0015] For each associated log file, if the file time range of the associated log file is within the time range to be recovered, then all log records in the associated log file will be used as target log records.

[0016] For each associated log file, if the file time interval of the associated log file partially overlaps with the time interval to be recovered, then the transaction commit timestamp of each log record in the associated log file is obtained, and the log record whose transaction commit timestamp is within the time interval to be recovered is taken as the target log record.

[0017] Optionally, the size relationship of the transaction identifiers is determined based on the following method:

[0018] For any two target log records including the first target log record and the second target log record, if the transaction commit timestamp in the first target log record is different from the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between the transaction commit timestamps of the first target log record and the second target log record.

[0019] If the transaction commit timestamp in the first target log record is the same as the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between their respective transaction numbers.

[0020] Optionally, the log record is represented as a key-value pair; the key in the log record includes the row index of the data row targeted by the write transaction and the transaction identifier of the write transaction; the value corresponding to the key in the log record includes the data in the data row after being updated by the write transaction. When at least two data rows targeted by the write transaction are stored on different upstream storage nodes, the transaction identifier of the write transaction in the log record corresponding to the transaction commit operation of the write transaction recorded by each upstream storage node is the same.

[0021] Optionally, each downstream storage node in the downstream database corresponds to at least one data range;

[0022] Determining the downstream storage node corresponding to the target log record from at least one downstream storage node of the downstream database includes:

[0023] Determine the target data range to which the row index corresponding to the target log record belongs from at least one data range corresponding to each downstream storage node;

[0024] The downstream storage node corresponding to the target data range is used as the downstream storage node corresponding to the target log record.

[0025] Optionally, the upstream database includes at least one upstream storage node;

[0026] The log file is generated by each upstream storage node in the upstream database using at least one of the following methods:

[0027] At each preset interval, the set of at least one log record generated within the preset interval is used as the log file corresponding to the upstream storage node;

[0028] When the generated log records meet the preset conditions, the set of log records that meet the preset conditions will be used as the log file corresponding to the upstream storage node; the preset conditions include the number of log records reaching a preset number or the data size of the log records being within a preset data size range.

[0029] According to another aspect of the present disclosure, a database recovery apparatus is provided, the apparatus comprising:

[0030] The data to be recovered determination module is used to determine the target time for recovery and the upstream database to be recovered;

[0031] The target log record determination module is used to obtain at least one associated log file related to the target time from multiple log files backed up through the upstream database; and to determine at least one target log record to be recovered from the at least one associated log file; wherein, the log file includes at least one log record for recording the transaction commit operation of a write transaction; the log record includes a transaction identifier corresponding to the write transaction, a row index of the data row targeted by the write transaction, and the current version data corresponding to the write transaction; the transaction identifier includes the transaction number of the write transaction and the transaction commit timestamp of the transaction commit operation of the write transaction; the current version data is the data in the data row after being updated by the write transaction;

[0032] The downstream storage node determination module is used to determine the downstream storage node corresponding to each target log record from at least one downstream storage node of the downstream database.

[0033] The data recovery module is used to send each target log record to the corresponding downstream storage node through multiple threads. For each downstream storage node in the downstream database, the downstream storage node stores the target log record with the largest transaction identifier based on the transaction identifier in each of the multiple target log records that have been received for the same row index, so that the downstream database can be restored to the upstream database at the target time.

[0034] According to another aspect of the present disclosure, an electronic device is provided, the electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of any of the above-described database recovery methods.

[0035] According to another aspect of the present disclosure, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, implements the steps of any of the database recovery methods described above.

[0036] According to one aspect of the present disclosure, a computer program product is provided, which includes a computer program that, when executed by a processor, implements the steps of any of the database recovery methods described above.

[0037] The beneficial effects of the technical solutions provided in this disclosure are:

[0038] In this embodiment, multiple log files are backed up by an upstream database, and the transaction commit timestamp of each write transaction is recorded in the corresponding log record. Multiple associated log files are selected from the multiple log files, and multiple target log records are determined from the multiple associated log files. Each target log record is restored to its corresponding downstream storage node by multiple threads, realizing out-of-order parallel restoration of physical logs and improving restoration efficiency. By retaining the target log record with the largest transaction identifier among multiple target log records with the same row index in the downstream storage node, the correctness of the data and the consistency of the transaction are guaranteed, thus achieving efficient data recovery. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below.

[0040] Figure 1 A schematic flowchart illustrating a database recovery method provided in this embodiment of the disclosure;

[0041] Figure 2 A schematic diagram of a transaction identifier provided in an embodiment of this disclosure;

[0042] Figure 3 A schematic diagram illustrating a distributed transaction log backup provided in an embodiment of this disclosure;

[0043] Figure 4 A schematic diagram illustrating a distributed transaction log storage and archiving method provided in an embodiment of this disclosure;

[0044] Figure 5 This is a schematic diagram of the structure of a database recovery device provided in an embodiment of the present disclosure;

[0045] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0046] The embodiments of this disclosure are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this disclosure, and do not constitute a limitation on the technical solutions of the embodiments of this disclosure.

[0047] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this disclosure mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element are connected through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term, for example, “A and / or B” or “A, B” indicates implementation as “A,” or implementation as “B,” or implementation as “A and B.”

[0048] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0049] Currently, both single-machine and distributed databases achieve PiTR (Pilot-to-Restore) capabilities by sequentially replaying data logs. Some databases back up logical logs (such as MySQL's Binlog), restoring to a target point in time by sequentially replaying the SQL statements in the logical log. However, the execution of SQL statements is inherently inefficient, and the replay cost is high when dealing with complex transactions. For example, a Binlog containing numerous UPDATE and DELETE operations needs to be executed line by line, resulting in low recovery efficiency.

[0050] Another part of the database backup is the physical log, which is achieved by directly restoring the physical redo log (such as Oceanbase and GaussDB). However, due to the limitations of transaction commit order and transaction consistency, the recovery process can only be executed sequentially according to the log order, resulting in low recovery efficiency.

[0051] The database recovery method, apparatus, electronic device, and storage medium disclosed herein are intended to solve the above-mentioned technical problems of the prior art.

[0052] The following description of several exemplary embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0053] Figure 1 This is a flowchart illustrating a database recovery method provided in an embodiment of the present disclosure, as shown below. Figure 1 As shown, the method includes:

[0054] Step S110: Determine the target time to be recovered and the upstream database to be recovered.

[0055] Specifically, the data recovery method provided in this disclosure can be applied to a downstream database, which corresponds to the upstream database. The upstream database can be the database that needs data recovery, and the downstream database can be a database used to recover data from the upstream database. The system architectures of the upstream and downstream databases can be the same or different; this disclosure does not limit this.

[0056] The target time can be a specified time to which the state of the upstream database needs to be restored. When the data recovery method provided in this embodiment is applied to a disaster recovery scenario, the upstream database can be a database that has experienced data deletion, modification, or other anomalies, and the target time can be the time when the upstream database experienced an anomaly. When the data recovery method provided in this embodiment is applied to a data rollback scenario, the upstream database can be a database that needs to be rolled back, and the target time can be a historical time that needs to be rolled back. This embodiment does not specifically limit the method for determining the target time.

[0057] Step S120: Obtain at least one associated log file related to the target time from multiple log files backed up by the upstream database; determine at least one target log record to be written from the at least one associated log file;

[0058] The log file includes at least one log record for recording the transaction commit operation of a write transaction; the log record includes the transaction identifier of the corresponding write transaction, the row index of the data row targeted by the write transaction, and the current version data corresponding to the row index; the transaction identifier includes the transaction number of the write transaction and the transaction commit timestamp of the write transaction's transaction commit operation; the current version data is the data in the data row after being updated by the write transaction.

[0059] Specifically, multiple log files can be backed up through an upstream database. The upstream database can store data based on a data table, which can include multiple data rows. Each data row corresponds to a row index, which is used to identify the corresponding data row.

[0060] Each log file records the transaction commit operations of write transactions to data in the upstream database. Each log file can include multiple log records, and the log file can be a physical log. Each log record can include the transaction identifier of the corresponding write transaction, the row index of the data row targeted by the write transaction, and the current version data corresponding to that row index. The transaction identifier of the write transaction includes the transaction number of the write transaction and the transaction commit timestamp of the write transaction's commit operation.

[0061] For example, the transaction identifier can be set to a 64-bit integer, with the first 48 bits storing the transaction commit timestamp of the write transaction and the last 16 bits storing the transaction number of the write transaction.

[0062] It's important to note that transaction commit timestamps are typically in the millisecond range. When at least two write transactions commit simultaneously within the same millisecond, the write transaction with the smaller transaction number will have a smaller transaction identifier. When at least two write transactions target the same row index, these write transactions cannot commit simultaneously; one write transaction must commit successfully before the other commits.

[0063] The current version data corresponding to the row index refers to the data in the data row corresponding to the row index after being updated by a write transaction.

[0064] For example, for account A (i.e., row index), the amount in account A (i.e., the data in the data row corresponding to the row index) is updated from 0 to 100 when a user performs a recharge operation of 100 on account A (i.e., write transaction). Then 100 is the current version data corresponding to the row index.

[0065] After determining the target time to be restored, at least one associated log file can be selected from multiple log files of the database backup to be restored based on the target time. The associated log file can be the log file used to restore the upstream data to the target time.

[0066] For example, each log file can correspond to a time information, which may include the time when the log file was generated, the time interval formed by the generation times of all log records in the log file, etc. Based on the time information of each log file, log files generated before the target time will be used as associated log files.

[0067] Each associated log file stores log records within a time interval. Therefore, it is possible that some log records in an associated log file are before the target time, while others are after the target time. Log records before the target time can be selected from at least one associated log file and used as the target log record, thus obtaining at least one target log record.

[0068] Step 130: For each target log record, determine the downstream storage node corresponding to the target log record from at least one downstream storage node in the downstream database.

[0069] Specifically, the upstream database can be a distributed database, which may include multiple upstream storage nodes. The downstream database can also be a distributed database, which may include multiple downstream storage nodes.

[0070] It should be noted that the number of downstream storage nodes in the downstream database can be the same as or different from the number of upstream storage nodes in the upstream database. The number of downstream storage nodes in the downstream database can be adjusted adaptively according to actual resources and needs.

[0071] For each target log record, the correspondence between the row index of the data row and the node identifier of the downstream storage node can be obtained. Based on the determined correspondence, the node identifier of the downstream storage node corresponding to the target log record can be determined, and the downstream storage node with the node identifier is taken as the downstream storage node corresponding to the target log record.

[0072] Optionally, each downstream storage node in the downstream database corresponds to at least one data range;

[0073] From at least one downstream storage node of the downstream database, determine the downstream storage node corresponding to the target log record, including:

[0074] Determine the target data range to which the row index of the target log record belongs from the data range corresponding to each downstream storage node;

[0075] The downstream storage node corresponding to the target data range is used as the downstream storage node corresponding to the target log record.

[0076] Specifically, each storage node in the downstream database can store data based on a data table. Each downstream storage node can correspond to at least one data range, and each downstream storage node is used to store multiple data rows whose row indexes are located within their respective data ranges. For each target log record, the downstream storage node corresponding to the data range to which the row index of the target log record belongs can be used as the downstream storage node for that target log record.

[0077] In this system, all data rows in the upstream database can be distributed and stored across multiple upstream storage nodes according to preset rules. Each upstream storage node can correspond to at least one data range, and each upstream storage node can be used to store data rows whose row indexes fall within their respective data ranges. The allocation method of multiple data rows across the upstream storage nodes in the upstream database can be the same as or different from the allocation method of the downstream storage nodes in the downstream database.

[0078] Step 140: Send each target log record to the corresponding downstream storage node through multiple threads; for each downstream storage node in the downstream database, for the multiple target log records with the same row index that have been received, store the target log record with the largest transaction identifier based on the transaction identifier in each of the multiple target log records, so that the downstream database can be restored to the upstream database at the target time.

[0079] Specifically, after determining the downstream storage node corresponding to each target log record, multiple threads can be used to restore each target log record to the corresponding downstream storage node in parallel.

[0080] Optionally, each downstream storage node can create multiple threads and assign all target log records corresponding to that downstream storage node to the multiple threads respectively. Each thread sends the assigned target log records to the downstream storage node.

[0081] For each downstream storage node in the downstream database, for multiple target log records of the same row index that have been received, the downstream storage node can determine the target log record with the largest transaction identifier from among the target log records, and write the target log record with the largest transaction identifier into the data row corresponding to that row index.

[0082] For multiple target log records with the same row index, the size relationship between the transaction identifiers of the target log records can be determined based on the following method:

[0083] For any two target log records including the first target log record and the second target log record, if the transaction commit timestamp in the first target log record is different from the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between the transaction commit timestamps of the first target log record and the second target log record.

[0084] If the transaction commit timestamp in the first target log record is the same as the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between their respective transaction numbers.

[0085] Specifically, for any two target log records, one is designated as the first target log record, and the other as the second target log record. First, the transaction commit timestamp of the transaction identifier in the first target log record is compared with that in the second target log record. If they are different, the relationship between the transaction identifiers in the first and second target log records is determined based on their relative sizes. Specifically, if the transaction commit timestamp of ID1 is greater than that of ID2, then ID1 is greater than ID2; if the transaction commit timestamp of ID1 is less than that of ID2, then ID1 is less than ID2. In other words, when the transaction commit timestamps of the two transaction identifiers are different, only the relationship between the transaction timestamps needs to be compared; the relationship between the transaction numbers does not need to be compared.

[0086] If the transaction commit timestamp of the transaction identifier in the first target log record is different from that in the second target log record, then the relationship between the transaction identifiers in the first and second target log records is determined based on the size relationship between their respective transaction numbers. Specifically, if the transaction number of ID1 is less than the transaction number of ID2, then ID1 is less than ID2; otherwise, if the transaction number of ID1 is greater than the transaction number of ID2, then ID1 is greater than ID2.

[0087] Based on the relationship between the transaction commit timestamp and the transaction number in the transaction identifier, the size relationship of the transaction identifiers can be compared, so that the determined transaction identifiers have the ability to be compared, and it is guaranteed that the transaction identifier with the larger transaction commit timestamp will also be larger.

[0088] In this embodiment, multiple target log records can be restored in parallel and out of order. Each downstream storage node sorts the transaction identifiers of multiple target log records based on the same row index and finally retains the target log record with the largest transaction identifier. The target log record with the largest transaction identifier records the latest write transaction executed on the data row of the index before the target time, which is the latest data state of the data row of the index at the target time. When each downstream storage node in the downstream database restores each data row in the upstream database to the latest data state at the target time, the downstream database is restored to the upstream database at the target time.

[0089] Optionally, for each downstream storage node, the downstream storage node can store the received target log records corresponding to the same row index in reverse order, so that the target log record with the largest transaction identifier is ultimately retained.

[0090] For example, each time a downstream storage node receives a target log record, it can use the row index of that target log record as the first row index. It then sorts the received target log records for that first row index in descending order of transaction identifier, determining the storage order. Multiple target log records are stored based on this storage order, where a larger transaction identifier is stored earlier. Each time the downstream storage node receives a new target log record, it can reorder the multiple target log records for the same row index, ensuring that the target log record with the largest transaction identifier is always stored first. After all target log records for a row index have been restored, the data for that row index closest to the target time can be retrieved most quickly.

[0091] In addition, the downstream storage node can reclaim target log records that are stored later in the same row index. For example, it can reclaim target log records other than those with the largest transaction identifier to avoid wasting storage resources.

[0092] In this embodiment, multiple log files are backed up by an upstream database, and the transaction commit timestamp of each write transaction is recorded in the corresponding log record. Multiple associated log files are selected from the multiple log files, and multiple target log records are determined from the multiple associated log files. Each target log record is restored to its corresponding downstream storage node by multiple threads, realizing out-of-order parallel restoration of physical logs and improving restoration efficiency. By retaining the target log record with the largest transaction identifier among multiple target log records with the same row index in the downstream storage node, the correctness of the data and the consistency of the transaction are guaranteed, thus achieving efficient data recovery.

[0093] As an optional implementation, each log file corresponds to a file time interval; the file time interval includes the start and end times of all log records in the log file;

[0094] Retrieve at least one associated log file related to the target time from multiple log files backed up via an upstream database, including:

[0095] Based on the target time, determine the target database snapshot related to the target time from multiple database snapshots corresponding to the upstream database;

[0096] Based on the generation time and target time of the target database snapshot, determine the time interval to be restored;

[0097] Based on the file time interval and the time interval to be recovered for each log file, at least one associated log file is determined from each log file.

[0098] Specifically, after obtaining multiple backed-up log files, at least one associated log file can be selected from the multiple log files based on the target time. The associated log file can be the log file used to restore the data to be recovered to the target time.

[0099] It can combine full backup data and incremental log data to restore the database to a specified target time by replaying the incremental logs, based on the restoration of the full backup data. It can save database snapshots of the upstream database at preset intervals, resulting in multiple versions of database snapshots. The version information of each database snapshot can be represented by its generation time. Based on the target time, it can select the database snapshot whose generation time is before the target time and is closest to the target time from the multiple database snapshots corresponding to the upstream data as the target database snapshot.

[0100] Each log file corresponds to a file time interval, which can include the start and end times of all log records generated in that log file. For example, the file time interval of a log file can be represented as {start_time=2025 / 01 / 01 / 3:30, end_time=2025 / 01 / 01 / 5:30}.

[0101] Optionally, for each log file, the file time range corresponding to the log file can be obtained based on the file name of the log file; metadata can also be obtained, which records the file information of each log file, including the file time range, and the file time range corresponding to each log file can be obtained from the metadata.

[0102] After determining the target database snapshot, the time range between the snapshot's creation time and the target time can be used as the recovery time interval. Based on the file time intervals and recovery time intervals corresponding to each log file, log files whose file time intervals overlap with the recovery time intervals are designated as associated log files.

[0103] For example, if the time interval to be recovered is [T1, T2], and the time interval corresponding to the log file is [t_start, t_end], then if [t_start, t_end] is within [T1, T2], that is, t_start is greater than T1 and t_end is less than T2, then the log file is considered an associated log file; if [t_start, t_end] partially overlaps with [T1, T2], for example, t_start is less than T1 and t_end is greater than T1 and less than T2, or t_start is greater than T1 and less than T2 and t_end is greater than T2, then the log file is considered an associated log file.

[0104] In this embodiment of the disclosure, a target database snapshot related to the target time is determined from multiple database snapshots corresponding to the upstream database based on the target time. The time interval to be recovered is determined based on the generation time of the target database snapshot, and then multiple associated log files are determined. By combining the database snapshot and the associated log files to achieve incremental recovery, the recovery efficiency is further improved.

[0105] As an optional embodiment, determining at least one target log record to be recovered from at least one associated log file includes:

[0106] For each associated log file, if the file time range of the associated log file is within the time range to be recovered, then all log records in the associated log file will be used as the target log records.

[0107] For each associated log file, if the file time range of the associated log file partially overlaps with the time range to be recovered, then obtain the transaction commit timestamp of each log record in the associated log file, and take the log record whose transaction commit timestamp is within the time range to be recovered as the target log record.

[0108] Specifically, for each associated log file, if the file time range of the associated log file is within the recovery time range (i.e., the recovery time range completely includes the file time range of the associated log file), then all log records in the associated log file are used as target log records. If the file time range of the associated log file is not completely within the recovery time range, but there is partial overlap, the transaction commit timestamps of all log records in the associated log file can be obtained, and the log records whose transaction commit timestamps are within the recovery time range are used as target log records. In this case, some log records in the associated log file are target log records, and others are not.

[0109] It should be noted that for each associated log file, the multiple log records in the associated log file are not strictly ordered in chronological order. Therefore, for partially overlapping associated log files, the transaction commit timestamps of all log records in the associated log file need to be judged as described above in order to filter out the target log record.

[0110] In this embodiment of the disclosure, multiple target log records are determined based on multiple associated log files, thereby effectively filtering out the target log records that need to be recovered and eliminating log records in the associated log files that do not need to be recovered, thus ensuring the correctness of data recovery.

[0111] As an optional embodiment, determining at least one target log record to be recovered from at least one associated log file includes:

[0112] Create at least one recovery node and assign each associated log file to the at least one recovery node, such that each recovery node reads the at least one associated log file assigned to it;

[0113] Based on the associated log files read by each recovery node, the at least one target log record is determined.

[0114] Specifically, at least one recovery node can be created, wherein the recovery node can be used to read associated log files, the recovery node can be a unit of executing programs, the node can be a process or thread, or it can be an electronic device (e.g., a server). This disclosure does not limit this aspect.

[0115] Multiple associated log files can be assigned to at least one recovery node, and each recovery node can read at least one associated log file assigned to it.

[0116] Optionally, for each upstream storage node in the upstream database, the upstream storage node can back up multiple log files. When the downstream database has sufficient storage resources, a corresponding recovery node can be set up for each upstream storage node. Each recovery node is used to read the associated log files backed up by the corresponding upstream storage node. When the downstream database has limited storage resources, the upstream storage nodes can be evenly allocated to each recovery node. For example, if the number of upstream storage nodes is 10 and the number of recovery nodes is 3, then the 1st to 3rd upstream storage nodes can be allocated to recovery node 1, the 4th to 6th upstream storage nodes to recovery node 2, and the 7th to 10th upstream storage nodes to recovery node 3. The number of recovery nodes and the allocation strategy can be adaptively adjusted according to actual resources and needs, and this embodiment does not limit this. By setting up multiple recovery nodes, the associated log files can be read in parallel, which helps to improve recovery efficiency.

[0117] For each recovery node, the recovery node can also traverse the log records in the multiple associated log files allocated to obtain multiple target log records. The method for determining the target log records is described in the corresponding embodiment above, and will not be repeated here.

[0118] As an optional implementation, log records are represented as key-value pairs; the keys in the log records include the row index of the data row targeted by the write transaction and the transaction identifier of the write transaction; the values ​​corresponding to the keys in the log records include the data in the data row after being updated by the write transaction.

[0119] Specifically, log files can be generated by each upstream storage node in the upstream database based on the following method:

[0120] For each upstream storage node in the upstream database, when the upstream storage node receives a transaction commit operation for a write transaction of data stored on the upstream storage node, it can record the transaction number of the write transaction and the transaction commit timestamp of the transaction commit operation, and combine the transaction number of the write transaction and the transaction commit timestamp of the transaction commit operation into a transaction identifier. That is, the transaction identifier includes the transaction number of the committed write transaction and the transaction commit timestamp of the corresponding transaction commit operation.

[0121] The upstream storage node can determine the row index of the data row targeted by the write transaction, use the combination of the obtained transaction identifier and the row index of the targeted data row as the key in the key-value pair, and use the data of the targeted data row after being updated by the write transaction as the value in the key-value pair, and generate a log record based on the obtained key-value pair.

[0122] Figure 2 This is a schematic diagram of a transaction identifier provided in an embodiment of the present disclosure, such as... Figure 2 As shown, each transaction is assigned a globally unique transaction number upon commit, which is used to identify the corresponding transaction. The transaction identifier is obtained based on the transaction number and the transaction commit timestamp, and the commit time of the transaction can be obtained through the transaction identifier.

[0123] For example, taking a money transfer scenario as an example, when a user performs a recharge operation of 100 to account A, the corresponding write transaction number is N1, the commit time of the transaction commit operation is t1, the transaction identifier ID1=N1_t1, the data of account A before the recharge operation is 0, and the data of account A after the recharge operation is 100. The generated log record can be represented as follows:<A_ID1,100> When a user performs a withdrawal of 30 from account A, the corresponding write transaction has transaction number N2, the commit time of the transaction is t2, and the transaction identifier ID2 = N2_t2. Before the withdrawal, the data in account A is 100, and after the withdrawal, the data in account A is 70. The generated log record can be represented as follows:<A_ID2,70> When a user recharges account A with 200, the corresponding write transaction has transaction number N3, the commit time is t3, and the transaction identifier ID3 = N3_t3. Before the recharge, account A's data was 70; after the recharge, account A's data was 270. The generated log record can be represented as follows:<A_ID3,270> Table 1 shows the log records generated when multiple write transactions are executed on the same account.

[0124] Table 1:

[0125]

[0126] Specifically, when a write transaction targets at least two data rows stored on different upstream storage nodes, the transaction identifier of the write transaction in the log record corresponding to the transaction commit operation of each upstream storage node is the same. When a write transaction targets multiple data rows, these multiple data rows need to be written successfully simultaneously, or fail simultaneously, and the transaction will be rolled back.

[0127] When recovering a distributed transaction, multiple log records belonging to the same transaction identifier need to be recovered to the downstream database to ensure the consistency of transactions across nodes.

[0128] For example, let's take a money transfer scenario as an example. Assume that the data for account A is stored on upstream storage node 1, and the data for account B is stored on upstream storage node 2. When a user transfers 30 from account A to account B, the corresponding write transaction has transaction number N1, the commit time of the transaction is t1, and the transaction identifier ID1 = N1_t1. Before the transfer operation, the data for account A is 100, and the data for account B is 200. After the transfer operation, the data for account A is 70, and the data for account B is 230. The corresponding log record generated by upstream storage node 1 can be represented as follows:<A_ID1,70> The corresponding log record generated by upstream storage node 2 can be represented as<B_ID1,230> .

[0129] Optionally, for each upstream storage node in the upstream database, the upstream storage node may use the set of log sets generated within the preset period as the log file corresponding to the upstream storage node at preset intervals.

[0130] Optionally, for each upstream storage node in the upstream database, when the upstream storage node determines that the generated log records meet the preset conditions, it can use the set of at least one log record that meets the preset conditions as the log file corresponding to the upstream storage node.

[0131] The preset conditions may include the number of log records reaching a preset number. In this case, when the number of generated log records reaches the preset number, the set of the preset number of log records will be used as a log file.

[0132] The preset conditions may also include the log record data size being within a preset data size range. In this case, when the generated log record data size is within the preset data size range, the resulting collection of log records will be treated as a single log file.

[0133] The preset data size range can include an upper limit and a lower limit. When the difference between the upper and lower limits is less than the preset threshold, the generated log files are relatively evenly sized, which helps to distribute multiple log files evenly among multiple recovery nodes, thus achieving load balancing among multiple recovery nodes.

[0134] Optionally, the filename of the log file is generated based on the upstream storage node. File information corresponding to the log file can also be generated, which may include the log file's time information, the key range of all log records in the log file, the file size of the log file, etc. The generated log file information is saved to the metadata.

[0135] The upstream storage node can store multiple generated log files in its log module.

[0136] Optionally, each upstream storage node can periodically or quantitatively archive log data from the log module to an external storage device and record the storage address of each log file on the external storage device, which can be an S3 or a distributed file system. In this case, each recovery node can read the log files from the external storage device. By archiving the log files to the external storage device, the log files avoid occupying storage resources in the upstream database, reducing the impact of the generated log files on the performance of the upstream database.

[0137] Figure 3 This is a schematic diagram of a distributed transaction log backup provided in an embodiment of the present disclosure, such as... Figure 3 As shown, the upstream database includes compute nodes 1 and 2 in the compute layer and storage nodes 1-3 in the storage layer. Client 1 connects to compute node 1 and initiates write transaction 1, which involves modifying the data in the first row (row1) of storage node 1 and the second row (row2) of storage node 2. Client 2 connects to compute node 2 and initiates write transaction 2, which involves modifying the data in the first row (row1) of storage node 1, the second row (row2) of storage node 2, and the third row (row3) of storage node 3.

[0138] Even if client 1 and client 2 submit transactions at the same time, they will obtain different logical numbers as transaction numbers, although the submission time is the same.

[0139] For the same transaction 1 (ID1), the log record corresponding to the first row of data row1 involved<row1index_ID1,row1Value> In the log record corresponding to the second row of data row2<row2index_ID1,row2Value> Belonging to the same transaction, these two key-value pairs contain the same transaction ID1. Similarly, for write transaction 2, the log records of different data rows involved...<row1index_ID2,row1Value> ,<row2index_ID2,row2Value> and<row3index_ID2,row3value> These three key-value pairs belong to the same transaction and contain the same transaction ID2.

[0140] Storage node 1 generates multiple log records corresponding to the first row of data and stores them in the log model within storage node 1. Then, it periodically or quantitatively archives the log files in the log module to cloud storage, such as S3 or DFS (Distributed File System). Similarly, storage nodes 2 and 3 can also archive the generated log files to their respective external storage devices.

[0141] The following uses a money transfer scenario to illustrate the data recovery process of a distributed transaction. Assume that account A's data is stored on storage node 1, and account B's data is stored on storage node 2. When a user transfers 30 from account A to account B, the corresponding write transaction number is N1, the commit time of the transaction is t1, and the transaction identifier ID1 = N1_t1. Before the transfer, account A's data is 100, and account B's data is 200. After the transfer, account A's data is 70, and account B's data is 230. The corresponding log record generated by storage node 1 can be represented as follows:<A_ID1,70> The corresponding log record generated by storage node 2 can be represented as<B_ID1,230> .

[0142] When a user transfers 100 from account B to account A, the corresponding write transaction number is N2, the commit time of the transaction is t2, and the transaction identifier ID2 = N2_t2. Before the transfer operation, the data in account A is 70, and the data in account B is 230. After the transfer operation, the data in account A is 170, and the data in account B is 130. The corresponding log record generated by storage node 1 can be represented as follows:<A_ID2,170> The corresponding log record generated by storage node 2 can be represented as<B_ID2,130> .

[0143] When a user transfers 10 from account A to account B, the corresponding write transaction number is N3, the commit time of the transaction is t3, and the transaction identifier ID3 = N3_t3. Before the transfer operation, the data for account A is 170 and the data for account B is 130. After the transfer operation, the data for account A is 160 and the data for account B is 140. The corresponding log record generated by storage node 1 can be represented as follows:<A_ID3,160> The corresponding log record generated by storage node 2 can be represented as<B_ID3,140> Table 2 shows the log records generated by cross-node transactions.

[0144] Table 2

[0145]

[0146] Figure 4 This is a schematic diagram illustrating a distributed transaction log storage and archiving method provided in an embodiment of this disclosure, such as... Figure 4As shown, for each storage node, when multiple consecutive write transactions commit operations occur for a data row, multiple log records corresponding to the multiple transaction commit operations can be continuously recorded in the log file.

[0147] Assume account A's data resides on storage node 1, and the backed-up log is archive log 1. Account B's data resides on storage node 2, and the backup corresponds to archive log 2. Now, archive log 1 and archive log 2 are restored in parallel, out of order, to time t3. Regardless of the restoration order of accounts A and B, after restoring to time t3, what is the largest transaction record of account A retained in the database storage?<A_ID3,160> The largest transaction record of account B retained in storage.<B_ID3,140> When querying the latest data for accounts A and B, A=160 and B=140, which satisfies the consistency of transactions.

[0148] In a distributed database, when a write transaction involves multiple storage nodes, the recovery order of the archived logs will also be different because the archived logs on different storage nodes are different, but the consistency of the transaction after recovery can still be guaranteed.

[0149] In this embodiment, the transaction ID is encoded in the key of the backed-up log record. The transaction ID contains the transaction commit time. At a specified recovery time point T, after out-of-order recovery, only the record with the largest transaction ID is retained in the storage module. Regardless of the recovery order, the final form in the database storage is consistent, without affecting data correctness and transaction consistency. For centralized storage databases, since out-of-order recovery does not affect correctness and consistency, concurrent replay of logs for a single storage service can be performed, improving commit replay efficiency. In a distributed database architecture, all storage nodes back up logs simultaneously, allowing transaction logs to be replayed in parallel across all storage nodes, further improving recovery efficiency and effectively enhancing the database's RTO capability.

[0150] Figure 5 This is a schematic diagram of the structure of a database recovery device provided in an embodiment of this disclosure, as shown below. Figure 5 As shown, the apparatus of this embodiment may include:

[0151] The data to be recovered determination module 210 is used to determine the target time to be recovered and the upstream database to be recovered;

[0152] The target log record determination module 220 is used to obtain at least one associated log file related to the target time from multiple log files backed up by the upstream database; and to determine at least one target log record to be recovered from the at least one associated log file; wherein, the log file includes at least one log record for recording the transaction commit operation of a write transaction; the log record includes a transaction identifier corresponding to the write transaction, a row index of the data row targeted by the write transaction, and the current version data corresponding to the write transaction; the transaction identifier includes the transaction number of the write transaction and the transaction commit timestamp of the transaction commit operation of the write transaction; the current version data is the data in the data row after being updated by the write transaction;

[0153] The downstream storage node determination module 230 is used to determine the downstream storage node corresponding to the target log record from at least one downstream storage node of the downstream database for each target log record.

[0154] The data recovery module 240 is used to send each target log record to the corresponding downstream storage node through multiple threads; for each downstream storage node in the downstream database, the downstream storage node stores the target log record with the largest transaction identifier based on the transaction identifier in each of the multiple target log records that have been received for the same row index, so that the downstream database can be restored to the upstream database at the target time.

[0155] As an optional embodiment, each log file corresponds to a file time interval; the file time interval includes the start and end times of recording all log records in the log file;

[0156] When the target log recording determination module retrieves at least one associated log file related to the target time from multiple log files backed up through the upstream database, it is used to:

[0157] Based on the target time, a target database snapshot related to the target time is determined from multiple database snapshots corresponding to the upstream database;

[0158] Based on the generation time of the target database snapshot and the target time, determine the time interval to be restored;

[0159] Based on the file time interval corresponding to each log file and the time interval to be recovered, at least one associated log file is determined from each log file.

[0160] As an optional embodiment, when the target log record determination module determines at least one target log record to be recovered from the at least one associated log file, it is used to:

[0161] For each associated log file, if the file time range of the associated log file is within the time range to be recovered, then all log records in the associated log file will be used as target log records.

[0162] For each associated log file, if the file time interval of the associated log file partially overlaps with the time interval to be recovered, then the transaction commit timestamp of each log record in the associated log file is obtained, and the log record whose transaction commit timestamp is within the time interval to be recovered is taken as the target log record.

[0163] As an optional embodiment, the size relationship of the transaction identifiers is determined based on the following method:

[0164] For any two target log records including the first target log record and the second target log record, if the transaction commit timestamp in the first target log record is different from the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between the transaction commit timestamps of the first target log record and the second target log record.

[0165] If the transaction commit timestamp in the first target log record is the same as the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between their respective transaction numbers.

[0166] As an optional embodiment, the log record is represented as a key-value pair; the key in the log record includes the row index of the data row targeted by the write transaction and the transaction identifier of the write transaction; the value corresponding to the key in the log record includes the data in the data row after being updated by the write transaction; when at least two data rows targeted by the write transaction are stored on different upstream storage nodes, the transaction identifier of the write transaction in the log record corresponding to the transaction commit operation of the write transaction recorded by each upstream storage node is the same.

[0167] As an optional embodiment, each downstream storage node in the downstream database corresponds to at least one data range;

[0168] When determining the downstream storage node corresponding to the target log record from at least one downstream storage node of the downstream database, the downstream storage node determination module is used to:

[0169] Determine the target data range to which the row index corresponding to the target log record belongs from at least one data range corresponding to each downstream storage node;

[0170] The downstream storage node corresponding to the target data range is used as the downstream storage node corresponding to the target log record.

[0171] As an optional embodiment, the upstream database includes at least one upstream storage node;

[0172] The log file is generated by each upstream storage node in the upstream database using at least one of the following methods:

[0173] At each preset interval, the set of at least one log record generated within the preset interval is used as the log file corresponding to the upstream storage node;

[0174] When the generated log records meet the preset conditions, the set of log records that meet the preset conditions will be used as the log file corresponding to the upstream storage node; the preset conditions include the number of log records reaching a preset number or the data size of the log records being within a preset data size range.

[0175] The apparatus of this disclosure embodiment can execute the method provided in this disclosure embodiment, and its implementation principle is similar, and it has corresponding technical effects. The actions performed by each module in the apparatus of each embodiment of this disclosure correspond to the steps in the method of each embodiment of this disclosure. For a detailed functional description of each module of the apparatus, please refer to the description in the corresponding method shown above, and it will not be repeated here.

[0176] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0177] This disclosure provides an electronic device including a memory, a processor, and a computer program stored on the memory. The processor executes the computer program to implement the steps of the method provided in any optional embodiment of this disclosure. Compared with the prior art, it can achieve: backing up multiple log files through an upstream database and recording the transaction commit timestamp of each write transaction in the corresponding log record; selecting multiple associated log files from the multiple log files, and then determining multiple target log records from the multiple associated log files; restoring each target log record to its corresponding downstream storage node through multiple threads, thereby achieving out-of-order parallel recovery of physical logs and improving recovery efficiency; and retaining the target log record with the largest transaction identifier among multiple target log records with the same row index in the downstream storage node, while ensuring data correctness and transaction consistency, thus achieving efficient data recovery.

[0178] In one alternative embodiment, an electronic device is provided, such as Figure 6 As shown, Figure 6 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this disclosure.

[0179] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with this disclosure. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0180] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0181] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0182] The memory 4003 is used to store computer programs that execute embodiments of the present disclosure, and is controlled by the processor 4001 to execute them. The processor 4001 is used to execute the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0183] Among them, electronic devices include, but are not limited to: mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (such as in-vehicle navigation terminals), wearable devices, etc., as well as fixed terminals such as digital TVs, desktop computers, etc.

[0184] This disclosure provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0185] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0186] It should be understood that although arrows indicate various operation steps in the flowcharts of the embodiments of this disclosure, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of the embodiments of this disclosure, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured as required, and the embodiments of this disclosure do not limit this.

[0187] The above description is only an optional implementation method for some implementation scenarios of this disclosure. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this disclosure without departing from the technical concept of this disclosure also fall within the protection scope of the embodiments of this disclosure.

Claims

1. A database recovery method, characterized in that, Applied to downstream databases, including: Determine the target time and upstream database to be recovered; At least one associated log file related to the target time is obtained from multiple log files backed up through the upstream database; at least one target log record to be recovered is determined from the at least one associated log file; wherein, the log file includes at least one log record for recording the transaction commit operation of a write transaction; the log record includes a transaction identifier corresponding to the write transaction, a row index of the data row targeted by the write transaction, and the current version data corresponding to the write transaction; the transaction identifier includes the transaction number of the write transaction and the transaction commit timestamp of the transaction commit operation of the write transaction; the current version data is the data in the data row after being updated by the write transaction; For each target log record, the target data range to which the row index of the target log record belongs is determined from at least one data range corresponding to each downstream storage node in the downstream database; the downstream storage node corresponding to the target data range is taken as the downstream storage node corresponding to the target log record; each downstream storage node in the downstream database corresponds to at least one data range; Each target log record is sent to its corresponding downstream storage node via multiple threads. For each downstream storage node in the downstream database, based on the transaction identifier in each of the multiple target log records with the same row index that have been received, the target log record with the largest transaction identifier is stored, so that the downstream database can be restored to the upstream database at the target time.

2. The method according to claim 1, characterized in that, Each log file corresponds to a file time interval; the file time interval includes the start and end times of recording all log records in the log file; The step of obtaining at least one associated log file related to the target time from multiple log files backed up through the upstream database includes: Based on the target time, a target database snapshot related to the target time is determined from multiple database snapshots corresponding to the upstream database; Based on the generation time of the target database snapshot and the target time, determine the time interval to be restored; Based on the file time interval corresponding to each log file and the time interval to be recovered, at least one associated log file is determined from each log file.

3. The method according to claim 2, characterized in that, The step of determining at least one target log record to be recovered from the at least one associated log file includes: For each associated log file, if the file time range of the associated log file is within the time range to be recovered, then all log records in the associated log file will be used as target log records. For each associated log file, if the file time interval of the associated log file partially overlaps with the time interval to be recovered, then the transaction commit timestamp of each log record in the associated log file is obtained, and the log record whose transaction commit timestamp is within the time interval to be recovered is taken as the target log record.

4. The method according to claim 1, characterized in that, The size relationship of the transaction identifiers is determined based on the following method: For any two target log records including the first target log record and the second target log record, if the transaction commit timestamp in the first target log record is different from the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between the transaction commit timestamps of the first target log record and the second target log record. If the transaction commit timestamp in the first target log record is the same as the transaction commit timestamp in the second target log record, then the size relationship between the transaction identifiers of the first target log record and the second target log record is determined based on the size relationship between their respective transaction numbers.

5. The method according to claim 1, characterized in that, The log record is represented as a key-value pair; the key in the log record includes the row index of the data row targeted by the write transaction and the transaction identifier of the write transaction; the value corresponding to the key in the log record includes the data in the data row after being updated by the write transaction; When the write transaction targets at least two data rows that are stored on different upstream storage nodes, the transaction identifier of the write transaction in the log record corresponding to the transaction commit operation of the write transaction recorded by each upstream storage node is the same.

6. The method according to any one of claims 1 to 5, characterized in that, The upstream database includes at least one upstream storage node; The log file is generated by each upstream storage node in the upstream database using at least one of the following methods: At each preset interval, the set of at least one log record generated within the preset interval is used as the log file corresponding to the upstream storage node; When the generated log records meet the preset conditions, the set of log records that meet the preset conditions will be used as the log file corresponding to the upstream storage node; the preset conditions include the number of log records reaching a preset number or the data size of the log records being within a preset data size range.

7. A database recovery device, characterized in that, include: The data to be recovered determination module is used to determine the target time for recovery and the upstream database to be recovered; The target log record determination module is used to obtain at least one associated log file related to the target time from multiple log files backed up through the upstream database; and to determine at least one target log record to be recovered from the at least one associated log file; wherein, the log file includes at least one log record for recording the transaction commit operation of a write transaction; the log record includes a transaction identifier corresponding to the write transaction, a row index of the data row targeted by the write transaction, and the current version data corresponding to the write transaction; the transaction identifier includes the transaction number of the write transaction and the transaction commit timestamp of the transaction commit operation of the write transaction; the current version data is the data in the data row after being updated by the write transaction; The downstream storage node determination module is used to determine, for each target log record, the target data range to which the row index corresponding to the target log record belongs from at least one data range corresponding to each downstream storage node in the downstream database; and to designate the downstream storage node corresponding to the target data range as the downstream storage node corresponding to the target log record; wherein each downstream storage node in the downstream database corresponds to at least one data range. The data recovery module is used to send each target log record to the corresponding downstream storage node through multiple threads. For each downstream storage node in the downstream database, the downstream storage node stores the target log record with the largest transaction identifier based on the transaction identifier in each of the multiple target log records that have been received for the same row index, so that the downstream database can be restored to the upstream database at the target time.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

Images