Database data recovery method and device

Abstract

The embodiment of the invention discloses a database data recovery method, which comprises the following steps of: monitoring a target file, and judging whether a specified event occurs in the target file or not; if the specified event occurs in the target file, executing data recovery operation; wherein the execution of the data recovery operation comprises the steps of creating a new file under a path of the target file, reading the content of the target file through a file descriptor corresponding to the target file, copying the read content of the target file into the new file, and obtaining a recovered file based on the new file after the content is copied.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a database data recovery method and device. Background Art

[0002] The database relies on key files such as data files, redo log files, and control files during operation. If any of these files is lost, the database may not operate normally, resulting in data loss or system inconsistency.

[0003] In the prior art, when the database finds that a data file is lost or moved, it is usually recommended that the user perform a logical backup and restore it by themselves without stopping the database. However, this method is often time-consuming and complicated to operate, and the recovery efficiency is low. Summary of the invention

[0004] The present application provides a database data recovery method and device to solve the technical problem of how to recover database data more effectively and efficiently.

[0005] In order to solve the above technical problems, this application provides the following technical solutions:

[0006] The present application provides a database data recovery method, the method comprising:

[0007] Monitor the target file to determine whether a specified event occurs in the target file;

[0008] If a specified event occurs in the target file, a data recovery operation is performed;

[0009] The data recovery operation includes:

[0010] A new file is created under the path of the target file, the content of the target file is read through the file descriptor corresponding to the target file, and the read content of the target file is copied to the new file, and the restored file is obtained based on the new file after the content is copied.

[0011] Optionally, the restored files based on the new files after content copying include:

[0012] The new file after content copying is completed is used as the restored file.

[0013] Optionally, the restored files based on the new files after content copying include:

[0014] After the content copy is completed, the dirty pages of the target file in the memory are flushed back to the new file to obtain the restored file.

[0015] Optionally, monitoring of target files includes:

[0016] Create an ifify instance, add the target file to be monitored to the ifify instance, so as to monitor the target file;

[0017] and / or,

[0018] Create an ifify instance and add the directory to be monitored to the ifify instance to monitor the target files in the directory.

[0019] Optionally, determining whether a specified event occurs in the target file includes:

[0020] The designated event is monitored to determine whether the designated event occurs in the target file.

[0021] Optionally, monitoring of specified events includes:

[0022] The kernel monitors whether a specified event occurs on the target file;

[0023] When the designated event occurs in the target file, event information of the designated event is put into an event queue associated with the file descriptor corresponding to the target file.

[0024] Optionally, monitoring of specified events also includes:

[0025] The file descriptor corresponding to the target file is read by polling to determine whether a specified event occurs in the target file.

[0026] Optionally, the data recovery operation is performed after a preset condition is triggered.

[0027] Optionally, the method further includes:

[0028] If a specified event occurs in the target file, determining that the target file is in a specific state;

[0029] When an operation involving a target file needs to be performed, the target file is checked;

[0030] If the target file is in a specific state, a preset prompt message is displayed;

[0031] Determine whether a preset condition is triggered based on operation information on the preset prompt information.

[0032] Optionally, the operations involving the target file include:

[0033] DML operations involving a target file and / or flushing dirty pages of the target file.

[0034] Optionally, before performing the data recovery operation, the method further includes:

[0035] Modify the database status so that the database does not provide external services;

[0036] and / or,

[0037] Modify the state of the target file to a state where the specified event does not occur;

[0038] and / or,

[0039] After performing the data recovery operation, the method further includes:

[0040] Enable the database to provide external services.

[0041] Optionally, after obtaining the restored file, the method further includes:

[0042] Verifying each page of the restored file;

[0043] If the verification of a page fails, the corresponding processing operation is determined according to the page that fails the verification.

[0044] Optionally, after obtaining the restored file, the method further includes:

[0045] Verifying each page of the restored file;

[0046] Among them, for any page, the verification operation for the page includes: performing an XOR operation on the page to obtain a verification code; comparing the obtained verification code with the verification code of the first 8 bytes of the page to determine whether the verification of the page is successful.

[0047] Optionally, the method further includes:

[0048] Record the information corresponding to the data recovery operation in the log.

[0049] The present application provides a database data recovery device, the device comprising:

[0050] A monitoring module, used to monitor the target file and determine whether a specified event occurs to the target file;

[0051] A recovery module, used for executing a data recovery operation if a specified event occurs in the target file;

[0052] The data recovery operation includes:

[0053] A new file is created under the path of the target file, the content of the target file is read through the file descriptor corresponding to the target file, and the read content of the target file is copied to the new file, and the restored file is obtained based on the new file after the content is copied.

[0054] At least one of the above technical solutions adopted in this application can achieve the following beneficial effects:

[0055] When database files need to be recovered, effective file recovery can be performed by holding open file descriptors, which can effectively reduce the time spent on database data recovery, recover lost data to the greatest extent, and improve the efficiency and effectiveness of database data recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings required for use in the embodiments of this specification or the prior art description are briefly described below. Obviously, the following only describes the drawings required for use in some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative labor.

[0057] Figure 1 It is a flowchart of the database data recovery method provided in the first embodiment of the present application.

[0058] Figure 2 It is a schematic diagram of the database data recovery process in the first embodiment of the present application.

[0059] Figure 3 It is a schematic diagram of the file detection process in the first embodiment of the present application.

[0060] Figure 4 It is a schematic diagram of the file recovery process in the first embodiment of the present application.

[0061] Figure 5 It is a schematic diagram of the file verification process in the first embodiment of the present application.

[0062] Figure 6 It is a structural diagram of a database data recovery device provided in the second embodiment of the present application. DETAILED DESCRIPTION

[0063] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments involved in the specific implementation methods are only part of the embodiments of this application, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the specific implementation methods without making creative work should belong to the scope of protection of this application.

[0064] The first embodiment of this specification (hereinafter referred to as "embodiment one") provides a database data recovery method. The execution subject of embodiment one includes but is not limited to a terminal or a server or an operating system or an application, that is, the execution subject can be various and can be set, used or changed as needed. In addition, a third-party application can also assist the execution subject in executing embodiment one. For example, the database data recovery method in embodiment one can be executed by a server, and a corresponding application can be installed on a terminal (the terminal can be held by a user), and data can be transmitted between the terminal or the application and the server, thereby assisting the server in executing the database data recovery method in embodiment one.

[0065] In particular, the execution subject of the first embodiment may be a database.

[0066] like Figure 1 and Figure 2 As shown, the database data recovery method provided in the first embodiment includes:

[0067] S101: monitoring a target file and a specified event, and when the specified event occurs to the target file, determining that the target file is in a state to be restored;

[0068] In the first embodiment, one or more files can be monitored, and the monitored file can be called a target file. By monitoring the target file, it can be determined whether a specified event has occurred in the target file (equivalent to also monitoring the specified event).

[0069] Among them, monitoring the target file may include: creating an ify instance, adding a target file or directory to be monitored to the ify instance, so as to monitor the target file; and / or, creating an ify instance, adding a directory to be monitored to the ify instance, so as to monitor the target file in the directory.

[0070] Determining whether a designated event occurs in the target file may include: monitoring the designated event to determine whether the designated event occurs in the target file.

[0071] Specifically, monitoring the specified event may include: the kernel monitoring whether the specified event occurs on the target file or directory; when the specified event occurs in the target file, putting the event information of the specified event into an event queue, where the event queue is an event queue associated with the file descriptor corresponding to the target file (the file descriptor is located in the ify instance) .

[0072] Monitoring the specified event may also include: polling and reading the file descriptor corresponding to the target file to determine whether the specified event occurs in the target file. That is, the database process may poll and read the file descriptor to obtain the event notified by the kernel (the notified event is the specified event). Once the event notification is received, it can be determined that the specified event has occurred in the target file, and the database may perform corresponding operations (including data recovery operations) according to the event type of the specified event.

[0073] The following are further optional ways to monitor target files and specified events:

[0074] Specifically, the target file and the specified event can be monitored through the ifify mechanism. The database process can create an ifify instance by calling the relevant system interface (such as ifify_init() system interface) and obtain the file descriptor for communication with the kernel. The database can call the relevant system interface (such as ifify_add_watch() system interface) to add a monitor to the ifify instance. The monitor can be a file and / or a directory. If the monitor is a file, the added file is the target file; if the monitor is a directory, one or some files under the directory can be specified as the target file.

[0075] The database can specify the event type to be monitored (i.e., specified events, such as file creation, deletion, modification, etc.) to monitor the specified events. Once the monitor is added successfully, the kernel starts to monitor the specified events on the corresponding file or directory (i.e., the monitor), that is, to determine whether the specified event occurs on the corresponding file or directory.

[0076] In the first embodiment, if it is determined that a specified event has occurred in the target file, it can be determined that the target file is in a specific state, and the specific state can be recorded with corresponding information. The specific state can be set as needed, for example, the specific state can be a lost state or a state to be restored. For example, if the target file is deleted or moved (belonging to the specified event), it can be determined that the target file is in a specific state. Correspondingly, if the target file is found to be in a specific state when checking or detecting the target file, it can be identified that the target file is deleted or moved.

[0077] S103: If a specified event occurs in the target file, a data recovery operation is performed; wherein the data recovery operation includes: creating a new file under the path of the target file, reading the content of the target file through the file descriptor corresponding to the target file, and copying the read content of the target file to the new file, and obtaining a recovered file based on the new file after the content is copied.

[0078] In the first embodiment, if it is determined that a specified event has occurred in the target file, a data recovery operation may be performed to obtain a recovered file.

[0079] The data recovery operation may be performed automatically after determining that a specified event has occurred in the target file, or may be performed after determining that a specified event has occurred in the target file and a preset condition is triggered.

[0080] Among them, whether the preset condition is triggered can be determined in the following ways:

[0081] When it is necessary to perform an operation involving a target file, it is necessary to access the target file, which triggers monitoring and checking of the target file, i.e., it is necessary to check the target file. Wherein, the operation involving the target file may include a DML (data manipulation language) operation involving the target file (i.e., a DML statement involves the target file) or a dirty page of the target file may be flushed back (the flushing back here may be a periodic automatic flushing back). In addition, one of the inspection methods for the target file may be to check the state of the target file, specifically, to check the state of the target file through an ifi fy mechanism, and to identify whether the target file is lost or moved according to whether the target file is in a specific state.

[0082] If the target file is in the above-mentioned specific state, the preset prompt information is displayed; according to the operation information of the preset prompt information, it is determined whether the preset condition is triggered. For example, the preset prompt information can be a prompt to the user to detect that the file (i.e., the target file) is lost or moved, and whether the file needs to be restored. If the user confirms or chooses to restore (i.e., the operation information of the preset prompt information), the preset condition is triggered. Of course, the preset prompt information can be set as needed, and the first embodiment is not limited.

[0083] The above content can be used as the file detection stage. An example of the overall process of the file detection stage can be as follows: Figure 3As shown, it includes: creating an ify instance, and adding files or directories to be monitored, and the kernel monitors the specified event. When a specified event occurs in the target file, the database obtains the event notified by the kernel, thereby detecting that the target file is lost or moved, and modifying the target file to a lost state. When the user performs a DML operation involving the target file or periodically flushes the dirty page of the target file, the target file needs to be accessed, so the target file is checked. Since the target file is deleted or moved (i.e., the specified event occurs), the target file cannot be accessed, thereby determining that the target file is in a specific state, and displaying a preset prompt message to prompt the user that the file is detected to be lost or moved.

[0084] The following content can be used as a file recovery stage.

[0085] In embodiment 1, performing a data recovery operation may include: creating a new file under the path of the target file, reading the content of the target file through the file descriptor corresponding to the target file, and copying the read content of the target file to the new file, and obtaining a recovered file based on the new file after the content is copied.

[0086] Specifically, taking the Linux system as an example, when the database opens a file, the kernel will assign a file descriptor to the file and create a reference to the open file in the file system. If a file is deleted, but the database still holds the corresponding file descriptor, the database can still continue to read and write the file. That is, deleting a file only deletes the directory entry of the file from the file system. The operation of deleting a file is only a logical mark deletion, and the file content is not immediately physically cleared, that is, the file content is not actually deleted. Although the file is deleted, the open file descriptor still exists, and the already opened file content can continue to be accessed.

[0087] In the first embodiment, during the data recovery operation, a new file can be created under the path of the target file, and the target file can be accessed through the opened file descriptor to read the contents of the target file and write them into the new file, i.e., copy them into the new file.

[0088] In the first embodiment, the restored file can be obtained based on the new file after the content is copied. The restored file obtained based on the new file after the content is copied may include the following contents described in the first or second case:

[0089] Case 1: The new file after the content is copied is used as the restored file, that is, the target file after restoration.

[0090] Case 2: After the content copy is completed, the dirty pages of the target file in the memory (i.e., the dirty pages belonging to the target file) are flushed back to the new file to obtain the recovered file. That is to say, as described above, the content copy operation to the new file is performed, and after the content copy is completed, the dirty pages involved in the target file in the memory are flushed back to the new file, so that the pages corresponding to the dirty pages in the new file are updated with the dirty pages. The new file after the dirty pages are flushed back can be used as the recovered file, that is, the recovered target file.

[0091] In Embodiment 1, before executing the data recovery operation, the database state can be modified so that the database does not provide external services (i.e., external clients cannot connect to the database); and / or, after executing the data recovery operation, the database can provide external services normally (i.e., if the database state has been modified before, the database state can be restored to the state before the modification); and / or, before executing the data recovery operation, the state of the target file can be modified to a state where a specified event has not occurred, that is, the target file is no longer in the above-mentioned specific state. Among them, the modified state of the target file can be set as needed, for example, the state of the target file where the specified event has not occurred can be a normal state. The purpose of modifying the state of the target file is to avoid detecting that the target file is in a specific state again during the execution of the data recovery operation, thereby avoiding the above-mentioned preset prompt information from appearing again.

[0092] An example of the overall process of the file recovery phase can be as follows Figure 4 As shown, it includes: file recovery starts, database status and target file status are modified. Data recovery operations are performed, content is copied, and dirty pages are flushed. The recovered file is obtained and the database status is restored.

[0093] The following content can be used as the file verification stage.

[0094] In the first embodiment, after obtaining the recovered file, each page of the recovered file can be verified (for example, each page is verified in sequence). If all pages are successfully verified, it means that the data recovery is successful; if a page is unsuccessful in verification, the corresponding processing operation is determined according to the page that failed to be verified.

[0095] Among them, a CRC (cyclic redundancy check) check method can be used. For any page, the page check operation includes: performing an XOR operation on the page to obtain a check code; comparing the obtained check code with the check code of the first 8 bytes of the page to determine whether the check of the page is successful.

[0096] The database page is in units of 8k. Before writing the page content of the file to disk, a checksum is calculated by XORing the page content, and the checksum is saved in the first 8 bytes of the page, and then written to disk together with the page content.

[0097] In the first embodiment, for any page of the recovered file, an XOR operation is performed on the content of the page to obtain a check code (hereinafter referred to as "check code A"). In addition, the check code of the first 8 bytes of the page (hereinafter referred to as "check code B") is read. Check code A and check code B are compared to determine whether the check of the page is successful. Specifically, if check code A and check code B are the same, the page is successfully checked; if check code A and check code B are different, the page fails to be checked.

[0098] In the first embodiment, if there is a page verification failure, the corresponding processing operation can be determined according to the page that failed to be verified. Specifically, according to the above-mentioned situation one and situation two, the page of the restored file can have two sources, one is the page obtained after reading from the target file and writing into the new file, and the other is the page obtained after reading from the target file and writing into the new file, and then being flushed back to the dirty page. If the page that failed to be verified is from the former source, it means that the content of the page may be tampered with or the data has an error in the storage process (there may be other reasons, which are not limited to the first embodiment), so the user can be prompted to perform corresponding processing operations, such as anti-tampering operations. If the page that failed to be verified is from the latter source, it means that the process of flushing back the dirty page may have an error or the data has an error in the storage process (there may be other reasons, which are not limited to the first embodiment), then the user can be prompted to perform corresponding processing operations, such as the operation of re-flushing the dirty page. Of course, according to the page that failed to be verified, the corresponding processing operations can be various, for example, the processing operation can also prompt the user to manually perform logical backup recovery after closing the file monitoring parameters. What kind of processing operation the page that failed to be verified specifically corresponds to can be set as needed.

[0099] In addition, after the data recovery operation is completed, all pages of the recovered file can be verified, regardless of whether there are pages that have failed to be verified. Alternatively, during the data recovery operation, as long as the pages have been written or flushed back to the new file, the above-mentioned verification operation can be performed on the pages that have been written or flushed back to the new file. If any page fails to be verified, the data recovery operation can be stopped. In either case, the corresponding processing operation can be determined based on the page that failed to be verified.

[0100] An example of the overall process of the file verification phase can be as follows Figure 5 As shown, it includes: after the verification starts, traverse the file (that is, traverse each page of the restored file), calculate the verification code A and read the verification code B for each page, and compare the verification code A and the verification code B to determine whether the verification is successful.

[0101] In the first embodiment, the information corresponding to the data recovery operation can be recorded in a log (eg, a database log) for easy viewing. The information corresponding to the data recovery operation includes but is not limited to the target file information to be recovered. The first embodiment does not limit the content of the information.

[0102] The target file described in the first embodiment may be various database files, such as one or more of a data file, a redo log file, and a control file, or may be other files, which is not limited to the first embodiment.

[0103] Embodiment 1 can achieve the following beneficial effects:

[0104] When a specified event occurs to a database target file (the occurrence of a specified event generally means that the target file is abnormal, such as lost or moved), data can be read and written from the file system by holding an open file descriptor, including reading the entire content of the target file and writing it into a new file, thereby performing effective and complete file recovery, which can effectively reduce the time consumption of database data recovery, and restore the lost data to the greatest extent, thereby improving the efficiency and effect of database data recovery. It can be seen that embodiment 1 provides a powerful and reliable fault-tolerant mechanism for the database system, so that it can still perform effective and efficient data recovery in the face of abnormal situations such as file loss, effectively maintain service availability and data consistency, reduce the operational risk of the database, and improve the stability of the database and the integrity of the data.

[0105] At the same time, data recovery can be automatically performed after a specified event occurs in the target file, or when an operation involving the target file is performed, a preset prompt message can be used to prompt so that recovery can be performed as soon as possible, thereby improving the timeliness of data recovery operations and reducing the time the database is unavailable.

[0106] Since the new file is created in the same path as the target file, the target file path and directory after recovery are guaranteed to remain unchanged, without affecting its normal use, further improving data recovery efficiency and effectiveness.

[0107] During the data recovery process, not only can the entire content of the target file be read and written into a new file, but the dirty pages of the target file in the memory can also be flushed back to the new file, ensuring that the data in the new file is consistent with the data on the dirty pages. This ensures that the dirty pages of the target file in the memory are written to the disk in time, and that the data in the recovered file is the latest data, further improving the data accuracy of the recovered file and improving the data recovery effect.

[0108] In the first embodiment, each page of the recovered file can be verified, so as to accurately determine whether the data recovery operation is successful, and further improve the data recovery efficiency. If a page verification fails, the corresponding processing operation is determined according to the page that failed the verification, so that the processing operation is taken according to the specific situation of the page that failed the verification, ensuring the matching of the processing operation with the page that failed the verification and the rationality of the processing operation, and improving the processing effect after the verification fails.

[0109] Embodiment 1 realizes the monitoring of target files and designated events. Once the designated event occurs in the target file, an alarm is given in time, and transaction submission can be prohibited; or, once the designated event occurs in the target file, the database state can be modified so that the database does not provide services to the outside. In this way, further loss of user data can be effectively avoided. In particular, the ifif mechanism can be utilized, which is an efficient file system monitoring mechanism that allows applications to monitor changes in files or directories on the file system in real time. Through the ifif mechanism, the database can timely discover designated events performed by external processes on the target file, such as deletion or move operations, thereby improving the monitoring efficiency of the target file and designated events.

[0110] like Figure 6 As shown, the second embodiment of this specification provides a database data recovery device corresponding to the method described in the first embodiment, including:

[0111] A monitoring module 202 is used to monitor the target file and determine whether a specified event occurs in the target file;

[0112] The recovery module 204 is used to perform a data recovery operation if a specified event occurs in the target file;

[0113] The data recovery operation includes:

[0114] A new file is created under the path of the target file, the content of the target file is read through the file descriptor corresponding to the target file, and the read content of the target file is copied to the new file, and the restored file is obtained based on the new file after the content is copied.

[0115] Optionally, the restored files based on the new files after content copying include:

[0116] The new file after content copying is completed is used as the restored file.

[0117] Optionally, the restored files based on the new files after content copying include:

[0118] After the content copy is completed, the dirty pages of the target file in the memory are flushed back to the new file to obtain the restored file.

[0119] Optionally, monitoring of target files includes:

[0120] Create an ifify instance, add the target file to be monitored to the ifify instance, so as to monitor the target file;

[0121] and / or,

[0122] Create an ifify instance and add the directory to be monitored to the ifify instance to monitor the target files in the directory.

[0123] Optionally, determining whether a specified event occurs in the target file includes:

[0124] The designated event is monitored to determine whether the designated event occurs in the target file.

[0125] Optionally, monitoring of specified events includes:

[0126] The kernel monitors whether a specified event occurs on the target file;

[0127] When the designated event occurs in the target file, event information of the designated event is put into an event queue associated with the file descriptor corresponding to the target file.

[0128] Optionally, monitoring of specified events also includes:

[0129] The file descriptor corresponding to the target file is read by polling to determine whether a specified event occurs in the target file.

[0130] Optionally, the data recovery operation is performed after a preset condition is triggered.

[0131] Optionally, the monitoring module 202 is further used for:

[0132] If a specified event occurs in the target file, it is determined that the target file is in a specific state.

[0133] When an operation involving a target file needs to be performed, the target file is checked;

[0134] If the target file is in a specific state, a preset prompt message is displayed;

[0135] Determine whether a preset condition is triggered based on operation information on the preset prompt information.

[0136] Optionally, the operations involving the target file include:

[0137] DML operations involving a target file and / or flushing dirty pages of the target file.

[0138] Optionally, the recovery module 204 is further used to: before performing the data recovery operation, modify the database state so that the database does not provide external services; and / or, before performing the data recovery operation, modify the state of the target file to a state where no specified event occurs;

[0139] and / or,

[0140] After performing the data recovery operation, the database is made available to the outside world.

[0141] Optionally, the recovery module 204 is further used to: after obtaining the recovered file, verify each page of the recovered file;

[0142] If the verification of a page fails, the corresponding processing operation is determined according to the page that fails the verification.

[0143] Optionally, the recovery module 204 is further used to: after obtaining the recovered file, verify each page of the recovered file;

[0144] Among them, for any page, the verification operation for the page includes: performing an XOR operation on the page to obtain a verification code; comparing the obtained verification code with the verification code of the first 8 bytes of the page to determine whether the verification of the page is successful.

[0145] Optionally, the recovery module 204 is further configured to record information corresponding to the data recovery operation in a log.

[0146] The second embodiment can achieve the same beneficial effects as the first embodiment.

[0147] The above embodiments can be used in combination.

[0148] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for recovering database data, characterized in that: The method comprises: Monitor the target file to determine whether a specified event occurs in the target file; If a specified event occurs in the target file, a data recovery operation is performed; The data recovery operation includes: A new file is created under the path of the target file, the content of the target file is read through the file descriptor corresponding to the target file, and the read content of the target file is copied to the new file, and the restored file is obtained based on the new file after the content is copied.

2. The method according to claim 1, characterized in that The restored files based on the new files after content copying include: The new file after content copying is completed is used as the restored file.

3. The method according to claim 1, characterized in that The restored files based on the new files after content copying include: After the content copy is completed, the dirty pages of the target file in the memory are flushed back to the new file to obtain the restored file.

4. The method according to claim 1, characterized in that Monitoring of target files includes: Create an inotify instance and add the target file to be monitored to the inotify instance to monitor the target file; and / or, Create an inotify instance and add the directory to be monitored to the inotify instance to monitor the target files in the directory.

5. The method according to any one of claims 1 to 4, characterized in that Determining whether a specified event occurs in the target file includes: The designated event is monitored to determine whether the designated event occurs in the target file.

6. The method according to claim 5, characterized in that Monitoring of specified events includes: The kernel monitors whether a specified event occurs on the target file; When the designated event occurs in the target file, event information of the designated event is put into an event queue associated with the file descriptor corresponding to the target file.

7. The method according to claim 6, characterized in that Monitoring of specified events also includes: The file descriptor corresponding to the target file is read by polling to determine whether a specified event occurs in the target file.

8. The method according to claim 1, characterized in that The data recovery operation is performed after a preset condition is triggered.

9. The method according to claim 8, characterized in that The method further comprises: If a specified event occurs in the target file, determining that the target file is in a specific state; When an operation involving a target file needs to be performed, the target file is checked; If the target file is in a specific state, a preset prompt message is displayed; Determine whether a preset condition is triggered based on operation information on the preset prompt information.

10. The method according to claim 9, characterized in that The operations involving the target file include: DML operations involving a target file and / or flushing dirty pages of the target file.

11. The method according to claim 1, characterized in that Before performing the data recovery operation, the method further includes: Modify the database status so that the database does not provide external services; and / or, Modify the state of the target file to a state where the specified event does not occur; and / or, After performing the data recovery operation, the method further includes: Enable the database to provide external services.

12. The method according to claim 1, characterized in that After obtaining the restored file, the method further includes: Verifying each page of the restored file; If the verification of a page fails, the corresponding processing operation is determined according to the page that fails the verification.

13. The method according to claim 1, characterized in that After obtaining the restored file, the method further includes: Verifying each page of the restored file; Among them, for any page, the verification operation for the page includes: performing an XOR operation on the page to obtain a verification code; comparing the obtained verification code with the verification code of the first 8 bytes of the page to determine whether the verification of the page is successful.

14. The method according to claim 1, wherein: The method further comprises: Record the information corresponding to the data recovery operation in the log.

15. A database data recovery device, characterized in that: The device comprises: A monitoring module, used to monitor the target file and determine whether a specified event occurs to the target file; A recovery module, used for executing a data recovery operation if a specified event occurs in the target file; The data recovery operation includes: A new file is created under the path of the target file, the content of the target file is read through the file descriptor corresponding to the target file, and the read content of the target file is copied to the new file, and the restored file is obtained based on the new file after the content is copied.

Images