Data recovery method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a data recovery method and device, electronic equipment and a storage medium. Embodiments of the present application obtain a reference time input by a user, and confirm a target transaction corresponding to the reference time in an incremental backup log. According to the target transaction, a split position is confirmed in the incremental backup log, and the split position is used to divide the incremental backup log into a fast playback segment and an accurate playback segment. A fast playback mode is used to perform backup recovery processing on the fast playback segment to obtain fast recovery data. The mode is switched to an accurate playback mode to perform backup recovery processing on the accurate playback segment to obtain accurate recovery data. Embodiments of the present application dynamically determine a split position through a reference time input by a user, thereby segmenting the incremental backup log, i.e., fast playback of most data and accurate playback of tail data, so that the speed and accuracy of recovery are taken into account. Thus, the present application can improve the efficiency of data recovery.

Description

Technical Field

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

[0002] Data recovery technology refers to the process of recovering data when it is lost, corrupted, or inaccessible, using specific technical means. Incremental backup logs, in particular, only back up data that has changed since the last backup. Using incremental backup logs for data recovery is relatively efficient, avoiding full backups every time, thus saving storage space and backup time. However, current data recovery technologies still have high time costs, especially in large-scale data environments where data recovery can require significant time and manpower. For example, over time, the number of incremental backups can become enormous. If the incremental log contains tens of thousands of transactions, recovery time increases linearly with the data volume, leading to excessively long recovery times. Therefore, current data recovery efficiency is low. Summary of the Invention

[0003] This application provides a data recovery method, apparatus, electronic device, and storage medium that can improve the efficiency of data recovery.

[0004] This application provides a data recovery method, including:

[0005] Obtain the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database.

[0006] Based on the target transaction, the split position is confirmed in the incremental backup log. The split position is used to divide the incremental backup log into a fast replay segment and a precise replay segment. The fast replay segment is the transaction in the incremental backup log before the split position, and the precise replay segment is the transaction in the incremental backup log from the split position to the transaction before the target transaction.

[0007] The fast playback method is used to back up and restore the fast playback segment to obtain fast recovery data;

[0008] Switch to precise playback mode, perform backup and restore processing on the precise playback segment, and obtain precise restored data.

[0009] This application embodiment also provides a data recovery device, including:

[0010] The acquisition unit is used to acquire the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database.

[0011] The segmentation unit is used to determine the segmentation position in the incremental backup log based on the target transaction. The segmentation position is used to divide the incremental backup log into a fast replay segment and a precise replay segment. The fast replay segment is the transaction in the incremental backup log before the segmentation position, and the precise replay segment is the transaction in the incremental backup log from the segmentation position to the transaction before the target transaction.

[0012] The fast playback unit is used to perform backup and recovery processing on the fast playback segment using the fast playback method to obtain fast recovery data.

[0013] The precise playback unit is used to switch to precise playback mode, perform backup and recovery processing on the precise playback segment, and obtain precise recovery data.

[0014] In some embodiments, the incremental backup log includes multiple log files arranged in chronological order, and the segmentation unit is used for:

[0015] In the incremental backup log, the log file that first involves the target transaction is used as the split point;

[0016] Incremental backup logs are divided into fast replay segments and precise replay segments based on the segmentation location, including:

[0017] Divide the first to the (n-1)th log files into fast replay segments, where n is the sequence number of the log file corresponding to the segmentation position in the incremental backup log;

[0018] Divide the log file from the nth log file to the last log file involving the target transaction into an exact replay segment.

[0019] In some embodiments, the acquiring unit is configured to:

[0020] Obtain the reference time input by the user, and confirm that the reference time corresponds to at least one pending transaction in the incremental backup log;

[0021] Query and display the data changes corresponding to at least one pending transaction;

[0022] In response to a user's selection operation for at least one pending transaction, select the target transaction from the at least one pending transaction.

[0023] In some embodiments, the acquiring unit is configured to:

[0024] The input page is displayed, which includes a standby machine selection control and a time input control. The standby machine selection control is used to select a standby machine, and the standby machine is used to store incremental backup logs.

[0025] In response to the user's standby selection operation using the standby selection control, obtain incremental backup logs;

[0026] In response to the user's time input operation on the time input control, obtain the reference time;

[0027] Confirm at least one pending transaction in the incremental backup log corresponding to the reference time.

[0028] In some embodiments, confirming at least one pending transaction corresponding to the reference time in the incremental backup log includes:

[0029] Determine the analysis period based on the reference time;

[0030] Query all transactions involving the parsing time period in the incremental backup log, and treat all transactions involving the parsing time period as pending confirmation transactions.

[0031] In some embodiments, querying and displaying the data changes corresponding to at least one pending transaction includes:

[0032] Query the data changes corresponding to at least one pending transaction;

[0033] The page displays a view page with at least one pending confirmation transaction. The view page includes a content display area, a confirmation control, and a start recovery control.

[0034] In response to a user's selection of a transaction to be confirmed, the data changes corresponding to the selected transaction are displayed in the content display area.

[0035] In some embodiments, in response to a user's selection operation for at least one transaction to be confirmed, selecting a target transaction from the at least one transaction to be confirmed includes:

[0036] In response to the user's confirmation action on the confirmation control, the transaction to be confirmed corresponding to the data change content displayed in the content display area is taken as the target transaction.

[0037] In some embodiments, the viewing page further includes a modify reference time control, displays the viewing page, and also includes:

[0038] In response to a user's modification of the reference time control, the reference time is retrieved again, and the pending confirmation transactions on the viewing page are updated based on the re-retrieved reference time.

[0039] In some embodiments, the fast playback unit is used for:

[0040] Multiple replay threads are used to replay transactions in the fast replay segment in parallel;

[0041] Once it is detected that all transactions in the fast replay segment have completed replay, parallel replay is stopped, and fast recovery data is obtained.

[0042] In some embodiments, the incremental backup log includes multiple log files arranged in chronological order, and multiple playback threads are used to perform parallel playback of transactions in the fast playback segment, further including:

[0043] The number of replay threads is determined based on the total number of log files contained in the fast replay segment;

[0044] If the density of parallel replay transactions exceeds a preset threshold, the number of replay threads is increased.

[0045] When the system resource utilization rate is detected to have reached its limit, the number of replay threads is reduced.

[0046] In some embodiments, the precise playback unit is used for:

[0047] Based on the original commit order of the transactions in the precise replay segment, a single replay thread is used to replay each transaction in the precise replay segment one by one.

[0048] Once the last transaction in the precise replay segment has finished replaying, the line-by-line replay stops, and the precise recovered data is obtained.

[0049] This application also provides an electronic device, including a memory storing multiple instructions; the processor loads instructions from the memory to execute steps in any of the data recovery methods provided in this application.

[0050] This application also provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the data recovery methods provided in this application.

[0051] The segmentation location proposed in this application embodiment can dynamically divide the incremental backup log into a fast replay segment and a precise replay segment. This significantly shortens the recovery time of most data by processing the fast replay segment. The target transaction is located by the reference time input by the user, and the precise replay segment is divided based on this. This ensures that the processing of precise replay can ensure that the recovery endpoint strictly corresponds to the valid data state before the failure, avoiding transaction dependency conflicts and inaccurate replay that may be caused by fast replay, thus enhancing the accuracy of recovery. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1a This is a schematic diagram illustrating a scenario of the data recovery method provided in an embodiment of this application;

[0054] Figure 1b This is a flowchart illustrating the data recovery method provided in an embodiment of this application;

[0055] Figure 1c This is a schematic diagram of the input page for the data recovery method provided in this application embodiment;

[0056] Figure 1d This is a schematic diagram of a standby machine for the data recovery method provided in the embodiments of this application;

[0057] Figure 1e This is a schematic diagram of the data recovery method provided in the embodiments of this application;

[0058] Figure 1f This is a segmented playback diagram of the data recovery method provided in the embodiments of this application;

[0059] Figure 2a This is a schematic diagram illustrating the application of the data recovery method provided in this application embodiment in a delayed standby scenario;

[0060] Figure 2b This is a timing diagram illustrating the application of the data recovery method provided in the embodiments of this application;

[0061] Figure 3 This is a schematic diagram of the data recovery device provided in the embodiments of this application;

[0062] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0063] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0064] This application provides a data recovery method, apparatus, electronic device, and storage medium.

[0065] Specifically, the data recovery device can be integrated into an electronic device, such as a terminal or server. The terminal can be a mobile phone, tablet, smart Bluetooth device, laptop, or personal computer (PC); the server can be a single server or a server cluster consisting of multiple servers.

[0066] In some embodiments, the data recovery device may also be integrated into multiple electronic devices, such as multiple servers, with multiple servers implementing the data recovery method of this application.

[0067] In some embodiments, the terminal may also be used as a server to perform some or all of the functions of a server.

[0068] For example, refer to Figure 1a The electronic device can be a server that can obtain the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database. Based on the target transaction, the partition position is confirmed in the incremental backup log. The partition position is used to divide the incremental backup log into a fast playback segment and an exact playback segment. The fast playback segment consists of transactions in the incremental backup log before the partition position, and the exact playback segment consists of transactions in the incremental backup log from the partition position to the transaction preceding the target transaction. The fast playback segment is backed up and restored using the fast playback method to obtain fast restored data. The exact playback segment is then backed up and restored using the exact playback method to obtain exact restored data.

[0069] The following sections provide detailed descriptions of each example. It should be noted that the sequence numbers of the following embodiments are not intended to limit the preferred order of the embodiments.

[0070] In this embodiment, a data recovery method is provided, such as... Figure 1b As shown, the specific process of this data recovery method can be as follows:

[0071] 110. Obtain the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database.

[0072] The reference time is the expected recovery time point entered by the user, such as the moment before the failure occurred, used to initially locate the target transaction.

[0073] Incremental backup logs record all data modifications made after a full backup. They store transaction operations in chronological order and are used to replay changes during recovery. These logs can include binary logs and relay logs. A binary log records all database changes (such as modifications, inserts, and deletions). In a master-slave replication architecture, the slave server pulls this binary log from the master server, and replay synchronization has been completed. A relay log is a binary log that the slave server pulls from the master server in a master-slave replication architecture but has not yet been replayed and synchronized.

[0074] Full backup refers to a backup of a full data snapshot at a specific point in time, while incremental backup refers to a backup of all data modifications made after a specific point in time.

[0075] In some embodiments, the incremental backup log also includes a binary log index file (Binlog.index) and a relay log index file (Relay.index). The binary log index file contains the paths to all binary log files to identify which log files have been replayed and used; the relay log index file contains the paths to all intermediate log files to identify which log files have not yet been replayed and used.

[0076] A transaction is an atomic unit of database operation, including operations that modify data in the database, such as INSERT, UPDATE, and DELETE. In some embodiments, each transaction can have a unique transaction identifier, such as a Global Transaction Identifier (GTID), which can be recorded in the incremental backup log for identification of the transaction.

[0077] In traditional recovery schemes, users can only input a time point, and the system automatically begins recovery. However, this can introduce errors, such as multiple transactions occurring at the same time point, making it difficult to pinpoint the specific transaction causing the failure. Therefore, some embodiments introduce a step to confirm the target transaction, allowing users to view and select a specific transaction, which can improve recovery accuracy. The steps of obtaining the user-inputted reference time and confirming the target transaction corresponding to that reference time in the incremental backup log include:

[0078] Obtain the reference time input by the user, and confirm that the reference time corresponds to at least one pending transaction in the incremental backup log;

[0079] Query and display the data changes corresponding to at least one pending transaction;

[0080] In response to a user's selection operation for at least one pending transaction, select the target transaction from the at least one pending transaction.

[0081] Among them, the transactions to be confirmed are all possible related transactions within the time period that the system parses after the user inputs a reference time, so that the user can filter and confirm them and help the user locate the source of the fault.

[0082] The data change content refers to the specific operations performed by the transaction to modify the data in the database. This data change content can be recorded in the database as SQL statements (Statement format) or row data changes (Row format).

[0083] Query and display the data changes corresponding to at least one pending transaction so that users can see the specific operations of each transaction, thereby identifying which transaction caused the data problem and preventing the system from automatically selecting the wrong transaction, thus improving the accuracy of recovery.

[0084] In this embodiment, the system parses the incremental backup log corresponding to the reference time and extracts all transactions to be confirmed within that time period. This avoids time point mapping errors and enables precise location of the target transaction. In addition, by displaying the data change content of the transaction, users can intuitively filter and confirm the target transaction that caused the failure, eliminating the blindness of black-box recovery. Furthermore, user participation in transaction selection ensures that the recovery endpoint strictly corresponds to the actual failure point, avoiding secondary data loss caused by automatic parsing errors in traditional solutions.

[0085] Therefore, by combining user input and transaction confirmation mechanisms, this embodiment achieves the dual goals of accurate recovery and optimized user experience while ensuring recovery speed.

[0086] To ensure the reliability of the restored data source while achieving efficient mapping of time points, laying the foundation for subsequent transaction confirmation and accurate recovery, some embodiments involve obtaining a reference time input by the user and confirming at least one transaction to be confirmed in the incremental backup log corresponding to that reference time, including:

[0087] The input page is displayed, which includes a standby machine selection control and a time input control. The standby machine selection control is used to select a standby machine, and the standby machine is used to store incremental backup logs.

[0088] In response to the user's standby selection operation using the standby selection control, obtain incremental backup logs;

[0089] In response to the user's time input operation on the time input control, obtain the reference time;

[0090] Confirm at least one pending transaction in the incremental backup log corresponding to the reference time.

[0091] The input page is a user interface that includes standby machine selection controls and time input controls for initiating recovery tasks. In some embodiments, the input page can integrate database metadata query functionality to dynamically load the standby machine list and log time range. The input page can respond to standby machine selection and time input operations in real time, automatically load logs and parse transactions, simplifying the user operation process.

[0092] Time input controls can take many forms. For example, in some embodiments, a time input control can be a text box into which the user enters the time; for example, a time input control can be a time picker into which the user selects from multiple times, and so on.

[0093] The standby device selection control can take many forms. For example, in some embodiments, the standby device selection control can be a text box into which the user enters the standby device address; for example, the standby device selection control can be a standby device selector, which allows the user to select from multiple standby devices, and so on.

[0094] In some embodiments, the input page may also include a confirmation control, which, in response to a user triggering the confirmation control, confirms at least one pending transaction in the incremental backup log corresponding to the reference time.

[0095] For example, refer to Figure 1c In some embodiments, the standby machine selection control may include an instance selection control [Instance Name:], a node selection control [Node:], and a port selection control [Port:], etc., used to select the database instance, database server node, network port of the database service, etc., thereby specifying the backup source of the acquired incremental backup logs. The user's operation on the time input control [Reference Time:] indicates their expected reference time. Finally, the user clicks the confirmation control [OK] to execute the step confirming that the reference time corresponds to at least one pending confirmation transaction in the incremental backup logs. A standby machine, or data backup machine, is a machine in a master-slave architecture that receives incremental backup logs from the master database through asynchronous or semi-synchronous replication. Standby machines may include snapshot backups, delayed backups, and cold backups.

[0096] Snapshot backup refers to a complete snapshot backup of the system or data at a specific point in time. Snapshot backups are usually incremental, can be generated quickly, and capture the state of the system or data at the time of backup. Delayed backup typically refers to real-time or near real-time data synchronization by the backup machine while the primary system is running, but the backup data will have a certain delay (e.g., minutes, hours). The backup data of delayed backup is not immediately applied to the backup machine, but is synchronized according to a preset delay period. Cold backup refers to backing up data to offline storage media. The backup data is not directly used for real-time operation or operation after the backup is completed. It is usually backed up when the system is powered off or in an inactive state. Cold backup is usually a full backup and requires manual intervention during recovery.

[0097] For example, refer to Figure 1dDatabase backup and recovery is accomplished through full backups of data at a specific point in time, along with incremental backup logs from that point to the current point in time. For example, in the payment and financial sectors, to fully ensure data consistency and security, multiple layers of backup protection are implemented for critical online data. Common backup methods include scheduled full backups, delayed standby, and snapshot backups.

[0098] For example, after a user selects a standby machine, the system can retrieve the incremental backup logs on that standby machine. Then, the user enters a reference time, and the system can find the corresponding transaction in the logs based on that time.

[0099] This embodiment integrates standby machine selection and time input functions through the input page, aiming to achieve flexible data source selection and precise time point positioning, thereby improving the operability and accuracy of the recovery process. Specifically, the multiple standby machine feature allows users to flexibly select different standby machines; furthermore, the system quickly locates relevant transactions in the incremental log based on the user-input reference time, avoiding the inefficiency of full scans.

[0100] In some embodiments, confirming at least one pending transaction corresponding to the reference time in the incremental backup log includes:

[0101] Determine the analysis period based on the reference time;

[0102] Query all transactions involving the parsing time period in the incremental backup log, and treat all transactions involving the parsing time period as pending confirmation transactions.

[0103] The parsing time period is a time interval extended around a reference time input by the user, used to query related transactions. In some embodiments, the parsing time period can be obtained by adding a preset window range to the reference time, such as a few seconds before and after the reference time, to cover possible transaction execution times. For example, reference time ± 1 second.

[0104] In some embodiments, each transaction has a timestamp or GTID to determine its execution time. Therefore, by scanning the timestamp or GTID of each transaction in the incremental backup log, all transactions that started or committed within the parsing time period can be found. Thus, this time window buffering mechanism can address minor differences between the commit time and the log recording time caused by network latency and other issues, improving fault tolerance.

[0105] Therefore, multiple transactions may exist around the time point entered by the user. This embodiment allows the user to select the specific transaction that caused the data problem. For example, a user may have accidentally deleted a table, but this operation may have occurred around the same time as other transactions. Therefore, it is necessary to filter and confirm to improve the accuracy of the playback.

[0106] In some embodiments, querying and displaying the data changes corresponding to at least one pending transaction includes:

[0107] Query the data changes corresponding to at least one pending transaction;

[0108] The page displays a view page with at least one pending confirmation transaction. The view page includes a content display area, a confirmation control, and a start recovery control.

[0109] In response to a user's selection of a transaction to be confirmed, the data changes corresponding to the selected transaction are displayed in the content display area.

[0110] The view page is an interactive interface that displays a list of transactions to be confirmed and the data changes made, allowing users to confirm target transactions. In some embodiments, the view page may support pagination, search, and highlighting of dangerous operations (such as DROP TABLE) to improve user filtering efficiency. By clicking on transaction entries, users can dynamically view their data changes, quickly locate abnormal operations, and repeatedly check and correct their selections.

[0111] In some embodiments, in response to a user's selection operation for at least one transaction to be confirmed, selecting a target transaction from the at least one transaction to be confirmed includes:

[0112] In response to the user's confirmation action on the confirmation control, the transaction to be confirmed corresponding to the data change content displayed in the content display area is taken as the target transaction.

[0113] In some embodiments, the viewing page further includes a control to modify the reference time, allowing users to repeatedly modify the reference time. Therefore, the step of displaying the viewing page also includes:

[0114] In response to a user's modification of the reference time control, the reference time is retrieved again, and the pending confirmation transactions on the viewing page are updated based on the re-retrieved reference time.

[0115] For example, refer to Figure 1eThe viewing page includes pending transactions [1], [2], [3], etc., from which users can select any one to view. If no one is selected, the first pending transaction is displayed by default. For example, when a user selects to view pending transaction [2], the content display area shows the GTID and data change content corresponding to pending transaction [2]. When a user performs a modification operation on the time point of the modification reference time control [Modify Reference Time:], the reference time is re-acquired, and the pending transactions on the viewing page are updated based on the re-acquired reference time. When a user performs a confirmation operation on the confirmation control [Confirm GTID], the pending transaction [2] corresponding to the data change content displayed in the content display area is taken as the target transaction.

[0116] 120. Based on the target transaction, confirm the split position in the incremental backup log. The split position is used to divide the incremental backup log into a fast replay segment and an exact replay segment. The fast replay segment is the transaction in the incremental backup log before the split position, and the exact replay segment is the transaction in the incremental backup log from the split position to the transaction before the target transaction.

[0117] This solution balances the speed and accuracy of data recovery by dividing incremental backup logs into two parts: a fast replay segment and a precise replay segment. This allows for the recovery of most data in the shortest possible time while ensuring data consistency and integrity as the target time point approaches.

[0118] In some embodiments, the incremental backup log includes multiple log files arranged in chronological order. Based on the target transaction, the split position is identified in the incremental backup log, including:

[0119] In the incremental backup log, the log file that first involves the target transaction is used as the split point;

[0120] Incremental backup logs are divided into fast replay segments and precise replay segments, including:

[0121] Divide the first to the (n-1)th log files into fast replay segments, where n is the sequence number of the log file corresponding to the segmentation position in the incremental backup log;

[0122] Divide the log file from the nth log file to the log file corresponding to the previous transaction of the target transaction into exact replay segments.

[0123] The incremental backup log can consist of multiple log files numbered chronologically. For example, the incremental backup log consists of four log files numbered chronologically: Binlog.001, Binlog.002, Binlog.003, and Binlog.004. The log files can be generated in a rolling manner based on size or time. The index file (such as Binlog.index) records the paths of all log files.

[0124] In some embodiments, the first to the nth log files can be divided into fast replay segments, and the log files from the (n-k+1)th log file to the log file corresponding to the previous transaction of the target transaction can be divided into exact replay segments. n and k are both positive integers, and the value of k can be set by those skilled in the art, but should be much smaller than n, for example, set to 1, so as to ensure that the fast replay segments with short execution time contain most of the log content in the incremental backup log, while the exact replay segments with long execution time contain a very small portion of the log content.

[0125] 130. Using the fast playback method, the fast playback segment is backed up and restored to obtain fast recovery data.

[0126] Fast playback methods can include multi-threaded parallel playback, batch playback, asynchronous parsing and execution separation playback, compressed playback, and other ways to improve playback speed. The data to be recovered quickly must ensure transaction integrity, but it is permissible to temporarily skip some dependency checks to speed up processing.

[0127] In some embodiments, a fast playback method can be used, such as using multiple threads to process transactions in the fast playback segment simultaneously, to perform backup and recovery processing on the fast playback segment and obtain fast recovery data, including:

[0128] Multiple replay threads are used to replay transactions in the fast replay segment in parallel;

[0129] Once it is detected that all transactions in the fast replay segment have completed replay, parallel replay is stopped, and fast recovery data is obtained.

[0130] Among them, multi-threaded parallel playback uses multiple threads to process transactions in the fast playback segment simultaneously. Thread tasks need to be divided by transaction ID or time range to avoid concurrent modification conflicts of the same row of data.

[0131] In some embodiments, the number of replay threads can be dynamically adjusted to optimize the recovery process of the incremental backup log. Therefore, the incremental backup log includes multiple log files arranged in chronological order, and multiple replay threads are used to perform parallel replay of transactions in the fast replay segment. The system also includes:

[0132] The number of replay threads is determined based on the total number of log files contained in the fast replay segment;

[0133] If the density of parallel replay transactions exceeds a preset threshold, the number of replay threads is increased.

[0134] When the system resource utilization rate is detected to have reached its limit, the number of replay threads is reduced.

[0135] System resource utilization can include the efficiency of utilizing resources such as CPU, memory, and disk I / O during the recovery process.

[0136] The intelligent adjustment mechanism proposed in this embodiment optimizes system performance, avoids resource waste, and maintains the balance of system recovery tasks under different load conditions, thereby improving the robustness and efficiency of the data recovery process and adapting to complex and dynamic recovery scenarios.

[0137] 140. Switch to precise playback mode, perform backup and restore processing on the precise playback segment, and obtain precise restored data.

[0138] In this solution, to ensure that the last transaction before the target time point can be accurately recovered in the final stage of data recovery, so as to guarantee data integrity and consistency, it is necessary to switch to the precise playback mode and perform backup and recovery processing on the precise playback segment.

[0139] Among them, accurate playback methods can include single-threaded playback, segmented playback, and dependency-aware parallel playback, which can improve playback accuracy and reduce playback errors.

[0140] In this process, single-threaded replay executes the operations in the precise replay segment one by one in the order of transaction commit, ensuring data consistency, strictly following the transaction order, and avoiding dirty reads or lost updates caused by parallelism.

[0141] In some embodiments, the system switches to precise playback mode, performs backup and recovery processing on the precise playback segment, and obtains precise recovery data, including:

[0142] Based on the original commit order of the transactions in the precise replay segment, a single replay thread is used to replay each transaction in the precise replay segment one by one.

[0143] Once the last transaction in the precise replay segment has finished replaying, the line-by-line replay stops, and the precise recovered data is obtained.

[0144] This embodiment employs a single-threaded, step-by-step replay of transactions within a precisely replayed segment. This ensures that the replay order matches the original commit order of the transactions, avoiding potential issues such as transaction order disruption or data inconsistency that might arise from parallel replay. It also prevents any potential data loss or replay errors. The recovery task terminates when the last transaction is fully replayed, thus guaranteeing the integrity and accuracy of the recovery process.

[0145] As can be seen from the above, the embodiments of this application can obtain the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database. According to the target transaction, the segmentation position is confirmed in the incremental backup log. The segmentation position is used to divide the incremental backup log into a fast playback segment and a precise playback segment. The fast playback segment is the transaction before the segmentation position in the incremental backup log, and the precise playback segment is the transaction between the segmentation position and the transaction before the target transaction. The fast playback segment is backed up and restored using the fast playback method to obtain fast recovery data. The precise playback segment is backed up and restored using the precise playback method to obtain precise recovery data.

[0146] This application's embodiments significantly improve the efficiency and accuracy of data recovery by obtaining a reference time input by the user and confirming its corresponding target transaction in the incremental backup log. For example, reference... Figure 1f First, this solution confirms the split position of the target transaction in the incremental backup log and divides the log into a fast replay segment and a precise replay segment. The fast replay segment uses a fast replay method, processing transactions before the split position in parallel through multi-threading, significantly shortening the recovery time. The precise replay segment uses a precise replay method, processing transactions between the split position and the target transaction sequentially in a single thread, ensuring the accuracy of the recovery. This segmented processing method solves the problem of slow recovery speed caused by single-threaded replay throughout the traditional solution, and avoids transaction dependency conflicts that may be caused by parallel replay, ensuring data consistency. In addition, this solution confirms the target transaction through user interaction, enhancing the transparency and controllability of the recovery process and solving the problem of unreliable recovery results caused by black-box operations in traditional solutions. Overall, this solution is superior to existing technologies in terms of recovery speed, accuracy, and user experience, and is suitable for scenarios with stringent requirements for timeliness and data consistency. Therefore, this solution can improve the efficiency of data recovery.

[0147] The method described in the above embodiments will be further described in detail below.

[0148] In this embodiment, the method of this application embodiment will be described in detail using the example of delaying the backup machine to restore data.

[0149] Delayed backup is a full backup with a one-day data delay compared to the online database by default. Therefore, the following will introduce the process of incremental backup log synchronization. When the online database experiences data anomalies such as accidental deletion or loss due to system bugs or human error, users will follow the steps below to complete data recovery. Figure 2a As shown, the specific process of a data recovery method is as follows:

[0150] 1. Users can find the corresponding delayed standby machine based on the instance name of the faulty instance.

[0151] Users can filter for corresponding delayed standby servers by entering the instance name in the standby server selection control on the input page, thereby obtaining standby servers for storing incremental backup logs. This input page can provide instance search functionality on the front end and verify the availability of standby servers through the back end.

[0152] For example, an input page is displayed, which includes a standby machine selection control; in response to the user's standby machine selection operation on the standby machine selection control, incremental backup logs are obtained. For example, if the user enters the instance name of the faulty instance into the standby machine selection control, the input page can return and display the available standby machines searched based on the instance name, so that the user can select a delayed standby machine from them, and finally obtain the incremental backup logs stored in the delayed standby machine.

[0153] 2. When clicking the data recovery button, the user enters the reference time to be recovered.

[0154] For example, the input page includes a time input control. In response to the user's time input operation on the time input control, such as entering a specific time, a reference time is obtained. Then, based on the reference time, the parsing time period is determined. All transactions involving the parsing time period are queried in the incremental backup log, and all transactions involving the parsing time period are displayed as pending confirmation transactions on the display page.

[0155] 3. When you click "OK" to initiate the data recovery task, the data recovery task is initiated and is in the initialization state.

[0156] For example, the input page may also include a confirmation control. When the user clicks the confirmation control, a data recovery task is initiated, i.e., steps 4 to 7 below.

[0157] The initialization state may include background operations such as verifying user permissions, preloading metadata of incremental backup logs, and assigning unique identifiers (Task IDs) to recovery tasks.

[0158] 4. The system will parse the target transaction and the content of the target transaction at the reference time specified by the user, and change the task stage to the target confirmation state, so that the user can confirm whether the content is the cause of the data loss.

[0159] This embodiment can display the data changes corresponding to at least one pending confirmation transaction on the viewing page. For example, it can query the data changes corresponding to at least one pending confirmation transaction; the viewing page displays at least one pending confirmation transaction, and the viewing page includes a content display area, a confirmation control, and a start recovery control; in response to the user's selection operation for a pending confirmation transaction, the data changes of the pending confirmation transaction corresponding to the selection operation are displayed in the content display area; in response to the user's confirmation operation on the confirmation control, the pending confirmation transaction corresponding to the data changes displayed in the content display area is taken as the target transaction.

[0160] For example, the mysqlbinlog tool can be used to parse transactions before and after a reference time point, such as SQL changes within one second before or after the time point, to extract transactions that might lead to data loss, and convert the transaction content into a readable format for user confirmation. Users need to filter and confirm the specific transactions that caused the failure by viewing the page. If users find that the parsing results are inaccurate, they can readjust the reference time and re-parse.

[0161] For example, the viewing page also includes a reference time modification control. Therefore, the viewing page can also respond to the user's modification operation of the reference time control, re-acquire the reference time, and update the pending confirmation transactions on the viewing page based on the re-acquired reference time.

[0162] 5. After the user confirms for the second time (i.e. the user confirms whether the content is the cause of the data loss), when the user clicks "Start Recovery", the task status will be changed to "Data Recovery" and the data recovery will officially begin.

[0163] For example, after a user confirms the target transaction, write permissions for the delayed standby machine can be locked to prevent data conflicts during the recovery process; the split position of the incremental backup log can be determined based on the GTID of the target transaction; the log files before the split position are marked as fast replay segments, and the log files after the split position are marked as exact replay segments.

[0164] For example, in the incremental backup log, the log file that first involves the target transaction can be used as the split point; the first to the (n-1)th log files can be divided into fast replay segments; and the log file from the nth log file to the log file corresponding to the transaction preceding the target transaction can be divided into exact replay segments.

[0165] 6. Start replaying data to the specified GTID via Relay Log.

[0166] First, the fast playback mode is used to back up and restore the fast playback segment to obtain fast recovery data; then, the precise playback mode is switched to back up and restore the precise playback segment to obtain precise recovery data.

[0167] The fast replay phase can employ a multi-threaded parallel replay approach to accelerate the recovery of log files from the fast replay segment. The system can dynamically detect thread load and adjust the number of threads based on transaction density and system resources.

[0168] For example, multiple replay threads can be used to replay transactions in the fast replay segment in parallel; once it is detected that all transactions in the fast replay segment have been replayed, parallel replay is stopped, and fast-recovered data is obtained.

[0169] The precise replay phase can be switched to single-threaded recovery of the log file of the precise replay segment, ensuring that the transaction order is consistent with the original commit. It automatically stops when replaying to the previous GTID of the target transaction to avoid triggering the faulty transaction again.

[0170] For example, following the original commit order of transactions in the precise replay segment, a single replay thread is used to replay each transaction in the precise replay segment one by one; when the last transaction in the precise replay segment is completed, the replay stops and the precise recovery data is obtained.

[0171] 7. The recovery task is in progress, and the system will continuously monitor the Relay Log playback progress.

[0172] For example, the recovery progress can be monitored by querying the SHOW SLAVE STATUS command in real time to obtain the GTID of the replayed data and the location of the log files. SHOW SLAVE STATUS is a MySQL command used to display the replication status from the server, which helps diagnose whether the replication is working properly and to identify any problems.

[0173] In some embodiments, the progress percentage and estimated remaining time can be displayed on the front-end page based on the recovery progress.

[0174] In some embodiments, if playback is interrupted, the system can record the breakpoint and support resuming playback from the breakpoint.

[0175] 8. Once the recovery is detected as complete, the data recovery task will proactively change its status to "complete" to signify the end of the data recovery process.

[0176] The system compares the final replay GTID with the previous GTID of the target transaction specified by the user to check the database table structure and data integrity. Once all checks are completed, the data recovery task is actively modified to complete.

[0177] In some embodiments, the standby write lock can also be released to restore synchronization with the primary database.

[0178] In some embodiments, a data recovery report may also be provided, which includes the reported replay logs, time taken, and scope of impact.

[0179] The following will provide further explanation based on the methods described in the above embodiments.

[0180] In this embodiment, the method of this application embodiment will be described in detail using the data interaction of the entire system as an example.

[0181] In this solution, to improve the incremental playback speed, the incremental playback stage is divided into two parts: fast playback mode and precise playback mode.

[0182] Specifically, the n Binlogs required for incremental recovery can be divided into two parts: n-1 and n. The first n-1 Binlogs are played back using a parallel playback thread for speed-up, while the last nth Binlog is played back using a single-threaded precise playback method, thereby achieving both acceleration and accurate playback.

[0183] refer to Figure 2b The specific implementation steps are as follows:

[0184] 1. Obtain the reference time input by the user and confirm that the reference time corresponds to at least one pending transaction in the incremental backup log: After the user inputs the reference time (targetTime), the system uses the mysqlbinlog tool to parse the time into at least one corresponding pending transaction and returns the SQL changes of the pending transaction to the user for secondary confirmation. For example, the command execution example is as follows:

[0185] mysqlbinlog-vv--base64-output=decode-rowsbinlog.xx--start-datetime=target Time--stop-datetime=targetTime+1s> / data1 / tmpbinlog.log.yyyymmddMM

[0186] The -vv parameter is used to output readable SQL statements, --base64-output=decode-rows is used to decode row data in the binary log, binlog.xx is the filename of the Binlog to be parsed, --start-datetime=targetTime starts parsing from the reference time entered by the user, --stop-datetime=targetTime+1s stops parsing 1 second after the reference time, and > / data1 / tmpbinlog.log.yyyymmddMM saves the parsing results to the specified file, where yyyymmddMM represents the year, month, day, hour, and minute to ensure that the filename is unique and traceable.

[0187] After the user filters and confirms the target transaction that caused the failure in at least one pending transaction, the system determines the corresponding target transaction.

[0188] For example, when a user selects a target transaction by clicking the confirmation control in the content display area, the system records its GTID as the recovery endpoint.

[0189] 2. Fast replay method: The system determines the Relay Log where the target transaction is located, shuts down the IO synchronization thread, modifies the Relay.index file to exclude subsequent Relay Logs, sets the number of parallel replay threads to 16, and starts the fast replay segment processing phase. The system continuously monitors the replay progress until the fast replay segment is completed.

[0190] Divide the first to the (n-1)th log files into fast replay segments, where n is the sequence number of the log file corresponding to the split position in the incremental backup log; divide the log files from the nth log file to the log file corresponding to the previous transaction of the target transaction into exact replay segments.

[0191] For example, the system locates the Binlog file containing the target transaction based on its GTID and marks that file as the split point. The first n-1 Binlog files are divided into fast replay segments. The system excludes logs after the split point by modifying the Relay.index file to ensure that subsequent replays only process the fast replay segments.

[0192] Set the number of parallel playback threads to 16, and use multi-threaded concurrent playback to quickly replay the Binlog file of the segment.

[0193] If the system detects high transaction density, it automatically increases the number of threads; if CPU or memory utilization exceeds 80%, it automatically reduces the number of threads to avoid resource contention.

[0194] The `SHOW SLAVE STATUS` command is used to obtain the `Relay_Log_Pos` field in real time, calculate the proportion of replayed logs, and report back to the front end. `Relay_Log_Pos` is a field output by the `SHOW SLAVE STATUS` command in MySQL, representing the current log position (i.e., offset) in the Relay Log being processed by the server; it indicates the position a thread has reached in its Relay Log file.

[0195] Stop the IO thread (STOP SLAVE IO_THREAD) to prevent new log writes from interfering with the recovery process.

[0196] Once all transactions in the fast replay segment have been completed, parallel replay stops, and the data is quickly recovered. For example, the replay scope can be controlled by modifying the Relay.index file to ensure that only the fast replay segment is processed during the parallel phase.

[0197] 3. Switch to single-threaded precise replay mode: The system re-adds the Binlog corresponding to the target transaction to the index file, switches to single-threaded precise replay mode, and replays each transaction to the previous transaction of the target transaction, finally completing the data recovery.

[0198] The system re-adds the Binlog file corresponding to the target transaction to Relay.index and enables single-threaded replay.

[0199] Following the original commit order of transactions in the precise replay segment, a single replay thread replays each transaction in the segment one by one. For example, Binlog events are replayed one by one in the transaction commit order, up to the previous GTID of the target transaction.

[0200] Once the last transaction in the precise replay segment has completed its replay, the row-by-row replay stops, and the precisely recovered data is obtained. Finally, the GTID of the final replay is verified to be consistent with the GTID of the previous target transaction; the data integrity of critical business tables is checked.

[0201] Restart the IO thread to restore synchronization between the delayed standby and the primary database.

[0202] Clean up temporary files and release database locks.

[0203] As can be seen from the above, this embodiment of the application dynamically determines the segmentation position based on the reference time input by the user, thereby segmenting the incremental backup log for processing. This means that most of the data is quickly replayed, while the remaining data is accurately replayed, balancing the speed and accuracy of recovery. Therefore, this solution can improve the efficiency of data recovery.

[0204] It is understood that, in the specific implementation of this application, incremental backup logs and other related data are involved. When the following embodiments of this application are applied to specific products or technologies, permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0205] To better implement the above methods, this application also provides a data recovery device, which can be integrated into an electronic device, such as a terminal or server. The terminal can be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, or personal computer; the server can be a single server or a server cluster composed of multiple servers.

[0206] For example, in this embodiment, the method of this application embodiment will be described in detail by taking the data recovery device specifically integrated into the server as an example.

[0207] For example, such as Figure 3 As shown, the data recovery device may include an acquisition unit 310, a segmentation unit 320, a fast playback unit 330, and a precise playback unit 340, as follows:

[0208] (a) Obtaining Unit 310.

[0209] The acquisition unit 310 is used to acquire the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database.

[0210] In some embodiments, the acquisition unit 310 is configured to:

[0211] Obtain the reference time input by the user, and confirm that the reference time corresponds to at least one pending transaction in the incremental backup log;

[0212] Query and display the data changes corresponding to at least one pending transaction;

[0213] In response to a user's selection operation for at least one pending transaction, select the target transaction from the at least one pending transaction.

[0214] In some embodiments, the acquisition unit 310 is configured to:

[0215] The input page is displayed, which includes a standby machine selection control and a time input control. The standby machine selection control is used to select a standby machine, and the standby machine is used to store incremental backup logs.

[0216] In response to the user's standby selection operation using the standby selection control, obtain incremental backup logs;

[0217] In response to the user's time input operation on the time input control, obtain the reference time;

[0218] Confirm at least one pending transaction in the incremental backup log corresponding to the reference time.

[0219] In some embodiments, confirming at least one pending transaction corresponding to the reference time in the incremental backup log includes:

[0220] Determine the analysis period based on the reference time;

[0221] Query all transactions involving the parsing time period in the incremental backup log, and treat all transactions involving the parsing time period as pending confirmation transactions.

[0222] In some embodiments, querying and displaying the data changes corresponding to at least one pending transaction includes:

[0223] Query the data changes corresponding to at least one pending transaction;

[0224] The page displays a view page with at least one pending confirmation transaction. The view page includes a content display area, a confirmation control, and a start recovery control.

[0225] In response to a user's selection of a transaction to be confirmed, the data changes corresponding to the selected transaction are displayed in the content display area.

[0226] In some embodiments, in response to a user's selection operation for at least one transaction to be confirmed, selecting a target transaction from the at least one transaction to be confirmed includes:

[0227] In response to the user's confirmation action on the confirmation control, the transaction to be confirmed corresponding to the data change content displayed in the content display area is taken as the target transaction.

[0228] In some embodiments, the viewing page further includes a modify reference time control, displays the viewing page, and also includes:

[0229] In response to a user's modification of the reference time control, the reference time is retrieved again, and the pending confirmation transactions on the viewing page are updated based on the re-retrieved reference time.

[0230] (ii) Segmentation unit 320.

[0231] The segmentation unit 320 is used to determine the segmentation position in the incremental backup log according to the target transaction. The segmentation position is used to divide the incremental backup log into a fast replay segment and a precise replay segment. The fast replay segment is the transaction in the incremental backup log before the segmentation position, and the precise replay segment is the transaction in the incremental backup log from the start of the segmentation position to the transaction before the target transaction.

[0232] In some embodiments, the incremental backup log includes multiple log files arranged in chronological order, and the segmentation unit 320 is used for:

[0233] In the incremental backup log, the log file that first involves the target transaction is used as the split point;

[0234] Incremental backup logs are divided into fast replay segments and precise replay segments, including:

[0235] Divide the first to the (n-1)th log files into fast replay segments, where n is the sequence number of the log file corresponding to the segmentation position in the incremental backup log;

[0236] Divide the log file from the nth log file to the log file corresponding to the previous transaction of the target transaction into exact replay segments.

[0237] (III) Fast playback unit 330.

[0238] The fast playback unit 330 is used to perform backup and recovery processing on the fast playback segment using the fast playback method to obtain fast recovery data.

[0239] In some embodiments, the fast playback unit 330 is used for:

[0240] Multiple replay threads are used to replay transactions in the fast replay segment in parallel;

[0241] Once it is detected that all transactions in the fast replay segment have completed replay, parallel replay is stopped, and fast recovery data is obtained.

[0242] In some embodiments, the incremental backup log includes multiple log files arranged in chronological order, and multiple playback threads are used to perform parallel playback of transactions in the fast playback segment, further including:

[0243] The number of replay threads is determined based on the total number of log files contained in the fast replay segment;

[0244] If the density of parallel replay transactions exceeds a preset threshold, the number of replay threads is increased.

[0245] When the system resource utilization rate is detected to have reached its limit, the number of replay threads is reduced.

[0246] (iv) Precision playback unit 340.

[0247] The precise playback unit 340 is used to switch to precise playback mode, perform backup and recovery processing on the precise playback segment, and obtain precise recovery data.

[0248] In some embodiments, the precision playback unit 340 is used for:

[0249] Based on the original commit order of the transactions in the precise replay segment, a single replay thread is used to replay each transaction in the precise replay segment one by one.

[0250] Once the last transaction in the precise replay segment has finished replaying, the line-by-line replay stops, and the precise recovered data is obtained.

[0251] In practice, each of the above units can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units, please refer to the previous method embodiments, which will not be repeated here.

[0252] In this application embodiment, 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.

[0253] As described above, the data recovery device in this embodiment obtains the reference time input by the user through the acquisition unit and confirms the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database. The segmentation unit determines the segmentation position in the incremental backup log based on the target transaction. The segmentation position is used to divide the incremental backup log into a fast playback segment and a precise playback segment. The fast playback segment consists of transactions in the incremental backup log before the segmentation position, and the precise playback segment consists of transactions in the incremental backup log from the segmentation position to the transaction preceding the target transaction. The fast playback unit performs backup and recovery processing on the fast playback segment using the fast playback mode to obtain fast-recovered data. The precise playback unit switches to the precise playback mode to perform backup and recovery processing on the precise playback segment to obtain precise-recovered data. Therefore, this embodiment can improve the efficiency of data recovery.

[0254] This application also provides an electronic device, which can be a terminal, a server, or other similar device. The terminal can be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, personal computer, etc.; the server can be a single server or a server cluster composed of multiple servers, etc.

[0255] In some embodiments, the data recovery device may also be integrated into multiple electronic devices, such as multiple servers, with multiple servers implementing the data recovery method of this application.

[0256] In this embodiment, a server will be used as an example for detailed description. For example, ... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically:

[0257] The electronic device may include components such as a processor 410 with one or more processing cores, a memory 420 with one or more computer-readable storage media, a power supply 430, an input module 440, and a communication module 450. Those skilled in the art will understand that... Figure 4The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0258] The processor 410 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 420, and by calling data stored in the memory 420, it performs various functions and processes data, thereby performing overall detection of the electronic device. In some embodiments, the processor 410 may include one or more processing cores; in some embodiments, the processor 410 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 410.

[0259] The memory 420 can be used to store software programs and modules. The processor 410 executes various functional applications and data processing by running the software programs and modules stored in the memory 420. The memory 420 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 420 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 420 may also include a memory controller to provide the processor 410 with access to the memory 420.

[0260] The electronic device also includes a power supply 430 that supplies power to the various components. In some embodiments, the power supply 430 can be logically connected to the processor 410 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 430 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0261] The electronic device may also include an input module 440, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0262] The electronic device may also include a communication module 450. In some embodiments, the communication module 450 may include a wireless module, through which the electronic device can perform short-range wireless transmission, thereby providing users with wireless broadband internet access. For example, the communication module 450 can be used to help users send and receive emails, browse web pages, and access streaming media.

[0263] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 410 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 420 according to the following instructions, and the processor 410 runs the applications stored in the memory 420 to realize various functions, as follows:

[0264] Obtain the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database.

[0265] Based on the target transaction, the split position is confirmed in the incremental backup log. The split position is used to divide the incremental backup log into a fast replay segment and a precise replay segment. The fast replay segment is the transaction in the incremental backup log before the split position, and the precise replay segment is the transaction in the incremental backup log from the split position to the transaction before the target transaction.

[0266] The fast playback method is used to back up and restore the fast playback segment to obtain fast recovery data;

[0267] Switch to precise playback mode, perform backup and restore processing on the precise playback segment, and obtain precise restored data.

[0268] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0269] As can be seen from the above, the embodiments of this application can improve the efficiency of data recovery.

[0270] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0271] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the data recovery methods provided in embodiments of this application. For example, the instructions can execute the following steps:

[0272] Obtain the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log. The incremental backup log records multiple transactions that modify data in the database.

[0273] Based on the target transaction, the split position is confirmed in the incremental backup log. The split position is used to divide the incremental backup log into a fast replay segment and a precise replay segment. The fast replay segment is the transaction in the incremental backup log before the split position, and the precise replay segment is the transaction in the incremental backup log from the split position to the transaction before the target transaction.

[0274] The fast playback method is used to back up and restore the fast playback segment to obtain fast recovery data;

[0275] Switch to precise playback mode, perform backup and restore processing on the precise playback segment, and obtain precise restored data.

[0276] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0277] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in various optional implementations of the data recovery or data backup aspects provided in the above embodiments.

[0278] Since the instructions stored in the storage medium can execute the steps of any of the data recovery methods provided in the embodiments of this application, the beneficial effects that any of the data recovery methods provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0279] The data recovery method, apparatus, electronic device, and computer-readable storage medium provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data recovery method, characterized in that, include: Obtain the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log, which records multiple transactions that modify data in the database; Based on the target transaction, the split position is confirmed in the incremental backup log. The split position is used to divide the incremental backup log into a fast replay segment and a precise replay segment. The fast replay segment is the transaction in the incremental backup log before the split position. The precise replay segment is the transaction in the incremental backup log from the split position to the transaction preceding the target transaction. The fast playback segment is backed up and restored using a fast playback method to obtain fast recovery data; Switch to precise playback mode, perform backup and restore processing on the precise playback segment, and obtain precise restored data.

2. The data recovery method as described in claim 1, characterized in that, The incremental backup log includes multiple log files arranged in chronological order. The step of confirming the split position in the incremental backup log based on the target transaction includes: In the incremental backup log, the log file that first involves the target transaction is used as the split point; The step of dividing the incremental backup log into a fast replay segment and a precise replay segment includes: The first to the (n-1)th log files are divided into fast replay segments, where n is the sequence number of the log file corresponding to the segmentation position in the incremental backup log; Divide the log file from the nth log file to the log file corresponding to the previous transaction of the target transaction into exact replay segments.

3. The data recovery method as described in claim 1, characterized in that, The step of obtaining the reference time input by the user and confirming the target transaction corresponding to the reference time in the incremental backup log includes: Obtain the reference time input by the user, and confirm that the reference time corresponds to at least one pending transaction in the incremental backup log; Query and display the data changes corresponding to the at least one transaction to be confirmed; In response to a user's selection operation for the at least one transaction to be confirmed, a target transaction is selected from the at least one transaction to be confirmed.

4. The data recovery method as described in claim 1, characterized in that, The step of obtaining the reference time input by the user and confirming at least one pending transaction corresponding to the reference time in the incremental backup log includes: The input page is displayed, which includes a standby machine selection control and a time input control. The standby machine selection control is used to select a standby machine, and the standby machine is used to store incremental backup logs. In response to the user's standby selection operation using the standby selection control, incremental backup logs are obtained; In response to the user's time input operation on the time input control, a reference time is obtained; Confirm at least one pending transaction in the incremental backup log corresponding to the reference time.

5. The data recovery method as described in any one of claims 3 or 4, characterized in that, The confirmation of at least one pending transaction corresponding to the reference time in the incremental backup log includes: The analysis time period is determined based on the reference time. Query all transactions involving the parsing time period in the incremental backup log, and treat all transactions involving the parsing time period as pending confirmation transactions.

6. The data recovery method as described in claim 3, characterized in that, The querying and displaying of the data changes corresponding to the at least one pending confirmation transaction includes: Query the data changes corresponding to at least one transaction to be confirmed; A viewing page is displayed, which shows at least one transaction to be confirmed. The viewing page includes a content display area, a confirmation control, and a start recovery control. In response to a user's selection operation for a transaction to be confirmed, the data change content of the transaction to be confirmed corresponding to the selection operation is displayed in the content display area.

7. The data recovery method as described in claim 6, characterized in that, The step of selecting a target transaction from the at least one pending confirmation transaction in response to a user's selection operation for the at least one pending confirmation transaction includes: In response to the user's confirmation operation on the confirmation control, the transaction to be confirmed corresponding to the data change content displayed in the content display area is taken as the target transaction.

8. The data recovery method as described in claim 6, characterized in that, The viewing page also includes a control for modifying the reference time, and the display viewing page also includes: In response to the user's modification operation on the time point of the modified reference time control, the reference time is re-acquired, and the pending confirmation transactions on the viewing page are updated based on the re-acquired reference time.

9. The data recovery method as described in claim 1, characterized in that, The method employs fast playback to perform backup and recovery processing on the fast playback segment, obtaining fast recovery data, including: Multiple replay threads are used to replay the transactions in the fast replay segment in parallel; Once it is detected that all transactions in the fast replay segment have been completed, parallel replay is stopped, and fast recovery data is obtained.

10. The data recovery method as described in claim 9, characterized in that, The incremental backup log includes multiple log files arranged in chronological order, and the method of using multiple replay threads to perform parallel replay of transactions in the fast replay segment further includes: The number of threads for the playback thread is determined based on the total number of log files contained in the fast playback segment. If the density of parallel replay transactions exceeds a preset threshold, the number of replay threads is increased. When the system resource utilization rate is detected to have reached its limit, the number of replay threads is reduced.

11. The data recovery method as described in claim 1, characterized in that, The process of switching to precise playback mode involves backing up and restoring the precise playback segment to obtain precise recovery data, including: According to the original commit order of the transactions in the precise replay segment, a single replay thread is used to replay each transaction in the precise replay segment one by one. Once the last transaction in the precise replay segment has been replayed, the replay process stops, and the precisely recovered data is obtained.

12. A data recovery device, characterized in that, include: The acquisition unit is used to acquire the reference time input by the user and confirm the target transaction corresponding to the reference time in the incremental backup log, wherein the incremental backup log records multiple transactions that modify data in the database. A segmentation unit is used to determine the segmentation position in the incremental backup log according to the target transaction. The segmentation position is used to divide the incremental backup log into a fast replay segment and a precise replay segment. The fast replay segment is the transaction in the incremental backup log before the segmentation position, and the precise replay segment is the transaction in the incremental backup log from the segmentation position to the transaction preceding the target transaction. The fast playback unit is used to perform backup and recovery processing on the fast playback segment using a fast playback method to obtain fast recovery data; The precise playback unit is used to switch to precise playback mode, perform backup and recovery processing on the precise playback segment, and obtain precise recovery data.

13. An electronic device, characterized in that, The system includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps of the data recovery method as described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the data recovery method according to any one of claims 1 to 12.

15. A computer program product comprising computer instructions stored in a computer-readable storage medium, wherein a processor of an electronic device reads the computer instructions from the computer-readable storage medium and loads the instructions from the memory to perform the steps of the data recovery method as claimed in any one of claims 1 to 12.

Images