A method and device for database data recovery

Abstract

The embodiments of this specification disclose a method for database data recovery. The method includes: monitoring a target file to determine whether a specified event occurs to the target file; if the specified event occurs to the target file, performing a data recovery operation; wherein, performing 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 copying.

Description

Technical Field

[0001] This application relates to the field of database technologies, and in particular, to a method and apparatus for database data recovery. Background Art

[0002] During operation, a database depends on key files such as data files, redo log files, and control files. If any of these files is lost, the database may not run properly, resulting in data loss or system inconsistency.

[0003] In the prior art, when a database detects that a data file is lost or moved, it is usually recommended that the user perform a logical backup and self-recovery in an environment without stopping the database. However, this method is often time-consuming and complex to operate, and the recovery efficiency is low. Summary of the Invention

[0004] This application provides a method and apparatus for database data recovery to solve the technical problem of how to perform database data recovery more effectively and efficiently.

[0005] To solve the above technical problem, this application provides the following technical solutions:

[0006] This application provides a method for database data recovery, and the method includes:

[0007] Monitor a target file and determine whether a specified event has occurred to the target file;

[0008] If the specified event has occurred to the target file, perform a data recovery operation;

[0009] Among them, performing the data recovery operation includes:

[0010] Create a new file in the path of the target file, read the content of the target file through the file descriptor corresponding to the target file, and copy the read content of the target file to the new file, and obtain a recovered file based on the new file after the content copy.

[0011] Optionally, obtaining a recovered file based on the new file after the content copy includes:

[0012] Use the new file after the content copy is completed as the recovered file.

[0013] Optionally, obtaining a recovered file based on the new file after the content copy includes:

[0014] After the content copy is completed, flush the dirty pages of the target file in the memory to the new file to obtain a recovered file.

[0015] Optionally, monitoring the target file includes:

[0016] Create an i not i fy instance, add the target file to be monitored to the i not i fy instance to monitor the target file;

[0017] And / or,

[0018] Create an i not i fy instance, add the directory to be monitored to the i not i fy instance to monitor the target files in the directory.

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

[0020] Monitor the specified event to determine whether the specified event occurs in the target file.

[0021] Optionally, monitoring the specified event includes:

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

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

[0024] Optionally, monitoring the specified event further includes:

[0025] Poll and read the file descriptor corresponding to the target file to determine whether the specified event occurs in the target file.

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

[0027] Optionally, the method further includes:

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

[0029] When an operation involving the target file needs to be executed, check the target file;

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

[0031] Determine whether to trigger a preset condition according to the operation information of the preset prompt message.

[0032] Optionally, the operation involving the target file includes:

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

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

[0035] Modifying the database status so that the database does not provide services externally;

[0036] And / or

[0037] Modifying the status of the target file to a status where the specified event has not occurred;

[0038] And / or

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

[0040] Enabling the database to provide services externally.

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

[0042] Verifying each page of the recovered file;

[0043] If any page verification fails, determining the corresponding processing operation according to the page where the verification fails.

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

[0045] Verifying each page of the recovered file;

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

[0047] Optionally, the method further includes:

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

[0049] This application provides a database data recovery device, and the device includes:

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

[0051] A recovery module, configured to perform a data recovery operation if the specified event occurs to the target file;

[0052] Among them, performing the data recovery operation includes:

[0053] Create a new file under the path of the target file, read the content of the target file through the file descriptor corresponding to the target file, and copy the read content of the target file to the new file, and obtain the restored file based on the new file after the content is copied.

[0054] The above at least one technical solution adopted by this application can achieve the following beneficial effects:

[0055] In the case where the database file needs to be restored, it is possible to perform effective file restoration by holding the opened file descriptor, which can effectively reduce the time-consuming of database data restoration, maximize the restoration of lost data, and improve the efficiency and effect of database data restoration. 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 following will briefly introduce the drawings required for the description of the embodiments of this specification or the prior art. Obviously, the following only shows the drawings required for some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0057] Figure 1 is a schematic flow chart of the database data restoration method provided by the first embodiment of this application.

[0058] Figure 2 is a schematic flow chart of the database data restoration process in the first embodiment of this application.

[0059] Figure 3 is a schematic flow chart of the file detection process in the first embodiment of this application.

[0060] Figure 4 is a schematic flow chart of the file restoration process in the first embodiment of this application.

[0061] Figure 5 is a schematic flow chart of the file verification process in the first embodiment of this application.

[0062] Figure 6 is a schematic structural diagram of the database data restoration device provided by the second embodiment of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0063] 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 manners are only a part of the embodiments of this application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the specific implementation manners without creative efforts shall fall within the protection scope of this application.

[0064] The first embodiment of this specification (hereinafter referred to as "Embodiment 1") provides a method for database data recovery. The execution subject of Embodiment 1 includes but is not limited to a terminal, a server, an operating system, or an application program. That is, the execution subject can be diverse and can be set, used, or transformed according to needs. In addition, a third-party application program can assist the execution subject in executing Embodiment 1. For example, the database data recovery method in Embodiment 1 can be executed by a server, and a corresponding application program can be installed on a terminal (which can be held by a user). Data transmission can occur between the terminal or the application program and the server to assist the server in executing the database data recovery method in Embodiment 1.

[0065] Specifically, the execution subject of Embodiment 1 can be a database.

[0066] As Figure 1 and Figure 2 shown, the database data recovery method provided by Embodiment 1 includes:

[0067] S101: Monitor the target file and a specified event. When the specified event occurs to the target file, determine that the target file is in a state to be recovered;

[0068] In Embodiment 1, one or some files can be monitored. The files being monitored can be called target files. By monitoring the target files, it can be determined whether a specified event has occurred to the target files (which is equivalent to also monitoring the specified event).

[0069] Among them, monitoring the target file can include: creating an inotify instance and adding the target file or directory to be monitored to the inotify instance to monitor the target file; and / or, creating an inotify instance and adding the directory to be monitored to the inotify instance to monitor the target files in the directory.

[0070] Determining whether a specified event has occurred to the target file can include: monitoring the specified event to determine whether the specified event has occurred to the target file.

[0071] Specifically, monitoring a specified event may include: the kernel monitors whether a specified event occurs on a target file or directory; when the specified event occurs on the target file, the event information of the occurred specified event is placed in 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 i not i fy instance)".

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

[0073] The following further describes optional ways to monitor the target file and the specified event:

[0074] Specifically, the monitoring of the target file and the specified event can be implemented through the i not i fy mechanism. The database process can create an i not ify instance by calling relevant system interfaces (such as the i not i fy_i n it() system interface) and obtain a file descriptor for communication with the kernel. The database can call relevant system interfaces (such as the i noti fy_add_watch() system interface) to add a monitor to the i not i fy instance, and 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, a certain or certain files under the specified directory can be specified as the target file.

[0075] The database can specify the event type to be monitored (i.e., the specified event, such as events like file creation, deletion, modification, etc.) to monitor the specified event. Once the monitor is added successfully, the kernel starts to monitor the specified event on the corresponding file or directory (i.e., the monitor), that is, determines 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 on 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. What the specific state is can be set according to needs. For example, the specific state can be a lost state or a state to be recovered. For example, if the target file is deleted or moved (which belongs to the specified event), it can be determined that the target file is in a specific state. Correspondingly, if it is found that the target file is in a specific state when the target file is checked or detected, it can be recognized that the target file has been deleted or moved.

[0077] S103: If a specified event occurs to the target file, perform a data recovery operation. Wherein, performing 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 copying.

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

[0079] Among them, the data recovery operation may be automatically performed after it is determined that a specified event has occurred to the target file, or may be performed after it is determined that a specified event has occurred to the target file and a preset condition is triggered.

[0080] Among them, the following method may be used to determine whether the preset condition is triggered:

[0081] When an operation involving the target file needs to be performed, the target file needs to be accessed, which triggers the monitoring and inspection of the target file, that is, the target file needs to be inspected. Among them, the operation involving the target file may include a DML (Data Manipulation Language) operation involving the target file (that is, the DML statement involves the target file) or flushing the dirty pages of the target file (the flushing here may be periodic automatic flushing). In addition, one of the inspection methods for the target file may be to view the status of the target file. Specifically, the status of the target file may be viewed through the i not i fy mechanism, and it is identified 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 specific state, a preset prompt message is displayed; according to the operation information of the preset prompt message, it is determined whether the preset condition is triggered. For example, the preset prompt message may be to prompt the user that the file (i.e., the target file) is detected to be lost or moved, and whether to recover the file. If the user confirms or selects to recover (i.e., the operation information of the preset prompt message), the preset condition is triggered. Of course, the preset prompt message 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 may be as Figure 3As shown in the figure, it includes: creating an i not i fy instance, adding files or directories to be monitored, and having the kernel monitor specified events. When a specified event occurs to 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 pages of the target file, the target file needs to be accessed, so the target file is checked. Since the target file has been deleted or moved (i.e., a specified event has occurred), the target file cannot be accessed, thus determining that the target file is in a specific state and displaying a preset prompt message to prompt the user that a file loss or movement has been detected.

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

[0085] In the first embodiment, 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 copy.

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

[0087] In the first embodiment, during the process of performing a data recovery operation, a new file can be created under the path of the target file, and the target file can continue to be accessed through the already opened file descriptor, and the content of the target file can be read again and written into the new file, that is, copied into the new file.

[0088] In the first embodiment, a recovered file can be obtained based on the new file after the content copy. Obtaining a recovered file based on the new file after the content copy may include the content described in Case 1 or Case 2 below:

[0089] Case 1: Using the new file after the content copy is completed as the recovered file, that is, the recovered target file.

[0090] In Case 2, after the content copy is completed, the dirty pages of the target file in memory (i.e., the dirty pages belonging to the target file) are flushed back to the new file to obtain the restored 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 memory are flushed back to the new file, so that the pages in the new file corresponding to the dirty pages are updated with the dirty pages. The new file after the dirty pages are flushed can be used as the restored file, that is, the restored target file.

[0091] In the first embodiment, before performing the data recovery operation, the database state can be modified so that the database does not provide services externally (i.e., external clients cannot connect to the database); and / or, after performing the data recovery operation, the database can provide services externally normally (i.e., if the database state was modified before, the database state can be restored to the state before the modification); and / or, before performing 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 specific state. Among them, the modified state of the target file can be set as needed. For example, the state where a specified event has not occurred for the target file 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 data recovery operation, and thus avoid the above preset prompt message from appearing again.

[0092] An example of the overall process in the file recovery stage can be as Figure 4 shown, including: the file recovery starts, modifying the database state and the target file state. Performing the data recovery operation, copying the content and flushing the dirty pages. Obtaining the restored file and restoring the database state.

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

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

[0095] Among them, the CRC (Cyclic Redundancy Check) verification method can be adopted. For any page, the verification operation for this page includes: performing an exclusive OR operation on this page to obtain a verification code; comparing the obtained verification code with the verification code of the first 8 bytes of this page to determine whether the verification of this page is successful.

[0096] The database pages are in units of 8k. Before writing the page content of the file to the disk, a verification code is calculated by performing an exclusive OR operation on the content of the page, and the verification code is saved in the first 8 bytes of the page, and then written to the disk together with the page content.

[0097] In the first embodiment, for any page of the restored file, perform an exclusive OR operation on the content of the page to obtain a checksum (hereinafter referred to as "checksum A"). Also, read the checksum of the first 8 bytes of the page (hereinafter referred to as "checksum B"). Compare checksum A and checksum B to determine whether the check of the page is successful. Specifically, if checksum A and checksum B are the same, the page check is successful; if checksum A and checksum B are different, the page check fails.

[0098] In the first embodiment, if the check of a page is unsuccessful, the corresponding processing operation can be determined according to the page with the unsuccessful check. Specifically, according to the aforementioned situation one and situation two, the pages of the restored file can have two sources. One is the page obtained after being read from the target file and written into the new file, and the other is the page obtained after being read from the target file, written into the new file, and then having its dirty page flushed back. If the page with the unsuccessful check is from the former source, it indicates that the content of the page may have been tampered with or an error occurred during data storage (there may be other reasons, which are not limited in the first embodiment), so corresponding processing operations can be performed or the user can be prompted to perform corresponding processing operations, such as anti-tampering operations. If the page with the unsuccessful check is from the latter source, it indicates that an error may have occurred during the process of flushing the dirty page or an error occurred during data storage (there may be other reasons, which are not limited in the first embodiment), then corresponding processing operations can be performed or the user can be prompted to perform corresponding processing operations, such as the operation of flushing the dirty page again. Of course, according to the page with the unsuccessful check, the corresponding processing operation can be various. For example, the processing operation can also prompt the user to turn off the file monitoring parameter and then perform a logical backup recovery manually. The specific processing operation corresponding to the page with the unsuccessful check can be set as needed.

[0099] In addition, after the data recovery operation is completed, all pages of the restored file can be checked, regardless of whether there has been a page with an unsuccessful check. Or, during the data recovery operation, as long as a page has been written or flushed in the new file, the above-mentioned check operation can be performed on the page that has been written or flushed in the new file first. If the check of any page is unsuccessful, the data recovery operation can be stopped. No matter which method is used, the corresponding processing operation can be determined according to the page with the unsuccessful check.

[0100] An example of the overall process in the file check stage can be as Figure 5 shown, including: after the check starts, traverse the file (i.e., traverse each page of the restored file), calculate checksum A and read checksum B for each page, and compare checksum A and checksum B to determine whether the check is successful.

[0101] In the first embodiment, information corresponding to the data recovery operation can be recorded in a log (such as a database log) for viewing. The information corresponding to the data recovery operation includes, but is not limited to, the information of the target file to be recovered. The first embodiment places no restrictions on the content of the information.

[0102] The target file described in the first embodiment can be various database files, such as one or more of data files, redo log files, and control files, or other files. The first embodiment places no restrictions.

[0103] The first embodiment can achieve the following beneficial effects:

[0104] In the case where a specified event occurs in the database target file (the occurrence of a specified event generally means that the target file appears abnormal, such as being lost or moved), data can be read and written from the file system by holding the opened file descriptor, including reading all the content of the target file and writing it into a new file, so as to perform effective and complete file recovery, effectively reduce the time consumed for database data recovery, and maximize the recovery of lost data, improving the efficiency and effect of database data recovery. It can be seen that the first embodiment provides a powerful and reliable fault tolerance mechanism for the database system, enabling it to still perform effective and efficient data recovery in the face of abnormal situations such as file loss, effectively maintaining the availability of the service and the consistency of the data, reducing the operation risk of the database, and improving the stability and integrity of the database.

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

[0106] Since the new file is created in the same path as the target file, it ensures that the path and the directory of the recovered target file remain unchanged, without affecting its normal use, further improving the efficiency and effect of data recovery.

[0107] During the process of performing the data recovery operation, not only can all the content of the target file be read and written into a new file, but also the dirty pages of the target file in the memory can be flushed back to the new file, ensuring that the data in the new file is consistent with the data in the dirty pages. Thus, on the one hand, it ensures that the dirty pages involving the target file in the memory are promptly written to the disk, and on the other hand, it ensures that the data of the recovered file is the latest data, further improving the data accuracy of the recovered file and the effect of data recovery.

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

[0109] The first embodiment realizes the monitoring of the target file and the specified event. Once the specified event occurs to the target file, an alarm is given in time, and the transaction submission can be prohibited; or, once the specified event occurs to the target file, the database status 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 inotify mechanism can be used, which is an efficient file system monitoring mechanism that allows applications to monitor changes to files or directories on the file system in real time. Through the inotify mechanism, the database can timely detect the specified events performed by external processes on the target file, such as deletion or movement operations, thereby improving the monitoring efficiency of the target file and the specified event.

[0110] As Figure 6 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, configured to monitor the target file and determine whether the specified event occurs to the target file;

[0112] A recovery module 204, configured to perform a data recovery operation if the specified event occurs to the target file;

[0113] Among them, performing the data recovery operation includes:

[0114] Create a new file under the path of the target file, read the content of the target file through the file descriptor corresponding to the target file, and copy the read content of the target file to the new file, and obtain the restored file based on the new file after the content copy.

[0115] Optionally, obtaining the restored file based on the new file after the content copy includes:

[0116] Taking the new file after the content copy is completed as the restored file.

[0117] Optionally, obtaining the restored file based on the new file after the content copy includes:

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

[0119] Optionally, monitoring the target file includes:

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

[0121] And / or,

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

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

[0124] Monitor the specified event to determine whether the specified event occurs in the target file.

[0125] Optionally, monitoring the specified event includes:

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

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

[0128] Optionally, monitoring the specified event further includes:

[0129] Poll and read the file descriptor corresponding to the target file to determine whether the specified event occurs in the target file.

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

[0131] Optionally, the monitoring module 202 is further configured to:

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

[0133] When an operation involving the target file needs to be executed, check the target file;

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

[0135] According to the operation information of the preset prompt message, determine whether to trigger the preset condition.

[0136] Optionally, the operations related to the target file include:

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

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

[0139] and / or,

[0140] After performing the data recovery operation, enable the database to provide services externally.

[0141] Optionally, the recovery module 204 is further configured to: after obtaining the recovered file, perform a check on each page of the recovered file;

[0142] If the check of a page fails, determine the corresponding processing operation according to the page for which the check fails.

[0143] Optionally, the recovery module 204 is further configured to: after obtaining the recovered file, perform a check on each page of the recovered file;

[0144] Wherein, for any page, the operation of checking the page includes: performing an exclusive OR 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.

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

[0146] Embodiment 2 can achieve the same beneficial effects as Embodiment 1.

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

[0148] The above is only for the embodiments of the present application and is not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for database data recovery, characterized in that, The method includes: Monitoring a target file to determine whether a specified event has occurred to the target file; If the specified event has occurred to the target file, performing a data recovery operation; Wherein, performing 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; After obtaining the recovered file, the method further includes: Verifying each page of the recovered file; Wherein, for any page, performing a verification operation on the page includes: performing an exclusive OR 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; specifically including: When file recovery starts, modifying the database state and the target file state, performing a data recovery operation, obtaining a recovered file, and restoring the database state; After obtaining the recovered file, verifying each page of the recovered file. If all pages are verified successfully, it indicates that the data recovery is successful; if there is a page that is not verified successfully, corresponding processing operations are determined according to the page that is not verified successfully; Wherein, in the CRC cyclic redundancy check verification method, for any page, performing a verification operation on the page includes: performing an exclusive OR 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; The database pages are in units of 8k; before writing the page content of the file to the disk, a verification code is calculated by performing an exclusive OR operation on the content of the page, and the verification code is saved in the first 8 bytes of the page, and then written to the disk together with the page content; If there is a page that is not verified successfully, corresponding processing operations are determined according to the page that is not verified successfully. The pages of the recovered file can have two sources. One is the page obtained after reading from the target file and writing it into the new file, and the other is the page obtained after reading from the target file and writing it into the new file and then having the dirty page flushed back. If the page that is not verified successfully is the former source, it indicates that the page content may have been tampered with or an error occurred during data storage, and corresponding processing operations are performed or the user is prompted to perform corresponding processing operations; if the page that is not verified successfully is the latter source, it indicates that an error may have occurred during the process of flushing the dirty page or an error occurred during data storage, and corresponding processing operations are performed or the user is prompted to perform corresponding processing operations, flushing the dirty page again, or prompting the user to close the file monitoring parameter and perform a logical backup recovery manually.

2. The method according to claim 1, characterized in that Obtaining a recovered file based on the new file after the content is copied includes: Taking the new file after the content is copied as the recovered file.

3. The method according to claim 1, wherein Obtaining a recovered file based on the new file after the content is copied includes: After the content copy is completed, flushing the dirty pages of the target file in the memory to the new file to obtain a recovered file.

4. The method according to claim 1, characterized in that, Monitoring the target file includes: Create an inotify instance, add the target file to be monitored to the inotify instance to monitor the target file; and / or, Create an inotify instance, 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 the specified event occurs for the target file includes: Monitoring for the specified event to determine whether the specified event occurs for the target file.

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

7. The method according to claim 6, wherein Monitoring for the specified event further includes: Poll and read the file descriptor corresponding to the target file to determine whether the specified event occurs for the target file.

8. The method according to claim 1, wherein The data recovery operation is executed after a preset condition is triggered.

9. The method according to claim 8, wherein, The method further includes: If the specified event occurs for the target file, determine that the target file is in a specific state; When an operation involving the target file needs to be executed, check the target file; If the target file is in a specific state, display a preset prompt message; Determine whether to trigger the preset condition according to the operation information of the preset prompt message.

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

11. The method according to claim 1, wherein Before executing the data recovery operation, the method further includes: Modify the database state so that the database does not provide services externally; and / or, Modify the state of the target file to the state where the specified event has not occurred; and / or, After executing the data recovery operation, the method further includes: Make the database provide services externally.

12. The method according to claim 1, characterized in that, The method further includes: Record the information corresponding to the data recovery operation in the log.

Images