Data fault recovery method and related device

Abstract

The present disclosure provides a data fault recovery method, comprising: obtaining a backup log of a high-availability database (HA DB) cluster; obtaining a state log of the HA DB cluster; merging the backup log of the HA DB cluster and the state log of the HA DB cluster to generate a historical data backup log of the HA DB cluster; locating an optimal recovery point based on the historical data backup log of the HA DB cluster, wherein the optimal recovery point corresponds to a time point and an HA DB; and performing data fault recovery in the HA DB cluster based on the optimal recovery point. The present disclosure also provides a data fault recovery apparatus, an electronic device, a storage medium, and a program product.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a data fault recovery method and related equipment. Background Technology

[0002] Currently, enterprises typically use Recovery-Time Objective (RTO) to define their acceptable downtime. RTO measures the time required for a service to recover from a failure state to an operational state, representing the total downtime from the occurrence of a service failure to its recovery. For example, a 5-minute RTO means that a business application may be unavailable for 5 minutes. Therefore, reducing or eliminating the RTO of a service has become a goal for most enterprises. Summary of the Invention

[0003] In view of this, embodiments of the present disclosure provide a data fault recovery method. The method includes: acquiring backup logs of an HADB cluster; acquiring status logs of the HADB cluster; merging the backup logs and status logs of the HADB cluster to generate historical data backup logs of the HADB cluster; locating the optimal recovery point based on the historical data backup logs of the HADB cluster; wherein the optimal recovery point corresponds to a point in time and an HADB; and performing data fault recovery in the HADB cluster based on the optimal recovery point.

[0004] In the embodiments of this disclosure, the above-mentioned acquisition of backup logs of each HA DB in the HA DB cluster includes: acquiring backup logs of each HA DB from the backup system corresponding to each HA DB in the HA DB cluster; generating backup logs of the HA DB cluster based on the backup logs of each HA DB; and determining the target time range corresponding to the backup logs of the HA DB cluster.

[0005] In the embodiments of this disclosure, obtaining the status log of the HA DB cluster includes: updating the status log record table of each HA DB based on the received status change notifications of each HA DB; and extracting records within the target time range from the status log record table of each HA DB as the status log of the HA DB cluster.

[0006] In the embodiments of this disclosure, the backup logs of each HA DB include continuous historical data backup records; the step of locating the best recovery point based on the historical data backup logs of the HA DB cluster includes: setting the initial values ​​of the incremental time range and the search time parameter PIT, setting the recovery point parameter to a null value, and then performing the following steps;

[0007] A. In response to determining that the incremental time range is less than a preset time threshold, execute step X; 6040; In response to determining that the incremental time range is greater than or equal to the preset time threshold, execute step B;

[0008] B. Identify the HA DB that is in an active state at the time point corresponding to the PIT, and take it as the target HA DB;

[0009] C. Instruct the backup system associated with the target HA DB to export the historical data backed up at the time point corresponding to the PIT as PIT data to the test database;

[0010] D. Prompt the user to check the PIT data in the test database, and receive the user's check results for the PIT data;

[0011] E. In response to determining, based on the verification result, that the PIT data is historical data that has not been destroyed, execute step F; in response to determining, based on the verification result, that the PIT data is historical data that has been destroyed, execute step G;

[0012] F. Update the incremental time range, the recovery point parameter, and the PIT according to the preset first method, and then return to step A;

[0013] G. In response to determining that the recovery point parameter is not null, execute step H; in response to determining that the recovery point parameter is null, execute step I;

[0014] H. Update the incremental time range and the PIT according to the pre-set second method, and then return to step A;

[0015] I. Update the incremental time range and the PIT according to the pre-set third method, and then return to step A; and

[0016] X. Determine the optimal recovery point based on the recovery point parameters.

[0017] In embodiments of this disclosure, setting the initial value of the incremental time range and PIT includes: determining the initial value of the incremental time range based on the user's selection or a preset default value; and using the difference between the current time point and the incremental time range as the initial value of PIT.

[0018] In embodiments of this disclosure, updating the incremental time range, the recovery point parameter, and the PIT according to a pre-set first method includes: updating the recovery point parameter to: the PIT and the HA DB in an active state at the time point corresponding to the PIT; updating the incremental time range to half of the incremental time range before the update; and updating the PIT to the sum of the PIT before the update and the incremental time range after the update.

[0019] In embodiments of this disclosure, updating the incremental time range and the PIT according to a pre-set second method includes: updating the incremental time range to half of the incremental time range before the update; and updating the PIT to the difference between the PIT before the update and the incremental time range after the update.

[0020] In embodiments of this disclosure, updating the incremental time range and the PIT according to a pre-set third method includes: updating the incremental time range to the difference between the PIT and the incremental time range in response to determining that the difference between the PIT and the incremental time range is less than the earliest time point in the historical data backup log; or, keeping the incremental time range unchanged in response to determining that the difference between the PIT and the incremental time range is greater than or equal to the earliest time point in the historical data backup log; and updating the PIT to the difference between the PIT before the update and the incremental time range after the update.

[0021] In the embodiments of this disclosure, the above-mentioned determination of the optimal recovery point based on the recovery point parameters includes: in response to determining that the recovery point parameters are not empty, taking the PIT included in the recovery point parameters as the time point corresponding to the optimal recovery point; and taking the HA DB included in the recovery point parameters as the HA DB corresponding to the optimal recovery point; and in response to determining that the recovery point parameters are empty, no optimal recovery point was found, and ending the data fault recovery method.

[0022] In the embodiments of this disclosure, the backup logs of each HA DB include recovery point logs; the step of locating the best recovery point based on the historical data backup logs of the HA DB cluster includes: setting the initial value of the search start time point parameter to the current time point, and setting the initial value of the candidate recovery point parameter to empty;

[0023] a. Starting from the time point corresponding to the search start time point parameter, traverse backward in time in the recovery point log to determine the next candidate recovery point that is closest to the search start time point, and update the candidate recovery point parameter and / or search start point parameter based on the determined candidate recovery point.

[0024] b. Instruct the backup system to export the data related to the candidate recovery points as PIT data to the test database;

[0025] c. Prompt the user to check the PIT data in the test database, and receive the user's check result for the PIT data;

[0026] d. In response to determining, based on the verification result, that the PIT data is historical data that has not been corrupted, execute step x; in response to determining, based on the verification result, that the PIT data is historical data that has been corrupted, execute step a; and

[0027] x. Determine the optimal recovery point based on the recovery point parameters.

[0028] In embodiments of this disclosure, the process of determining the next candidate recovery point closest to the search start time point by traversing the recovery point log chronologically from the time point corresponding to the search start time point parameter includes: determining a target time point in the recovery point log that is closest to the search start time point and contains a recovery point; determining the number of recovery points at the target time point that were not selected as candidate recovery points; in response to determining that there is only one recovery point that was not selected as a candidate recovery point, selecting that recovery point as the candidate recovery point; in response to determining that there are multiple recovery points that were not selected as candidate recovery points, selecting one recovery point as the candidate recovery point; and updating the search start time point and the time point corresponding to the candidate recovery point parameter based on the time point corresponding to the recovery point, and updating the HA DB corresponding to the candidate recovery point parameter based on the HA DB corresponding to the recovery point.

[0029] In embodiments of this disclosure, selecting a recovery point as a candidate recovery point includes: in response to determining that the plurality of recovery points not selected as candidate recovery points include a recovery point corresponding to an HA DB in an active state, selecting the recovery point corresponding to the HA DB in an active state as the candidate recovery point; or, in response to determining that the plurality of recovery points not selected as candidate recovery points do not include a recovery point corresponding to an HA DB in an active state, selecting any recovery point corresponding to an HA DB from among them as the candidate recovery point.

[0030] In embodiments of this disclosure, determining the optimal recovery point based on the recovery point parameters includes: in response to determining that the candidate recovery point parameters are not empty, using the timestamp included in the candidate recovery point parameters as the time point corresponding to the optimal recovery point; and using the HA DB included in the recovery point parameters as the HA DB corresponding to the optimal recovery point; or, in response to determining that the recovery point parameters are empty, no optimal recovery point is found, and the data fault recovery method is terminated.

[0031] In embodiments of this disclosure, the above-mentioned data fault recovery based on the optimal recovery point in the HA DB cluster includes: extracting historical data backed up by the HA DB at the time point based on the time point corresponding to the optimal recovery point and the HA DB instructing the backup system; and copying the extracted historical data to each HADB in the HADB cluster.

[0032] Based on the above-described data fault recovery method, embodiments of this disclosure also disclose a data fault recovery apparatus, comprising:

[0033] HADB Backup Monitor is used to obtain backup logs of the HADB cluster.

[0034] The HADB status monitor is used to acquire the status logs of the HADB cluster; and

[0035] The HA data recovery module is used to merge the backup logs of each HA DB and the status log of the HA DB cluster to generate historical data backup logs of the HA DB cluster; locate the optimal recovery point based on the historical data backup logs of the HA DB cluster; wherein the optimal recovery point corresponds to a point in time and an HA DB; and perform data fault recovery in the HA DB cluster based on the optimal recovery point.

[0036] Furthermore, embodiments of this disclosure also provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described data fault recovery method.

[0037] Embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the above-described data fault recovery method.

[0038] Embodiments of this disclosure also provide a computer program product, including computer program instructions that, when executed on a computer, cause the computer to perform the aforementioned data fault recovery method.

[0039] It can be seen that the data failure recovery method and related equipment provided by the embodiments of this disclosure can enable application developers or database administrators (DBAs) to quickly locate the best recovery point when a data failure occurs, and complete the data failure recovery of the HADB cluster based on the best recovery point with the lowest possible recovery point target and recovery time target. Attached Figure Description

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

[0041] Figure 1 An example of deploying a high-availability database (HA DB) in two data centers, as described in embodiments of this disclosure, is shown.

[0042] Figure 2 An example of the status and synchronization process of the HA DB cluster described in this disclosure is shown.

[0043] Figure 3 An example of implementing data failure recovery in an HA DB cluster as described in embodiments of this disclosure is shown.

[0044] Figure 4A An example of the HA DB status monitor 3100 described in this disclosure is shown.

[0045] Figure 4B This document illustrates the specific process by which the HADB status monitor 3100 generates the status log 4010 of the HADB cluster, as described in an embodiment of this disclosure.

[0046] Figure 4C This illustration shows the specific processing procedure of the HA DB status monitor 3100 when the HA data recovery module 3300 queries the status log of the HA DB cluster, as described in an embodiment of this disclosure.

[0047] Figure 5A An example of the HADB backup monitor 3200 described in this disclosure is shown.

[0048] Figure 5B The specific process of the HADB backup monitor 3200 querying backup log 5010 as described in this embodiment of the disclosure is shown.

[0049] Figure 6 This document illustrates the specific process by which the HA data recovery module 3300, as described in some embodiments of this disclosure, recovers HA DB data faults based on continuous historical data backup records.

[0050] Figure 7 This illustrates an exemplary search process by which the HA data recovery module 3300 described in this disclosure locates the optimal recovery point in a continuous historical data backup record.

[0051] Figure 8The following describes the specific process of the HA data recovery module 3300 recovering HA DB data according to other embodiments of this disclosure. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0053] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0054] As mentioned earlier, reducing or eliminating the Real-Time Objective (RTO) of business operations has become a goal for most enterprises. Currently, due to the high-availability database (HADB) cluster configuration allowing for rapid failover of IT services, an increasing number of enterprises are using HADB clusters to deploy their mission-critical databases (DBs), file servers, and data object servers, etc., to reduce business RTO. Deploying HADB clusters is crucial for enterprises with critical applications, where data services can failover without causing downtime. Specifically, data service failover can reduce or eliminate downtime caused by system equipment failures, thereby achieving RTO targets. Data service failover can also cover scenarios requiring system maintenance such as software upgrades. Therefore, deploying HADB clusters in data centers allows businesses to minimize downtime caused by unpredictable major disasters. In applications, the aforementioned HADB clusters typically consist of active-active or active-passive data service nodes (i.e., HADBs). The active-passive data service nodes can also be referred to as active-standby data service nodes.

[0055] To further reduce or eliminate the RTO of their operations, some enterprises establish two or more data centers and deploy HA DBs in a geographically distributed manner within these data centers. Furthermore, within these two or more data centers, one active data service node and two or more backup / passive data service nodes can be deployed.

[0056] It should be noted that, although the embodiments of this disclosure only refer to the technical term "data service" for illustrative purposes, the embodiments of this disclosure are intended to cover all data services, such as file system services, data object services, and any other type of data service.

[0057] Furthermore, in the embodiments of this disclosure, the aforementioned data services are typically executed on a server, which may be a virtual machine, a virtual device, or a physical server, and this disclosure does not limit this. In the embodiments of this disclosure, the term "node" or "data service node" can be used to describe a virtual server or physical server on which data services are executed, and therefore may also be referred to as a data server or database server. The DB or DB server mentioned in the embodiments of this disclosure refers to a server on which data services are executed. The HA DB mentioned in the embodiments of this disclosure typically refers to a high-availability database server.

[0058] Figure 1 An example of deploying HA DB in two data centers as described in embodiments of this disclosure is shown.

[0059] exist Figure 1 The example shown depicts four HA DBs: DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140. These four HA DBs are deployed in two data centers: Data Center-1 1010 and Data Center-2 1020. Data Centers 1010 and 1020 are connected via a Wide Area Network (WAN) 1030. DB-a 1110 and DB-b 1120 are connected via their local intranets 1012. DB-c 1130 and DB-d 1140 are connected via their local intranets 1022. DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140 are interconnected and can communicate with WAN 1030 via their intranets 1012 and 1022.

[0060] It should be noted that networking is a specialized field and can be quite complex; the purpose of this disclosure is not to provide a detailed description of networking. In other words, the aforementioned WAN 1030 and the aforementioned local intranets 1012 and 1022 can all be implemented based on existing WAN and local intranet standards and implementation methods, which will not be elaborated upon here.

[0061] exist Figure 1 In the example shown, each data center has two HA DBs deployed. Of the four HA DBs mentioned above, one is active (i.e., in an active state), and the other three are standby / passive (in a standby / passive state). Specifically, in the example above, DB-a 1110 is labeled as the active HA DB, while DB-b 1120, DB-c 1130, and DB-d 1140 are all labeled as standby HA DBs.

[0062] also, Figure 1 Data storage devices 1111, 1112, 1131, and 1141, deployed in each HA DB, are also shown. These data storage devices are used to store data for their respective HA DBs.

[0063] exist Figure 1 Based on the two data centers shown, Figure 2 The status and data synchronization process of each HA DB (e.g., DB-a1110, DB-b1120, DB-c1130, and DB-d1140) are further illustrated. It should be noted that the aforementioned HA DBs communicate via intranets 1012 and 1022 and WAN 1030. Figure 2 (Not shown in the image).

[0064] exist Figure 2 In the example shown, DB-a 1110 is in an active state and read / write functionality is enabled. In this example, application 2010 can read data from data storage 1111 via DB-a 1110 and write the read data to DB-a 1110 2012. DB-b 1120 is in a fully hot-standby state, and application 2020 is in read-only mode 2022. DB-c 1130 and DB-c 1140 are in a warm-standby state, meaning that access to the data storage is not allowed. The fully hot-standby DB-b 1120 and the hot-standby DB-c 1130 and DB-d 1140 are all ready to take over the active role in the cluster in the event of a failure of DB-a 1110 in the active state, or when the IT administrator decides to shut down DB-a 1110 for maintenance purposes, i.e., switch from standby to active state. In an HA DB cluster, the process of transitioning from a standby state to an active state is called failover or switching. Typically, this failover or switching can be achieved through failover control.

[0065] like Figure 2As shown, DB-a 1110, in an active state, can copy all its data modifications (2110, 2120, 2130) to DB-b 1120, DB-c 1130, and DB-d 1140. These copy operations (2110, 2120, 2130) can be performed synchronously or asynchronously. When performing synchronous copy operations (2110, 2120, 2130), when application 2010 issues a data update request to DB-a 1110, changes need to be committed at each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) to successfully complete the data update request. When performing asynchronous copy operations (2110, 2120, 2130), when application 2010 issues a data update request to DB-a 1110, changes only need to be committed at DB-a 1110 to successfully complete the data update request. For asynchronous replication, data modifications made at DB-a 1110 in an active state (DBs 2110, 2120, and 2130) can be periodically replicated, either in streams or in batches, to other HA DBs in a standby state (e.g., DB-b 1120, DB-c 1130, and DB-d 1140) after the completion of a configured transaction.

[0066] from Figure 1 and Figure 2 It can be seen that although deploying an HA DB cluster can effectively reduce RTO, it also brings financial and operational costs, as well as the risk of difficulty in recovering corrupted data.

[0067] Understandably, regarding funding and operating costs, implementing an HA DB cluster requires purchasing and managing two or more HA DB hosts and software, rather than just a single HA DB host. Furthermore, the operational complexity increases significantly when an HA DB cluster is deployed across two or more data centers. Administrators must configure, manage, and monitor the data replication process, and implement failover control as needed. When configuring automatic failover, administrators may need to periodically and manually check the HA DB status to monitor which HA DBs are in an active state.

[0068] On the other hand, while having an HA DB cluster can prevent downtime caused by system-related failures, it cannot prevent application errors or malware from corrupting data. When data corruption occurs, the corrupted data is replicated from the active HA DB to all standby HA DBs. In some cases, this can lead to instantaneous failure of business applications. In other cases, the corrupted data may not be detected for a period of time. Currently, the daunting task of finding a point in time for data failure recovery and restoring all HA DBs to a correct data state is often handled manually by application developers and DBAs. Restoring the HA DB cluster to a state with minimal data loss, i.e., achieving a lower Recovery-Point-Objective (RPO), is also in the interest of application developers or DBAs. It's important to note that RPO measures the duration of the data loss process. For example, if RPO = 1 hour, it means that data loss occurred for one hour. This means that if we manually search for the point in time before the data failure occurred where the least data was lost (which can generally be understood as the point in time when the data was not damaged and is closest to the current time), that is, to find the best time to perform data failure recovery in order to achieve the best RPO, the RTO may take several hours or even days.

[0069] For ease of description, in the embodiments of this disclosure, the time point from which data failure recovery can be performed can be identified by a recovery point. Furthermore, since multiple HA DBs exist in the HA DB cluster in these embodiments, in addition to determining the time point for data failure recovery, it is also necessary to identify from which HA DB the data was backed up at that time point for data failure recovery. Therefore, in these embodiments, each recovery point will point to a time point and an HA DB. Based on the determined recovery point, undamaged data can be obtained, thereby enabling data failure recovery of the HA DB cluster. It is understood that multiple recovery points may be found during the data failure recovery process. Different recovery points may correspond to different time points or different HA DBs. To improve the efficiency of data failure recovery, finding the time point with the least data loss before the data failure occurred (the time point closest to the current moment) and the corresponding HA DB from among the multiple recovery points becomes the target of data failure recovery. In the embodiments of this disclosure, the process of finding the time point with the least data loss before the data failure occurred and the corresponding HA DB can be simply referred to as the process of searching for or locating the optimal recovery point.

[0070] It can be seen that even with an HA DB cluster, the issues of Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for mission-critical applications cannot be completely resolved. Therefore, embodiments of this disclosure propose solutions to address these problems.

[0071] Figure 3 This illustration shows an example of implementing data fault recovery in an HA DB cluster, as provided in an embodiment of this disclosure. Figure 3 As shown, to address the RPO and RTO issues of mission-critical applications, an HA Data Recovery Assistant (HA DR Assistant) 3010 will be further deployed in the aforementioned HA DB cluster. In addition, a backup system (Backup System-1 3204 and Backup System-2 3208) and test DBs (Test-DB1 3222 and Test-DB2 3224) for data testing in each data center will also be deployed. Each test DB will include a test data store (Test-store-1 3226 and Test-store-2 3228).

[0072] Based on the above Figure 2 The HA DB deployment shown in this disclosure provides a data failure recovery method applied to the HA DR Assistant 3010 to support application developers or DBAs in quickly locating the optimal recovery point when a data failure occurs, and completing the data failure recovery of the HA DB cluster with the lowest possible RPO and RTO based on the optimal recovery point.

[0073] In embodiments of this disclosure, the HADR Assistant 3010 described above can work in conjunction with the backup system described above. Since services employing HA DB clusters cannot tolerate prolonged application downtime or excessive data loss, the backup system used should have the capability for frequent or continuous data backup. Therefore, in embodiments of this disclosure, backup systems of the Continuous Data Protection (CDP) or Near Continuous Data Protection (nCDP) type are preferred for Backup System-1 3204 and Backup System-2 3208.

[0074] like Figure 3As shown in the example, in data center-1 1010, data from DB-a 1110 and DB-b 1120 will be backed up to backup system-1 3204 (3212, 3214). In data center-2 1020, data from DB-c 1130 and DB-d 1140 will be backed up to backup system-2 3208 (3216, 3218). Because each HA DB is backed up independently, their backup schedules may not be coordinated. Therefore, the historical backup data captured in backup system-1 3204 and backup system-2 3208 associated with each HA DB may also be different.

[0075] In locating the optimal recovery point, the HADR Assistant 3010 of this disclosure first needs to find one or more candidate recovery points, and then submit the data of the HA DB corresponding to each candidate recovery point to the application developer or DBA for inspection and confirmation, thereby confirming whether these candidate recovery points are the true recovery points. This is the purpose of deploying test DBs (e.g., Test-DB1 3222 and Test-DB-2 3224). In embodiments of this disclosure, the test DB is used to store data extracted based on candidate recovery points. In this way, application developers or DBAs can confirm whether a candidate recovery point is a true recovery point simply by checking and confirming whether the data in the test DB is corrupted, without having to check the data of the entire HADB cluster backup. Therefore, the time required for data inspection is greatly reduced, thus achieving the lowest possible RPO and RTO targets.

[0076] Specifically, in Figure 3 In the example shown, in data center-1 1010, backup system-1 3204 can export data 3221 from the HA DB corresponding to the candidate recovery point to Test-DB1 3222 for review by application developers or DBAs. In data center-2 1020, backup system-2 3208 can export data 3223 from the HA DB corresponding to the candidate recovery point to Test-DB2 3224 for review by application developers or DBAs.

[0077] It is worth mentioning that the embodiments of this disclosure deploy two backup systems and two test databases. However, in practical applications, it is not necessary to deploy exactly two backup systems and test databases; deploying one or more such backup systems and test databases can achieve the same purpose.

[0078] like Figure 3As shown, in order to achieve data fault recovery, according to the functional division, the above-mentioned HA DR Assistant 3010 may include: HA DB status monitor 3100, HA DB backup monitor 3200, and HA data recovery module 3300.

[0079] As part of the data failure recovery process, the aforementioned HA data recovery module 3300 can request the HA DB cluster status log 3302 from the HA DB status monitor 3100. Figure 4A (4010 in the above). The status log of the aforementioned HA DB cluster consists of the status of each HA DB at multiple points in time. The HA DB status monitor 3100 can receive status information from each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140) at points 3102, 3104, 3106, and 3108 respectively through querying and notification, thereby generating the status log of the aforementioned HA DB cluster. In other embodiments, the HA DB status monitor 3100 can also receive HA DB status information from other system monitoring software without directly communicating with the HA DBs. The specific process by which the HA DB status monitor 3100 collects status information from each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 140) can be described as follows: Figure 4B As shown, we will skip that for now.

[0080] As part of the data failure recovery process, the aforementioned HA data recovery module 3300 can also request the HA DB cluster backup logs from the HA DB backup monitor 3200. Figure 5A (5010 in the original text). Then, the HADB backup monitor 3200 can request backup records of each HADB (3202, 3206) from backup systems 3204 and 3208, and return the generated HADB backup records to the HADB backup monitor 3200, whereby the HA data recovery module 3300 generates the HADB cluster backup log. The process of the HADB backup monitor 3200 collecting each HADB backup record can be described as follows: Figure 5B As shown, we will skip that for now.

[0081] Furthermore, during data failure recovery, the HA data recovery module 3300 combines the status logs and backup logs of the HA DB cluster to search for the point in time before the data failure occurred where data loss was minimal, i.e., the optimal recovery point. Typically, since there may be multiple recovery points, the HA data recovery module 3300 cannot pinpoint the optimal recovery point in one go. It usually first identifies a candidate recovery point, confirms its validity, and then further searches for the optimal recovery point based on the confirmed one. This is usually a cyclical search process.

[0082] Furthermore, as mentioned earlier, since the current HADB cluster contains multiple HADBs, and each HADB stores its own data, in the embodiments of this disclosure, the aforementioned recovery point not only identifies a point in time but also a specific HADB, that is, it indicates the source of the backup data. Thus, during data failure recovery, the HA data recovery module 3300 will export the data backups at the corresponding time points 3221 and 3223 to Test-DB1 3222 or Test-DB2 3224 based on the time points indicated by the determined candidate recovery points and the corresponding backup systems 3204 and 3208 of the HADB commands 3306 and 3308, so that application developers or DBAs can inspect the data.

[0083] The following will use Figures 3 to 8 The illustrated embodiment demonstrates a data fault recovery method applied to an HA DB cluster.

[0084] Figure 3 The block diagram of HA DR Assistant 3010 is shown, and an exemplary data failure recovery method in a current HA DB cluster is illustrated. Figure 3 As shown, the HA DR Assistant 3010 has three main modules: HA DB Status Monitor 3100, HA DB Backup Monitor 3200, and HA Data Recovery Module 3300.

[0085] In the above embodiments, the HADB status monitor 3100 can interact with each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) 3102, 3104, 3106, 3108 respectively to periodically check the status of each HA DB and obtain its status information. When their status changes, it can also receive corresponding notifications through registration. In alternative embodiments, the HADB status monitor 3100 can receive the status information of each HA DB from other software solutions (e.g., system monitoring software).

[0086] Figure 4A An example of the HA DB status monitor 3100 described in this disclosure is shown. In the current embodiment, as Figure 4A As shown, when the HADB status monitor 3100 receives status change notifications from 3102, 3104, 3106, and 3108 to a certain HA DB (e.g., DB-a1110, DB-b1120, DB-c1130, or DB-d1140), or when the HADB status monitor 3100 periodically queries 3102, 3104, 3106, and 3108 and obtains the status of each HA DB, the HADB status monitor 3100 saves the obtained HA DB status information to the HADB cluster status log (HADB-State-Log) 4010. Table 1 below shows an example of the HADB cluster status information recorded in the HADB cluster status log 4010.

[0087] It should be noted that, in the embodiments of this disclosure, the status information of the HA DB can include UP-ACTIVE, UP-STANDBY, or DOWN. Both fully hot standby and hot standby states are recorded as UP-STANDBY. In different embodiments, different backup modes can be recorded as different states. UP-ACTIVE indicates that the HA DB is UP (available) and in an active state, usable for reading and writing. UP-STANDBY indicates that the HA DB is UP (available), but in a fully hot standby (read-only) or hot standby (neither read nor write). DOWN indicates that the HA DB is unavailable and the system is shut down.

[0088] Table 1: Example of HA DB cluster status log:

[0089] 1 20240118:05:10:39 DOWN UP-ACTIVE UP-STANDBY UP-STANDBY 2 20240115:21:05:35 UP-ACTIVE UP-STANDBY UP-STANDBY UP-STANDBY 3 20240113:23:40:13 UP-STANDBY UP-ACTIVE UP-STANDBY UP-STANDBY 4 20240112:02:13:45 UP-STANDBY UP-STANDBY UP-STANDBY UP-ACTIVE 5 20240108:19:03:17 UP-ACTIVE UP-STANDBY UP-STANDBY UP-STANDBY 6 20240105:12:28:05 UP-STANDBY DOWN UP-ACTIVE UP-STANDBY 7 20240101:05:03:39 UP-STANDBY UP-ACTIVE UP-STANDBY UP-STANDBY 8 20240101:00:00:00 UP-ACTIVE UP-STANDBY UP-STANDBY UP-STANDBY

[0090] It should be noted that Table 1 above is an example of a HA DB cluster status log 4010, which can be accessed by the HA DB status monitor 3100. Figure 4B The specific process shown is generated.

[0091] In Table 1, each row of data consists of a timestamp representing a point in time and the status information of all HA DBs at that timestamp. For this HA DB cluster, at any given time, only one HA DB can be in the UP-ACTIVE state. The other HA DBs are either in the UP-STANDBY state, ready to take over the active role (failover) of the UP-ACTIVE HA DB if it fails, or they may be in the DOWN state. For example, at the time point corresponding to the timestamp "20240115:21:05:35" (row 2), the status information of DB-a 1110 is "UP-ACTIVE", while the status information of DB-b1120, DB-c 1130, and DB-d 1140 is "UP-STANDBY". At the time point corresponding to the timestamp "20240118:05:10:39" (row 1), DB-a 1110 fails, and its status information changes to "DOWN". At this point, DB-b 1120 takes over the active role of DB-a1110, and therefore its status information will change to "UP-ACTIVE".

[0092] Figure 4B This document illustrates the specific process by which the HA DB status monitor 3100, as described in some embodiments of this disclosure, generates the status log 4010 of the HA DB cluster.

[0093] In step 4100, the HA DB status monitor 3100 begins to capture HA DB status information.

[0094] In step 4102, each HA DB is configured to provide an HA DB status change notification to the HA DB status monitor 3100 when its status changes.

[0095] In the embodiments of this disclosure, the HADB state change notification will include: a timestamp corresponding to the time point when the state change occurred and the state information of the HADB after the state change.

[0096] Alternatively, in step 4102 above, external HA DB monitoring software can be configured to provide HA DB status change notifications to HA DB status monitor 3100 when the HA DB status changes.

[0097] In step 4120, the HA DB status monitor 3100 creates a listener to wait for notifications of HA DB status changes.

[0098] When the state of any HA DB changes, the listener can receive the corresponding HA DB state change notification in step 4120.

[0099] Meanwhile, in steps 4104 and 4106, based on a specific pre-configured time interval, the HA DB status monitor 3100 can periodically and proactively check the status of all HA DBs to obtain the status information of each HA DB.

[0100] In step 4108, once the HA DB status information is received, an HA DB status record is generated based on the received status information, and the HA DB status record is written into the status log 4010 of the HA DB cluster.

[0101] In some embodiments, the records in the status log 4010 of the HADB cluster described above are the same as those in the example in Table 1. Each row in Table 1 represents one record. As shown in Table 1, each record in the status log of the HADB cluster is used to record the status information of each HADB node in the HADB cluster at a certain point in time.

[0102] In step 4110, if the HADB status monitor 3100 has not terminated, return to step 4104 above and continue periodically querying the HADB status. Otherwise, proceed to step 4140.

[0103] In step 4140, the HADB status monitor 3100 terminates its processing.

[0104] Since all the aforementioned HADB and / or external HADB status monitoring software are configured to send HADB status change notifications to the HADB status monitor 3100 when the status of any HADB changes (see step 4120 above), the aforementioned periodic HADB status query process (from step 4104 to step 4110) is actually a redundant process. However, through this redundancy, the timeliness and accuracy of the HADB status log can be guaranteed.

[0105] In step 4122, when the HA DB status monitor 3100 receives a status change notification from the HA DB, step 4124 will be executed.

[0106] In step 4124, the HA DB status monitor 3100 checks the status of all HA DBs and generates a record based on the acquired status information, which is then entered into the HA DB cluster status log 4010. Then, it returns to step 4120 to continue listening for notifications.

[0107] In some embodiments, the records entered into the status log 4010 of the HA DB cluster are the same as those in the example in Table 1.

[0108] In step 4132, the operation of the HA DB status monitor 3100 is terminated by providing a termination command.

[0109] In step 4134, when the termination command arrives, the HA DB status monitor 3100 can end the notification configuration from all HADB or external HADB monitoring software and terminate the HA DB status monitor 3100 from continuing to listen for status change notifications.

[0110] In step 4136, the HA DB status monitor 3100 switches to the end state, which will cause the periodic HA DB status query process (from steps 4110 to 4140) to end.

[0111] Figure 4C This shows the specific processing procedure of HADB Status Monitor 3100 when HA Data Recovery Module 3300 queries the status log of HADB cluster.

[0112] When the HA data recovery module 3300 sends a request 3302 to the HADB status monitor 3100 to obtain the HADB cluster status log, the HADB status monitor 3100 will perform the following steps:

[0113] In step 4202, the HA DB status monitor 3100 receives a request from the HA data recovery module 3300 to obtain the HA DB cluster status log.

[0114] In the embodiments of this disclosure, the above-mentioned request to obtain HA DB cluster status logs will be used to instruct the query of HA DB cluster status log records within a certain period of time (from a start time to an end time). That is, the above-mentioned request to obtain HA DB cluster status logs typically includes a start time and an end time.

[0115] In step 4204, the HADB status monitor 3100 queries the status log of the HADB cluster and extracts the status log of the HADB cluster that belongs to the above time range.

[0116] In step 4206, the HA DB status monitor 3100 returns the extracted status logs of the HA DB cluster within the aforementioned time range to the HA data recovery module 3300.

[0117] In the embodiments of this disclosure, after receiving a request from the HA data recovery module 3300 to obtain the HA DB cluster status log, the HA DB backup monitor 3200 can interact with the backup systems 3204, 3208 3202, 3206 to query the backup logs of all HADBs (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140).

[0118] Figure 5AAn example of the HADB backup monitor 3200 described in this disclosure is shown. For example... Figure 5A As shown, after the HADB backup monitor 3200 collects backup records from backup systems 3204 and 3208 for each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140), it generates the HA DB cluster backup log 5010. It should be noted that although... Figure 5A Two backup systems are shown, but the methods described in this disclosure can be applied to scenarios in which one or more backup systems are deployed in one or more data centers.

[0119] like Figure 3 As shown, during normal business operations, the data of each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) will be continuously backed up to backup systems 3212, 3214, 3216, and 3118 to backup systems 3204 and 3208. In other words, backup systems 3204 and 3208 can obtain the historical backup data and backup time points of each HA DB.

[0120] In embodiments of this disclosure, the backup system can back up historical data of the HA DB in one of two different ways: continuous historical data backup or recovery point backup. Some Continuous Data Protection (CDP) backup systems can store protected historical data continuously. Based on this stored historical data, the HA DB data can be restored to any past point in time. However, it is understood that storing continuous historical data is very resource-intensive. Most CDP backup systems or near-continuous data protection (nCDP) systems periodically save historical data, and for descriptive convenience, the HA DB of each backup and its corresponding time point are referred to together as a recovery point. This backup method is also known as recovery point-based backup. Under recovery point-based backup, the HA DB data can be restored to the time point corresponding to any past recovery point.

[0121] In embodiments of this disclosure, if the historical data backed up by the backup system is continuous, the backup log 5010 of the HA DB cluster may look like the example shown in Table 2A. If the historical data backed up by the backup system is discrete, the backup log 5010 of the HA DB cluster may look like the example shown in Table 2B.

[0122] To illustrate this with the data in Table 1, the example data in Table 2A is aligned with the HA DB status timeline in Table 1. That is, in this example, historical data backup begins at the time point corresponding to the timestamp "20240101:00:00:00". As shown in Table 2A, in the "DB-a 1110" column, historical data for DB-a 1110 can be continuously retrieved from "20240101:00:00:00" to "20240118:05:10:39". However, historical data for DB-a 1110 will no longer be available after this point because DB-a 1111 failed and is now down (DOWN) starting at "20240118:00 05:10:39". In Table 2A, "^" represents historical data with backups, while "X" represents historical data without backups. In the "DB-b1120" column, historical data for DB-b 1120 can be continuously retrieved from "20240101:00:00:00" to "20240105:12:28:05", and then from "20240108:19:03:17" to "NOW" (i.e., now). However, from "20240105:12:28:05" to "20240108:19:03:17", historical data for DB-b 1120 cannot be retrieved because DB-b 1120 has failed and is now down. Since DB-c 1130 and DB-d 1140 are not experiencing any failures, historical data for these two HADBs can be continuously retrieved from "20240101:00:00:00" to "NOW".

[0123] Table 2A: HADB Cluster Backup Log 5010 – Continuous Historical Data Backup Records

[0124]

[0125] It should be noted that in Table 2A above and in the subsequent examples, NOW represents the timestamp corresponding to the current time.

[0126] Similarly, to illustrate this with the data in Table 1, the example data in Table 2B is aligned with the HA DB status timeline in Table 1. In the example in Table 2B, the backup records for historical data also begin at "20240101:00:00:00". Unlike Table 2A, the historical data in Table 2B is only available at each point in time when the backup occurred.

[0127] In fact, each of DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140 can have its own backup schedule, resulting in different recovery points for each HA DB. However, for the sake of simplicity, the example in Table 2B assumes that all HA DBs in the HA DB cluster (e.g., DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140) use the same backup schedule. Assume that in the example in Table 2B, the backup schedule is set to run every 6 hours, specifically at 00:00:00, 06:00:00, 12:00:00, and 18:00:00 daily.

[0128] Based on the above assumptions about the data backup schedule, as shown in Table 1, DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140 all operated normally between "20240101:00:00:00" and "20240105:12:00:00". Therefore, in time period 1 (20240105:12:0:00-220240101:00:00:00), DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140 each have 19 recovery points, including: {20240105:12:00:20240105:06:00:00, ..., 20240101:06:00:0020240101:00:00}.

[0129] Consistent with Table 1, DB-b1120 experienced a failure during the period from "20240105:18:00:00" to "20240108:18:00:00 (time period 2)" (its status was DOWN starting from 20240105:12:28:05 in Table 1). Therefore, DB-b1120 has no recovery points. The other DB-a1110, DB-c1130, and DB-d1140 still each have 13 recovery points. Although Table 2B does not show all recovery points, these should include: {20240108:18:00:00, 20240108:12:00:00, ..., 20240106:00:00:00, 20240105:18:00:00}.

[0130] Assuming the current time NOW is 20240118:18:00:00, similarly to Table 1, DB-a 1110 started failing (DOWN) at 20240118:05:10:39. Therefore, from "20240118:06:00:00" to "20240118:18:00:00 (NOW)" (i.e., time period 4), DB-a 1110 will have no recovery points. DB-b 1120, DB-c 1130, and DB-d 1140 will each have three recovery points. Although Table 2B does not show all recovery points, these should include: {20240118:06:00:002020118:12:0:002020118:18:00:00}.

[0131] Table 2B: HA DB Cluster Backup Log 5010 - Recovery Point

[0132]

[0133] As can be seen from the above examples, in the embodiments of this disclosure, the recovery point not only indicates the time when the data backup occurred, but also indicates the HA DB that performed the data backup. That is, in the embodiments of this disclosure, each recovery point corresponds to a point in time (the time when the data backup occurred, which can be identified using a timestamp) and an HA DB (the HA DB that performed the data backup).

[0134] Figure 5B The specific process of querying backup logs using the HA DB Backup Monitor 3200 as described in this embodiment of the disclosure is shown.

[0135] In an embodiment of this disclosure, the HA data recovery module 3300 sends a request 3304 to the HA DB backup monitor 3200 to obtain the HA DB cluster backup logs 5010.

[0136] In step 5100, the HA DB backup monitor 3200 receives a request from the HA data recovery module 3300 to obtain the HA DB cluster backup logs.

[0137] In step 5102, the HA DB backup monitor 3200 obtains the HA DB list and creates a new HA DB cluster backup log.

[0138] In steps 5104 and 5106, the HA DB backup monitor 3200 traverses the HADBs in the HADB list until all HADBs have been queried.

[0139] In step 5106, for each HADB, the HADB backup monitor 3200 connects to the backup system corresponding to the HADB to query the backup records of the HADB and adds the backup records of each HADB to the backup log of the HADB cluster.

[0140] In step 5110, after all HADB backup records have been queried and added to the HADB cluster backup log, the HADB backup monitor 3200 provides the HADB cluster backup log to the HA data recovery module 3300.

[0141] Figure 6 This illustration shows the specific process by which the HA data recovery module 3300 described in this embodiment recovers HADB data faults from continuous historical data.

[0142] Figure 6 This demonstrates a concrete process that allows application developers or DBAs to perform data failure recovery on an HADB cluster based on backed-up, continuous historical data. In other words, Figure 6 The process shown is applicable to backup systems that can capture and store continuous historical data of HADB.

[0143] The above data fault recovery process begins at step 6000.

[0144] In step 6002, the HA data recovery module 3300 sends a request 3304 to the HADB backup monitor 3200 to obtain the HADB cluster backup logs 5100 and the target time range corresponding to the HADB cluster backup logs.

[0145] As mentioned above Figure 5B As shown, based on the request to obtain HADB cluster backup logs from the HA data recovery module 3300, the HA DB backup monitor 3200 can return a backup log 5010 of the HA DB cluster to the HA data recovery module 3300. Since the HA DB cluster backup log 5010 in this embodiment contains backup records of continuous historical data, the HA DB cluster backup log 5010 received by the HA data recovery module 3300 looks like the example in Table 2A.

[0146] Thus, in step 6002, after obtaining the HADB cluster backup log 5010, the HA data recovery module 3300 will further determine the target time range corresponding to the HADB cluster backup log from the HADB cluster backup log 5010. The aforementioned target time range refers to the period from the current time to the earliest time of the backup record within it. This earliest time is referred to as LastPIT in this disclosure. LastPIT corresponds to the time point at which the earliest historical data was backed up in the backup system; no old data existed before this time point.

[0147] In step 6004, the HA data recovery module 3300 sends a request 3302 to the HA DB status monitor 3100 to obtain the HA DB cluster status log 4010.

[0148] Specifically, in step 6004 above, the request to obtain the HA DB cluster status log will include the target time range (e.g., from NOW to LastPIT) to obtain the status log 4010 of the HA DB cluster within the target time range.

[0149] In the embodiments of this disclosure, the status log 4010 of the HA DB cluster contains the historical status of each HADB in the HA DB cluster (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) at multiple points in the past.

[0150] As mentioned above Figure 4C As shown in the specific process, in step 4202, the HA DB status monitor 3100 receives the aforementioned request to obtain the HA DB cluster status logs. In step 4204, the HA DB status monitor 3100 extracts the status logs of the HA DB cluster that fall within the aforementioned target time range. It should be noted that, simultaneously, the HA DB cluster status log recording process 4010 (from steps 4100 to 4140) is also underway. In step 4206, the HA DB status monitor 3100 returns the extracted HA DB cluster status logs to the HA data recovery module 3300.

[0151] In step 6006, the HA data recovery module 3300 merges the backup logs and status logs of the HA DB cluster to generate HA continuous historical data backup logs.

[0152] In embodiments of this disclosure, the aforementioned HA continuous historical data log can also be simply referred to as the historical data backup log of the HA DB cluster. An example of the aforementioned HA continuous historical data log is shown in Table 3A below. The aforementioned HA continuous historical data log contains a combination of the historical state of the HA DB and its continuous historical data backup records. The example in Table 3A is the result of combining Table 1 and Table 2A above. Table 3A contains the historical state of each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) and its continuous historical data backup records (recorded in the "CH" column under each HA DB in Table 3A).

[0153] Table 3A: HA Continuous Historical Data Backup Log

[0154]

[0155]

[0156] As can be seen from the embodiments of this disclosure, a new row (row 0) is added to Table 3A with a timestamp of "NOW", representing the present. Row 1 in Table 3A has the same timestamp as row 1 in Table 1; row 2 in Table 3A has the same timestamp as row 2 in Table 1; and so on.

[0157] In Table 3A, the data in the status column for each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) comes from Table 1; while the data in its "CH" column comes from Table 2A.

[0158] Specifically, the "CH" column under DB-a 1110 represents the continuous historical data backup records of DB-a 1110. As shown in Table 2A, the failure of DB-a 1110 began at the time point corresponding to the timestamp "20240118:05:10:39" (row 1). Therefore, the "CH" column in rows 0 and 1 of the data corresponding to DB-a 1110 is "X", meaning that there are no historical data backup records (i.e., no data backup was performed at the time point corresponding to this timestamp). Before the time point corresponding to the timestamp "20240118:05:10:39" (row 1), DB-a 1110 did not fail. Therefore, the "CH" column in rows 2 to 8 of the data corresponding to DB-a 1110 is "^", indicating that its continuous historical data backup records exist (i.e., a data backup was performed at the time point corresponding to this timestamp). Furthermore, as shown in Table 1, DB-a 1110 is in an UP-ACTIVE state during three different time periods starting from the timestamps 20240101:00:00:00, 20240108:19:03:17, and 20240115:21:05:35, meaning its role is that of an active HA DB in the HA DB cluster.

[0159] The columns DB-b 1120, DB-c 1130, and DB-d 1140 in Table 3A are also data from Tables 1 and 2A merged in the same way as DB-a 1110. This will not be repeated here.

[0160] Back Figure 6 The flowchart is as follows. After merging the backup logs of the HA DB cluster (as shown in Table 2A) and the status logs of the HA DB cluster (as shown in Table 1) to generate the HA continuous historical data backup logs (as shown in Table 3A), the HA data recovery module 3300 can feed back the above-mentioned HA continuous historical data backup logs to the user (application developer or DBA), and continue to search the above-mentioned HA continuous historical data backup logs according to the methods shown in steps 6008 to 6044 to locate the time point in the backed-up historical data where the data loss was minimal before the data failure occurred, that is, the best recovery point.

[0161] This demonstrates that the HA data recovery module 3300 can efficiently traverse the timeline to locate the closest undamaged data, helping users quickly find the recovery point with minimal data loss, thereby achieving the optimal Recovery Point Objective (RPO). In the worst-case scenario, the data may have been corrupted for a long time before being discovered, and the entire backup history data is corrupted, with no recoverable data available in any backup system (as shown in step 6042).

[0162] To better illustrate Figure 6The process of locating the optimal recovery point shown in steps 6008 to 6044 provides... Figure 7 . Figure 7 This is an example of the search process by which the HA data recovery module 3300 described in this disclosure locates the best recovery point in continuous historical data.

[0163] exist Figure 7 In this example, the sample recovery points shown in box 7100 differ in style from those in Table 3A, but contain similar information, including the historical status of each HA DB and its historical data backup records. Each sub-box 7111-7147 within box 7100 corresponds to a time slot and an HA DB, respectively. For example, in the time slot corresponding to box 7111, DB-a 1110 is in a "DOWN" state, and no historical data backup records are available in its backup system (no arrow). The solid arrows in boxes 7112, 7116, 7117, 7124, 7131, 7135, and 7143 indicate that their associated HA DBs are in an active state in the time slots corresponding to these boxes and have historical data backup records. Dashed arrows indicate that the associated HA DBs are in a standby state in the time slots corresponding to these boxes, but these HA DBs have historical data backup records in their backup system.

[0164] In step 6008, the HA data recovery module 3300 prompts the user (application developer or DBA) to select the incremental time range D to search for data in the HA continuous historical data log.

[0165] Alternatively, as an alternative to step 6008 above, the HA data recovery module 3300 can use the default D as the incremental time range, such as 1 hour.

[0166] That is, in step 6008 above, the HA data recovery module 3300 will determine an incremental time range D to indicate the time range of a data search.

[0167] In step 6010, initial values ​​for several search parameters are set before the search begins. These search parameters include:

[0168] LastGood – This parameter corresponds to the recovery point indicating that it can be used for data fault recovery, and can also be referred to as the recovery point parameter. In an embodiment of the present disclosure, when a recovery point has been determined, the above-mentioned LastGood parameter may include the HA DB corresponding to the recovery point and a time point (which can be represented by a timestamp). When no recovery point has been found yet, the above-mentioned LastGood parameter may be NIL (representing null). It can be understood that if the LastGood parameter is not empty, the HA DB and time point recorded in the LastGood parameter can be recorded, the backup historical data can be located from the corresponding backup system, and the data fault recovery of the HA DB cluster can be completed accordingly. <"0000449">In an embodiment of the present disclosure, the initial value of LastGood can be set to NIL.

[0170] PIT - Represents the currently searched time point, usually represented by a timestamp.

[0171] In an embodiment of the present disclosure, the initial search can start from PIT = NOW - D. For example, if D is 1 hour and the current time is 10 am, the start time of the search should be 9 am. In a specific example, using Figure 7 in scenario 1 7200, the position pointed to by arrow 7202 represents PIT (NOW - D), and the search will start from the position pointed to by arrow 7202. Figure 7 Scenarios 27300 and scenario 3 7400 in

[0172] also show similar scenarios, where the positions pointed to by arrows 7302 and 7402 also represent PIT, which is also NOW - D.

[0173] Steps 6012 to 6020 form a loop to search for the best recovery point in the historical data by continuously navigating forward and backward in time.

[0174] In step 6012, if the HA data recovery module 3300 finds that D is less than or equal to a preset time threshold, such as 1 second, it means that the incremental time range D is too small to find the optimal recovery point. The search loop ends and the process jumps to 6040.

[0175] It should be noted that, although Figure 6 The time threshold shown is 1 second, but this is not a hard limit of this disclosure. In fact, the minimum D can be set empirically, for example, at the sub-second level.

[0176] In step 6014, the HA data recovery module 3300 identifies the HA DB that is in an active state in the above PIT as the target HA DB.

[0177] Taking scenario 1 7200 as an example, in Figure 7 In this context, based on the determined PIT, the HA DB in the active state of the aforementioned PIT is DB-b 1120. Therefore, the selected historical data should be located at 7124.

[0178] In step 6016, the HA data recovery module 3300 instructs the backup system associated with the target HA DB to export the historical data corresponding to the PIT as PIT data to the test DB for user inspection.

[0179] by Figure 7 For example, at the time point corresponding to the PIT, the HA DB in an active state is DB-b 1120, and its associated backup system should be backup system 3204, while the test DB is Test-DB-1 3222. Therefore, in the above steps, the HA data recovery module 3300 will instruct the backup system 3204 associated with DB-b 1120 to export the historical data backed up at the time point corresponding to the PIT as PIT data to Test-DB-1 3222. Furthermore, the HA data recovery module 3300 will also instruct the user (application developer or DBA) to check the PIT data in Test-DB-1 3222.

[0180] In step 6018, the HA data recovery module 3300 receives feedback from the user regarding the PIT data. If the PIT data is undamaged historical data, proceed to step 6020; otherwise, proceed to step 6022.

[0181] If the process jumps to step 6020, it means that undamaged historical data has been located, and this historical data can be used for data failure recovery. However, this historical data may not be the historical data with the least data loss, that is, it may not be the data corresponding to the optimal recovery point. In other words, there may be other undamaged historical data between PIT and NOW, and because their corresponding timestamps are closer to NOW, their data loss is less. In order to further search for the optimal recovery point, a further search can be performed between the current PIT and NOW to find the time point when the data was not damaged, thereby achieving data failure recovery with minimal loss. Therefore, in step 6020, the following operation will be performed.

[0182] In step 6020, the HA data recovery module 3300 updates the search parameters according to the preset first method, and then returns to step 6012.

[0183] In the embodiments of this disclosure, updating the search parameters according to a pre-set first method may specifically include the following aspects:

[0184] 1) Update the LastGood parameter to the current PIT and the HA DB that is in an active state in that PIT.

[0185] use Figure 7 Using scenario 1 7200 as an example, arrow 7202 points to the location where an undisturbed historical data record is found. In this case, the timestamp in the LastGood parameter can be set to the current PIT, i.e., the time slot corresponding to box 7124. Furthermore, the LastGood parameter will also include the identifier of the HA DB in the aforementioned PIT active state, i.e., the identifier of DB-b 1120.

[0186] 2) Update the incremental time range D to half of the previous D value, i.e., let D = D / 2, so that data search can be performed within a narrower incremental time range.

[0187] 3) Update PIT to the sum of the original PIT and the incremental time range D after the update, i.e., let PIT = PIT + D. The goal is to find the most recent point in time where the data has not been corrupted.

[0188] After updating the search parameters according to the first method described above, the search process will return to step 6012.

[0189] Still using Figure 7Taking scenario 1 (7200) as an example, if the previously found undisturbed PIT historical data is located at 7202, then the LastGood parameters can be updated to include: PIT = 7124 and DB - b1120. Further, dividing D by half yields the updated incremental time range of 0.5d, where d represents the initial value of the incremental time range D. Then, updating PIT = PIT + 0.5d, the updated PIT will be located at the position indicated by arrow 7204. Assuming 0.5d is still greater than 1 second, continue using... Figure 7 Using scenario 17200 as an example, in step 6014, the updated PIT is the location indicated by arrow 7204. The HA DB in active state in this time slot is DB-a 1110, and the historical data corresponding to the PIT is located in the time slot corresponding to box 7112. Thus, in step 6016, the historical data of the time slot corresponding to box 7112 backed up in the backup system corresponding to DB-a 1110 will be exported as PIT data to Test-DB1 3222, and the user will be prompted to perform a data check.

[0190] Suppose that the PIT data is determined to be corrupted after inspection. As shown in scenario 7206, the HA data recovery module 3300 must rewind time to find the recovery point corresponding to the historical data that was not corrupted before the PIT. Thus, after step 6018, the process jumps to step 6022.

[0191] In step 6022, determine whether the LastGood parameter is equal to NIL. If not, proceed to step 6024; otherwise, proceed to step 6026.

[0192] In step 6024, the HA data recovery module 3300 updates the search parameters according to the preset second method, and then returns to step 6012.

[0193] Since the LastGood parameter has already recorded the PIT and DB in this situation, the HA data recovery module 3300 will further find other recovery points between the current PIT (the position pointed to by arrow 7204) and the PIT recorded by the LastGood parameter.

[0194] In the embodiments of this disclosure, updating the search parameters according to the pre-set second method may include the following aspects:

[0195] 1) Update the incremental time range D to half of the original value of D, i.e., let D = D / 2, so that data search can be performed within a narrower incremental time range.

[0196] exist Figure 7In Scenario 1 of 7200 examples, after two updates, the updated incremental time range D is one-fourth of the original initial incremental time range D, that is, 0.25d, as shown by arrow 7206.

[0197] 2) Update the PIT to the difference between the PIT before update and the updated incremental time range D, that is, let PIT = PIT - D.

[0198] Still use Figure 7 Scenario 1 of 7200 in it as an example. The updated PIT is in the middle of the previous two PITs, that is, at the position pointed to by arrow 7206. At this time, in steps 6012, 6014, and 6016, based on the updated PIT, the selected historical data should be the time slots corresponding to box 7143. And the HA DB in which the above PIT is in the active state is DB - d 1140. Thus, in step 6016, the historical data of the time slots corresponding to box 7143 backed up in the backup system corresponding to DB - d 1140 will be exported to Test - DB2 3224 as PIT data, and the user will be prompted to perform data checking. Assume that in step 6018, it is determined that the current PIT data is an undamaged historical data record, then the process will jump back to step 6020, and the HA data recovery module 3300 will further update the search parameters in the first manner, and then jump to step 6012. The specific parameter update this time can include: setting the timestamp in the LastGood parameter to the time slot corresponding to box 7143; the HA DB in the active state is DB - d1140; D = D / 2; and 3) PIT = PIT + D.

[0199] In Figure 7 In the example of Scenario 1 of 7200, the updated PIT corresponds to the position pointed to by arrow 7208.

[0200] In step 6026, the HA data recovery module 3300 updates the search parameters in a preset third manner, and then returns to 6012.

[0201] In the embodiments of the present disclosure, the above-mentioned update of the search parameters in a preset third manner may include the following aspects:

[0202] 1) If PIT - D < LastPIT, then let D = PIT - LastPIT; otherwise, keep D unchanged.

[0203] 2) Update the PIT to the difference between the PIT before update and the updated incremental time range D, that is, let PIT = PIT - D.

[0204] If the current updated incremental time range D is equal to or less than 1 second (the preset time threshold), the search process will jump from step 6012 to step 6040.

[0205] In step 6040, the optimal recovery point is determined based on the LastGood parameter.

[0206] This means using the timestamp in the LastGood parameter as the time point corresponding to the best recovery point, and using the HA DB identifier in the LastGood parameter as the HA DB corresponding to the best recovery point.

[0207] In step 6044, the HA data recovery module 3300 instructs the backup system to perform data failure recovery from the aforementioned optimal recovery point to each HADB.

[0208] The above data fault recovery process will successfully end in step 6046.

[0209] It should be noted that the data failure recovery of the HA DB cluster mentioned above involves copying the historical data backed up at the determined optimal recovery point in the HA DB cluster to other HA DBs in the cluster, thereby completing the data failure recovery.

[0210] Figure 7 Two other scenarios were also shown: Scenario 2 7300 and Scenario 3 7400.

[0211] In scenario 2 7300, in step 6018, the user reports that PIT data 7124 (the data indicated by arrow 7302) has been corrupted. The process then jumps to step 6022, and the search parameters are updated in step 6024. Since no uncorrupted PIT data has been found yet, LastGood remains equal to NIL. Next, in step 6026, the HA data recovery module 3300 further shifts the PIT by an incremental time range D, resulting in the updated PIT at the position indicated by arrow 7304. Assuming that data inspection determines the new PIT data (data 7117) is not corrupted, the process continues... Figure 6 The method shown updates the LastGood parameter's timestamp to the time slot corresponding to box 7117, obtaining a new D(0.5d), and sets PIT = PIT + 0.5d, i.e., moving forward D to obtain the new PIT (the position pointed to by arrow 7306). In this case, assuming that data inspection determines that the new PIT data (box 7116) is not corrupted, then continue according to... Figure 6The method shown updates the LastGood parameter to the time slot corresponding to box 7116, obtaining a new D (0.25d) and shifting PIT forward by D to obtain a new PIT (the position indicated by arrow 7308). Assuming that data inspection determines the new PIT data (data 7135) is corrupted, the updated D (0.125D) and shifting PIT backward by D to obtain a new PIT (the position indicated by arrow 7310) are then used... This process continues to determine the optimal recovery point.

[0212] exist Figure 7 In scenario 3 7400, assuming the PIT data at the location indicated by arrow 7402 is corrupted, the process jumps to step 6022. Since uncorrupted PIT data is found, i.e., LastGood = NIL, in step 6026, the HA data recovery module 3300 further shifts the PIT backward by an incremental time range D. The new PIT is the location indicated by arrow 7404. If we assume the PIT data at the location indicated by arrow 7404 is also corrupted, the process jumps to step 6022 again. Since uncorrupted PIT data is still found, i.e., LastGood = NIL, in step 6026, the HA data recovery module 3300 further shifts the PIT backward by an incremental time range D. The updated PIT exceeds the LastPIT of the historical data record. Therefore, in step 6026, D needs to be adjusted, and the new PIT is set as the LastPIT, i.e., the location indicated by arrow 7406. After another data check, if the PIT historical data is still corrupted, the processing step moves from 6018 to 6022, and the new D will eventually become less than 1 second. After jumping to step 6040, since the LastGood parameter is still NIL, the above search process will end at step 6042, meaning that no backup historical data was found that can be used to recover from the data failure.

[0213] As can be seen from the above process, Figure 6 This paper demonstrates an algorithm for rapidly traversing continuous historical data in an HA DB (High-Intensity Focused Database), allowing users to quickly identify the time point of the most recent undamaged data, i.e., to locate the optimal recovery point, thereby achieving the best Recovery Point Objective (RPO). Furthermore, this method can also be used to quickly recover from data failures in an HA DB cluster, thus achieving the best Recovery Time Objective (RTO).

[0214] In other embodiments of this disclosure, the backup system periodically captures and backs up historical data of the HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) in a discrete manner. In these embodiments, there will be no continuous historical data backup records. In this case, the data in the HA DB cannot be restored to any past point in time, but only to one of the points in time when the historical data was backed up. Figure 8 The process shown is designed to support the scenario described above. Specifically, Figure 8 This illustrates the specific process of the HA data recovery module 3300 recovering HA DB data as described in some embodiments.

[0215] It should be noted that, depending on how historical data is acquired and backed up, the method of this disclosure embodiment may include two processes.

[0216] and Figure 6 The same purpose Figure 8 It also demonstrates a specific process that allows application developers and DBAs to perform data failure recovery for HA DB clusters.

[0217] The data fault recovery process described in this embodiment begins at step 8000.

[0218] In step 8002, the HA data recovery module 3300 sends a request 3304 to the HA DB backup monitor 3200 to obtain the HA DB cluster backup logs 5010.

[0219] like Figure 5B As shown, upon receiving a request to retrieve the HA DB cluster backup log, the HA DB backup monitor 3200 can correspondingly return a backup log 5010 of the HA DB cluster to the HA data recovery module 3300. In the above embodiment, the backup log 5010 of the HA DB cluster can contain a discrete sequence of recovery points corresponding to each HA DB in the HA DB cluster. As mentioned earlier, each recovery point will correspond to a timestamp (representing the time point of historical data backup) and an HA DB (representing the HA DB that performed the historical data backup). Table 2B shows an example of a backup log 5010 of an HA DB cluster.

[0220] Similarly, in step 8002, the HA data recovery module 3300 further determines the target time range corresponding to the backup log 5010 of the HA DB cluster. This target time range is from the current time to the earliest time when no more historical data backup records exist. In the embodiments of this disclosure, this earliest time is referred to as LastPIT. It can be understood that LastPIT is the time point corresponding to the earliest historical data backup record existing in the backup system. There are no earlier historical data records before this time point.

[0221] In step 8004, the HA data recovery module 3300 sends a request 3302 to the HA DB status monitor 3100 to obtain the HA DB cluster status log 4010.

[0222] It should be noted that, in the embodiments of this disclosure, the above-mentioned acquisition of the HA DB cluster status log 4010 is the HA DB cluster status log 4010 within the above-mentioned target time range (from now to LastPIT).

[0223] As mentioned above, the aforementioned HA DB cluster status log 4010 contains the historical status of each HA DB in the HA DB cluster (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) at multiple points in the past.

[0224] like Figure 4C As shown in the specific process, in step 4202, the HA DB status monitor 3100 receives a request. In step 4204, the HA DB status monitor 3100 extracts the status logs of the HA DB cluster falling within the aforementioned target time range. It should be noted that the HA DB cluster status log 4010 recording process from step 4100 to step 4124 is performed simultaneously. In step 4206, the HA DB status monitor 3100 returns the extracted HA DB cluster status logs falling within the aforementioned target time range to the HA data recovery module 3300.

[0225] In step 8006, the HA data recovery module 3300 merges the backup logs and status logs of the HA DB cluster to generate recovery point logs.

[0226] In the disclosed embodiments, the recovery point logs described above can also be referred to as historical data backup logs of the HA DB cluster. Table 3B shows an example of a recovery point log. The time points corresponding to the recovery points mentioned above are described as timestamps in the example in Table 3B.

[0227] The example in Table 3B is the result of combining Tables 1 and 2B above. The data in Table 3B contains the historical states of each HADB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) and the corresponding time points for their recovery points. For example, rows 16, 15, 13, 11, 9, 7, 5, and 3 in Table 3B come from the status log 4010 of the HADB cluster as shown in Table 1. Rows 16, 14, 12, 10, 8, 6, 4, and 2 in Table 3B contain the time points corresponding to the recovery points in the backup log 5010 of the HADB cluster in Table 2B.

[0228] Table 3B: Recovery Point Log

[0229]

[0230]

[0231] Assume the backup begins at "20240101:00:00:00" (line 16). At this point in time, DB-a 1110 is in an active state, while other HA DBs (e.g., DB-b 1120, DB-c 1130, DB-d 1140) are in a standby state. Furthermore, each HA DB has a corresponding recovery point at this point in time (the recovery point corresponds to the time "20240101:00:00:00", and the corresponding HA DB is the respective HA DB).

[0232] At “20240101:05:03:39” (line 15), DB-b 1120 becomes active, while DB-a1110, DB-c1130, and DB-d 1140 become standby. Since the example in Table 2B shows that backups are performed every 6 hours, there are no corresponding recovery points for any of the HA DBs between the start times of “20240101:00:00:00” (line 16) and “202401010:05:03:39” (line 15) when the status of DB-a 1110 and DB-b 1120 changes.

[0233] From time “20240101:06:00:00” to time “20240105:12:00:00” (row 14), each HA DB in the HA DB cluster underwent 18 backups. Therefore, each HA DB in the HA DB cluster (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) has 18 corresponding recovery points, with the corresponding timestamps listed in the corresponding rows and columns of Table 3B. The generation interval between adjacent recovery points corresponding to the same HA DB is 6 hours. Furthermore, the status of each HA DB in row 14 is the same as in row 15. It should be noted that, similar to Table 2B, the example in Table 3B assumes that all HA DBs are backed up simultaneously for illustrative purposes.

[0234] At "20240105:12:28:05" (line 13), DB-b 1120 failed (DOWN), DB-c 1130 switched to active terminal, and DB-a 1110 and DB-d 1140 switched to standby status. Similarly, since the example in Table 2B shows that backups are performed every 6 hours, there are no recovery points for any of the HA DBs from this time to the last backup time. That is, line 13 of Table 3B only shows the status change.

[0235] From "20240105:18:00:00" to "20240108:18:00:00" (line 12), each HADB in the HA DB cluster underwent 13 backups. Therefore, each HA DB in the HA DB cluster (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) has 13 corresponding recovery points. Unlike line 14, for simplicity, line 12 in Table 3B does not contain a complete list of timestamps corresponding to the 13 recovery points. Furthermore, the status of each HA DB in line 12 is the same as in line 13.

[0236] In line 11, the status of the HA DBs changed. Then, in line 10, each HA DB has 13 corresponding recovery points. In line 9, the status of the HA DBs changed again. Then, in line 8, each HA DB has 6 corresponding recovery points, and so on. In line 3, at "20240118:05:10:39", DB-a 1110 failed (DOWN), DB-b 1120 switched to active status, and DB-c 1130 and DB-d 1140 switched to standby status. Later, in line 2, DB-a 1110 was unavailable for the entire period from "20240118:06:00:00" to "20240118:18:00:00". Therefore, there is no recovery point corresponding to DB-a 1110. The other three HA DBs, namely DB-b 1120, DB-c 1130, and DB-d 1140, each have three corresponding recovery points.

[0237] After merging the HA DB cluster status log 4010 and the HA DB cluster backup log 5010 into the recovery point log as shown in Table 3B, step 8008 will continue.

[0238] In step 8008, the HA data recovery module 3300 sets the initial values ​​for multiple search parameters.

[0239] In embodiments of this disclosure, setting the initial values ​​of the search parameters includes:

[0240] 1) Set the T value, representing the start time of the search, to the current time (NOW);

[0241] 2) Set the RP value, which represents the parameter corresponding to the candidate recovery point, to NULL. The PR value consists of two parts: one representing the time point, which can be represented by PIT (as a timestamp); the other representing the HA DB, for example, the HA DB identifier.

[0242] In step 8010, the HA data recovery module 3300 starts from the value of T mentioned above and iterates backward in time in the recovery point log to determine the next candidate recovery point that is closest to T, and updates the candidate recovery point parameters in the search parameters based on the determined candidate recovery point.

[0243] In the current example, when T = NOW (line 1), the timestamp corresponding to the next candidate recovery point should be "20240118:18:00:00", located in line 2.

[0244] It's important to note that in line 2, DB-b 1120, DB-c 1130, and DB-d 1140 each correspond to three recovery points, with each recovery point spaced 6 hours apart (20240118:06:00:00, 20240118:12:00:00, and 20240118:18:00:00). However, since DB-a 1110 is out of service, it has no corresponding recovery point. Therefore, for the timestamp "20240118:18:00:00", a total of three recovery points can be located. These three recovery points correspond to the same timestamp but to different HA DBs.

[0245] Assuming that multiple recovery points are located in step 8010 above, and one of the recovery points comes from an HA DB in an active state (e.g., DB-b 1120), then in the embodiments of this disclosure, the recovery point corresponding to the HA DB in an active state can be selected as the above-mentioned candidate recovery point.

[0246] After identifying the candidate recovery point, the HA data recovery module 3300 sets the PIT value in the RP value of the above search parameters to "20240118:18:00:00" and sets the HA DB value in the RP value to DB-b 1120 to complete the update of the search parameters.

[0247] Suppose that multiple recovery points are located in step 8010 above, but none of the located recovery points come from the HA DB in an active state, then the HA data recovery module 3300 can select any recovery point corresponding to the standby HA DB as the above candidate recovery point.

[0248] In the embodiments of this disclosure, the reason for selecting the recovery point corresponding to the HA DB in an active state as the candidate recovery point is that the HA DB in an active state usually pushes its transactions to the standby HA DB. Therefore, the HA DB in an active state usually has the latest data, thus ensuring that the amount of data loss is small.

[0249] In step 8012, if the RP value is not NULL, then proceed to step 8014.

[0250] In step 8014, the HA data recovery module 3300 instructs the backup system corresponding to the above-mentioned candidate recovery points to export the data related to the above-mentioned recovery points as PIT data to the relevant test DB.

[0251] As mentioned above, each recovery point corresponds to a time point and an HA DB. In the embodiments of this disclosure, in step 8014 above, the HA data recovery module 3300 will instruct the backup system corresponding to the HA DB of the above candidate recovery point to use the data related to the time point corresponding to the above candidate recovery point as PIT data and export it to the relevant test DB.

[0252] In the aforementioned example, the HA DB identified by the RP value of the candidate recovery point is DB-b 1120, and the time point (i.e., PIT value) identified by the RP value of the candidate recovery point is "20240118:18:00:00". Thus, in the above steps, the HA data recovery module 3300 will instruct the backup system 3204 corresponding to DB-b 1120 to export the historical data backed up at "20240118:18:00:00" as PIT data to the relevant test DB Test-DB1 3222.

[0253] After exporting the PIT data to the test DB, the HA data recovery module 3300 instructs the user (application developer or DBA) to examine the PIT data 3222 from Test-DB1.

[0254] In step 8018, user feedback on PIT data is received.

[0255] If it is determined that the PIT data in the test DB is not corrupted, proceed to step 8044 and end.

[0256] In step 8044, the above candidate recovery points are determined as the optimal recovery points, and data failure recovery of the HA DB cluster is performed based on the determined optimal recovery points.

[0257] As mentioned earlier, the RP value includes a PIT (timestamp) corresponding to a point in time, and an HA DB. In the current example, the RP value includes: PIT = "20240118:18:00:00", HA DB = DB-b 1120. Therefore, the optimal recovery point points to the historical data backed up by DB-b 1120 at the time "20240118:18:00:00". Thus, in step 8044 above, the HA data recovery module 3300 can perform data failure recovery of the HA DB cluster based on the determined optimal recovery point. The specific process can be referred to the aforementioned embodiments, and will not be repeated here.

[0258] If it is determined that the PIT data in the test DB is corrupted, the HA data recovery module 3300 will execute step 8020.

[0259] In step 8020, the HA data recovery module 3300 checks whether there are other HA DBs with recovery points at the same time point as the current candidate recovery point. If so, it continues to step 8022. If not, it continues to step 8024.

[0260] In the current example, the time point corresponding to the current candidate recovery point is "20240118:18:00:00". At this time point, both DB-c 1130 and DB-d 1140 have recovery points. Therefore, the search process will continue to step 8022.

[0261] In step 8022, update the candidate recovery points and the candidate recovery point parameters in the search parameters, and return to step 8014.

[0262] In the example above, in this step, the RP value can be updated to: PIT="20240118:18:00:00", and the HA DB is DB-c 1120. Then, return to step 8014.

[0263] Subsequently, backup system 3208 exports the historical data backed up by DB-c 1130 at "20240118:18:00:00" as PIT data to Test-DB2 3224 and instructs the user to check it. If the PIT data is still corrupted, HA data recovery module 3300 will try the recovery point corresponding to DB-d 1140 in the same PIT. After testing all recovery points at the same PIT for all databases, if no uncorrupted historical data suitable for data failure recovery is found, the search process will jump to step 8024. As mentioned earlier, if uncorrupted historical data suitable for data failure recovery is found, the search process will jump to step 8044.

[0264] In step 8024, the HA data recovery module 3300 updates the search parameters and then returns to step 8010.

[0265] In the above steps, the above-mentioned updated search parameters may include: the HA data recovery module 3300 sets the T value to the time point (PIT) in the current candidate recovery point (RP) parameter, and resets the candidate recovery point parameter RP value to NULL.

[0266] In the example above, after traversing all recovery points corresponding to the HA DB at the time point "20240118:18:00:00" and finding no undamaged data, the HA data recovery module 3300 updates the T value to "20240118:18:00:00" and sets the RP value to NULL. Then, it returns to step 8010. At this point, the HA data recovery module 3300 again starts traversing other recovery points backward in the HA recovery point history log from T ("20240118:18:00:00"). Continuing the current example, the next recovery point corresponds to the time point "20240118:12:00:00" (PIT time point). At this time point, DB-b 1120 is also an active HA DB. Therefore, a new candidate recovery point can be identified, and the RP value is updated to DB-b 1120 and "20240118:12:00:00". This process continues.

[0267] If it is determined that the PIT data corresponding to the candidate recovery point is not corrupted, the best recovery point has been found, the search process jumps to step 8044, and then ends.

[0268] In step 8044, the HA data recovery module 3300 instructs the backup system corresponding to the HA DB indicated by the optimal recovery point to back up the historical data backed up at the time indicated by the optimal recovery point to each HA DB in the HA DB cluster, thereby completing the data failure recovery.

[0269] The search process described above will successfully terminate at step 8046.

[0270] If the HA data recovery module 3300 fails to find any undamaged data after traversing all recovery points in the HA recovery point log in time, the above search process will jump to step 8042 and end.

[0271] As can be seen, the above method can be simply summarized as follows: First, starting from the time point corresponding to the search start time point parameter, the recovery point log is traversed backwards in time to determine the next candidate recovery point closest to the search start time point, and the candidate recovery point parameters and / or search start point parameters are updated based on the determined candidate recovery point. Next, it is further determined whether the candidate recovery point is the optimal recovery point by checking whether the relevant historical data corresponding to the candidate recovery point is undamaged historical data. If it is the optimal recovery point, data fault recovery is performed based on the located optimal recovery point; if it is not the optimal recovery point, the above backward traversal steps are repeated until the optimal recovery point is located.

[0272] The method described in this disclosure enables users to quickly locate the optimal recovery point for HA DB in an HA DB cluster and perform data failure recovery of the HA DB cluster based on the located optimal recovery point. The optimal recovery point represents the backup location of historical data where data loss is minimal and data corruption is minimal.

[0273] Although, the above Figure 6 This explains the data failure recovery process when all HA DBs have continuous historical data, and Figure 8 The data fault recovery process described herein is applied to scenarios with discrete historical data. However, the method described in this embodiment can be applied to scenarios where some HA DBs in a cluster have continuous historical data backup records, while other HA DBs in the cluster have discrete historical data backup records. Specifically, in practical applications, it can be used... Figure 6 The search process within the system searches consecutive historical data backup records to locate the first optimal recovery point, while simultaneously using... Figure 8 The search process searches discrete historical data backup records to locate a second optimal recovery point. Then, the recovery point closest to the current time is selected from the two optimal recovery points as the final optimal recovery point.

[0274] In an alternative embodiment, Figure 6 The search process and Figure 8 The search process can also be merged, and the method for traversing historical data backup records can be determined based on the format of the historical data backup records.

[0275] Although this disclosure focuses on HA DB, the same approach can be applied to any HA data system, such as object storage or file system.

[0276] Although the accompanying drawings of this disclosure illustrate an HA DB cluster with one active node and three standby or downtime (DOWN) nodes, the methods described in this disclosure are not limited to this configuration. The methods described in this disclosure can be applied to clusters with two or more data nodes deployed in one or more data centers.

[0277] While the above example shows two data centers, an HA DB cluster can be deployed in only one data center or in more than two data centers. Therefore, the methods described in this disclosure are applicable to data failure recovery of HA DB clusters deployed in one, two, or more data centers.

[0278] The accompanying drawings corresponding to the embodiments of this disclosure show two data centers and two backup systems, each backup system deployed in one of the data centers. The methods described in the embodiments of this disclosure do not require such a specific configuration. The methods described in the embodiments of this disclosure are applicable to one or more backup systems in one or more data centers. Data in an HA DB cluster can be backed up entirely to a single backup system, or each data node can be backed up to a separate backup system.

[0279] As can be seen from the above examples, the data fault recovery method provided by the embodiments of this disclosure may include: obtaining the backup log of the HA DB cluster; obtaining the status log of the HA DB cluster; merging the backup log of the HA DB cluster and the status log of the HA DB cluster to generate the historical data backup log of the HA DB cluster; locating the optimal recovery point based on the historical data backup log of the HA DB cluster; wherein the optimal recovery point corresponds to a time point and an HADB; and performing data fault recovery in the HADB cluster based on the optimal recovery point.

[0280] In the embodiments of this disclosure, the above-mentioned acquisition of backup logs of each HA DB in the HA DB cluster includes: acquiring backup logs of each HA DB from the backup system corresponding to each HA DB in the HA DB cluster; generating backup logs of the HA DB cluster based on the backup logs of each HA DB; and determining the target time range corresponding to the backup logs of the HA DB cluster.

[0281] In the embodiments of this disclosure, obtaining the status log of the HA DB cluster includes: updating the status log record table of each HA DB based on the received status change notifications of each HA DB; and extracting records within the target time range from the status log record table of each HA DB as the status log of the HA DB cluster.

[0282] In the embodiments of this disclosure, the backup logs of each HA DB include continuous historical data backup records; the step of locating the best recovery point based on the historical data backup logs of the HA DB cluster includes: setting the initial values ​​of the incremental time range and the search time parameter PIT, setting the recovery point parameter to a null value, and then performing the following steps;

[0283] A. In response to determining that the incremental time range is less than a preset time threshold, execute step X; 6040; In response to determining that the incremental time range is greater than or equal to the preset time threshold, execute step B;

[0284] B. Identify the HA DB that is in an active state at the time point corresponding to the PIT, and take it as the target HA DB;

[0285] C. Instruct the backup system associated with the target HA DB to export the historical data backed up at the time point corresponding to the PIT as PIT data to the test database;

[0286] D. Prompt the user to check the PIT data in the test database, and receive the user's check results for the PIT data;

[0287] E. In response to determining, based on the verification result, that the PIT data is historical data that has not been destroyed, execute step F; in response to determining, based on the verification result, that the PIT data is historical data that has been destroyed, execute step G;

[0288] F. Update the incremental time range, the recovery point parameter, and the PIT according to the preset first method, and then return to step A;

[0289] G. In response to determining that the recovery point parameter is not null, execute step H; in response to determining that the recovery point parameter is null, execute step I;

[0290] H. Update the incremental time range and the PIT according to the pre-set second method, and then return to step A;

[0291] I. Update the incremental time range and the PIT according to the pre-set third method, and then return to step A; and

[0292] X. Determine the optimal recovery point based on the recovery point parameters.

[0293] In embodiments of this disclosure, setting the initial value of the incremental time range and PIT includes: determining the initial value of the incremental time range based on the user's selection or a preset default value; and using the difference between the current time point and the incremental time range as the initial value of PIT.

[0294] In embodiments of this disclosure, updating the incremental time range, the recovery point parameter, and the PIT according to a pre-set first method includes: updating the recovery point parameter to: the PIT and the HA DB in an active state at the time point corresponding to the PIT; updating the incremental time range to half of the incremental time range before the update; and updating the PIT to the sum of the PIT before the update and the incremental time range after the update.

[0295] In embodiments of this disclosure, updating the incremental time range and the PIT according to a pre-set second method includes: updating the incremental time range to half of the incremental time range before the update; and updating the PIT to the difference between the PIT before the update and the incremental time range after the update.

[0296] In embodiments of this disclosure, updating the incremental time range and the PIT according to a pre-set third method includes: updating the incremental time range to the difference between the PIT and the incremental time range in response to determining that the difference between the PIT and the incremental time range is less than the earliest time point in the historical data backup log; or, keeping the incremental time range unchanged in response to determining that the difference between the PIT and the incremental time range is greater than or equal to the earliest time point in the historical data backup log; and updating the PIT to the difference between the PIT before the update and the incremental time range after the update.

[0297] In the embodiments of this disclosure, the above-mentioned determination of the optimal recovery point based on the recovery point parameters includes: in response to determining that the recovery point parameters are not empty, taking the PIT included in the recovery point parameters as the time point corresponding to the optimal recovery point; and taking the HA DB included in the recovery point parameters as the HA DB corresponding to the optimal recovery point; and in response to determining that the recovery point parameters are empty, no optimal recovery point was found, and ending the data fault recovery method.

[0298] In the embodiments of this disclosure, the backup logs of each HA DB include recovery point logs; the step of locating the best recovery point based on the historical data backup logs of the HA DB cluster includes: setting the initial value of the search start time point parameter to the current time point, and setting the initial value of the candidate recovery point parameter to empty;

[0299] a. Starting from the time point corresponding to the search start time point parameter, traverse backward in time in the recovery point log to determine the next candidate recovery point that is closest to the search start time point, and update the candidate recovery point parameter and / or search start point parameter based on the determined candidate recovery point.

[0300] b. Instruct the backup system to export the data related to the candidate recovery points as PIT data to the test database;

[0301] c. Prompt the user to check the PIT data in the test database, and receive the user's check result for the PIT data;

[0302] d. In response to determining, based on the verification result, that the PIT data is historical data that has not been corrupted, execute step x; in response to determining, based on the verification result, that the PIT data is historical data that has been corrupted, execute step a; and

[0303] x. Determine the optimal recovery point based on the recovery point parameters.

[0304] In embodiments of this disclosure, the process of determining the next candidate recovery point closest to the search start time point by traversing the recovery point log chronologically from the time point corresponding to the search start time point parameter includes: determining a target time point in the recovery point log that is closest to the search start time point and contains a recovery point; determining the number of recovery points at the target time point that were not selected as candidate recovery points; in response to determining that there is only one recovery point that was not selected as a candidate recovery point, selecting that recovery point as the candidate recovery point; in response to determining that there are multiple recovery points that were not selected as candidate recovery points, selecting one recovery point as the candidate recovery point; and updating the search start time point and the time point corresponding to the candidate recovery point parameter based on the time point corresponding to the recovery point, and updating the HA DB corresponding to the candidate recovery point parameter based on the HA DB corresponding to the recovery point.

[0305] In embodiments of this disclosure, selecting a recovery point as a candidate recovery point includes: in response to determining that the plurality of recovery points not selected as candidate recovery points include a recovery point corresponding to an HA DB in an active state, selecting the recovery point corresponding to the HA DB in an active state as the candidate recovery point; or, in response to determining that the plurality of recovery points not selected as candidate recovery points do not include a recovery point corresponding to an HA DB in an active state, selecting any recovery point corresponding to an HA DB from among them as the candidate recovery point.

[0306] In embodiments of this disclosure, determining the optimal recovery point based on the recovery point parameters includes: in response to determining that the candidate recovery point parameters are not empty, using the timestamp included in the candidate recovery point parameters as the time point corresponding to the optimal recovery point; and using the HA DB included in the recovery point parameters as the HA DB corresponding to the optimal recovery point; or, in response to determining that the recovery point parameters are empty, no optimal recovery point is found, and the data fault recovery method is terminated.

[0307] In embodiments of this disclosure, the above-mentioned data fault recovery based on the optimal recovery point in the HA DB cluster includes: extracting historical data backed up by the HA DB at the time point based on the time point corresponding to the optimal recovery point and the HA DB instructing the backup system; and copying the extracted historical data to each HADB in the HADB cluster.

[0308] Accordingly, embodiments of this disclosure also disclose a data fault recovery apparatus, comprising:

[0309] HADB Backup Monitor is used to obtain backup logs of a high availability database (HADB) cluster.

[0310] The HADB status monitor is used to acquire the status logs of the HADB cluster; and

[0311] The HA data recovery module is used to merge the backup logs and status logs of the HA DB cluster to generate historical data backup logs of the HA DB cluster; locate the optimal recovery point based on the historical data backup logs of the HA DB cluster; wherein the optimal recovery point corresponds to a point in time and an HA DB; and perform data fault recovery in the HA DB cluster based on the optimal recovery point.

[0312] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the data fault recovery method described in any of the above embodiments.

[0313] The aforementioned electronic device may include: a processor, a memory, an input / output interface, a communication interface, and a bus. The processor, memory, input / output interface, and communication interface are interconnected internally via the bus.

[0314] The processor can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0315] The memory can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory and called and executed by the processor.

[0316] Input / output interfaces are used to connect input / output devices to enable information input and output. These devices can be configured as components within the device or externally connected to provide corresponding functions. Input devices may include microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0317] The communication interface is used to connect the communication module to enable communication and interaction between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0318] A bus is a pathway that transmits information between various components of a device, such as processors, memory, input / output interfaces, and communication interfaces.

[0319] It should be noted that although the above-described device only shows the processor, memory, input / output interface, communication interface, and bus, in actual implementation, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0320] The electronic devices described above are used to implement the corresponding data fault recovery methods in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0321] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the data fault recovery method as described in any of the above embodiments.

[0322] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0323] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the task processing method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0324] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0325] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuitry) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure may be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0326] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0327] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A data fault recovery method, comprising: Obtain backup logs for the high availability database (HA) cluster; Obtain the status logs of the HA DB cluster; Merge the backup logs and status logs of the HA DB cluster to generate the historical data backup logs of the HA DB cluster; The optimal recovery point is located based on the historical data backup logs of the HA DB cluster; wherein, the optimal recovery point corresponds to a point in time and an HA DB; the backup logs of each HA DB include continuous historical data backup records; and Data failure recovery is performed in the HA DB cluster based on the aforementioned optimal recovery point; wherein... The process of locating the optimal recovery point based on the historical data backup logs of the HA DB cluster includes: Set the initial values ​​for the incremental time range and the search time parameter PIT, and set the recovery point parameter to an empty value, then perform the following steps; A. In response to determining that the incremental time range is less than a preset time threshold, execute step X; or, in response to determining that the incremental time range is greater than or equal to the preset time threshold, execute step B; B. Identify the HA DB that is in an active state at the time point corresponding to the PIT, and take it as the target HA DB; C. Instruct the backup system associated with the target HA DB to export the historical data backed up at the time point corresponding to the PIT as PIT data to the test database; D. Prompt the user to check the PIT data in the test database, and receive the user's check results for the PIT data; E. In response to determining, based on the verification result, that the PIT data is historical data that has not been destroyed, proceed to step F; or, in response to determining, based on the verification result, that the PIT data is historical data that has been destroyed, proceed to step G; F. Update the incremental time range, the recovery point parameter, and the PIT according to the preset first method, and then return to step A; G. In response to determining that the recovery point parameter is not null, execute step H; or, in response to determining that the recovery point parameter is null, execute step I; H. Update the incremental time range and the PIT according to the pre-set second method, and then return to step A; I. Update the incremental time range and the PIT according to the pre-set third method, and then return to step A; and X. Determine the optimal recovery point based on the recovery point parameters.

2. The method according to claim 1, wherein, The process of obtaining backup logs for the high availability database (HADB) cluster includes: Obtain the backup logs of each HA DB from the backup system corresponding to each HA DB in the HA DB cluster; Backup logs for the HA DB cluster are generated based on the backup logs of each HA DB; and Determine the target time range corresponding to the backup logs of the HA DB cluster.

3. The method according to claim 2, wherein, The process of obtaining the status log of the HA DB cluster includes: Based on the received status change notifications for each HA DB, update the status log records of each HA DB; and Records within the target time range are extracted from the status log records of each HA DB as the status log of the HA DB cluster.

4. The method according to claim 1, wherein, The setting of the incremental time range and the initial value of PIT includes: The initial value of the incremental time range is determined based on the user's selection or a pre-set default value; and The difference between the current time point and the incremental time range is used as the initial value of the PIT.

5. The method according to claim 1, wherein, The step of updating the incremental time range, the recovery point parameter, and the PIT according to a pre-defined first method includes: Update the recovery point parameters to the PIT and the HADB that is in an active state at the time point corresponding to the PIT; Update the incremental time range to half of the original incremental time range; and The PIT is updated to the sum of the PIT before the update and the incremental time range after the update.

6. The method according to claim 1, wherein, The step of updating the incremental time range and the PIT according to a pre-defined second method includes: Update the incremental time range to half of the original incremental time range; and The PIT is updated to the difference between the PIT before the update and the incremental time range after the update.

7. The method according to claim 1, wherein, The step of updating the incremental time range and the PIT according to a pre-defined third method includes: In response to determining that the difference between the PIT and the incremental time range is less than the earliest time point in the historical data backup log, the incremental time range is updated to the difference between the PIT and the earliest time point; or, in response to determining that the difference between the PIT and the incremental time range is greater than or equal to the earliest time point in the historical data backup log, the incremental time range remains unchanged; and The PIT is updated to the difference between the PIT before the update and the incremental time range after the update.

8. The method according to claim 1, wherein, Determining the optimal recovery point based on the recovery point parameters includes: In response to determining that the recovery point parameter is not empty, the PIT included in the recovery point parameter is taken as the time point corresponding to the optimal recovery point; and the HA DB included in the recovery point parameter is taken as the HA DB corresponding to the optimal recovery point; or, In response to determining that the recovery point parameter is empty and no optimal recovery point has been found, the data fault recovery method is terminated.

9. The method according to claim 1, wherein, The backup logs of each HA DB include recovery point logs; The process of locating the optimal recovery point based on the historical data backup logs of the HA DB cluster includes: The initial value of the search start time point parameter is set to the current time point, and the initial value of the candidate recovery point parameter is set to empty; a. Starting from the time point corresponding to the search start time point parameter, traverse backward in time in the recovery point log to determine the next candidate recovery point that is closest to the search start time point, and update the candidate recovery point parameter and the search start point parameter based on the determined candidate recovery point; b. Instruct the backup system to export the data related to the candidate recovery points as PIT data to the test database; c. Prompt the user to check the PIT data in the test database, and receive the user's check result for the PIT data; d. In response to determining, based on the verification result, that the PIT data is historical data that has not been corrupted, execute step x; or, in response to determining, based on the verification result, that the PIT data is historical data that has been corrupted, execute step a; and x. Determine the optimal recovery point based on the recovery point parameters.

10. The method according to claim 9, wherein, The step of determining the next candidate recovery point closest to the search start time point by traversing the recovery point log chronologically from the time point corresponding to the search start time point parameter includes: Starting from the time point corresponding to the search start time point parameter, determine the target time point in the recovery point log that is closest to the search start time point and has an existing recovery point; Determine the number of recovery points at the target time point that were not selected as candidate recovery points; In response to determining that there is only one recovery point that is not selected as a candidate recovery point, the recovery point is selected as the candidate recovery point; or, in response to determining that there are multiple recovery points that are not selected as candidate recovery points, one recovery point is selected as the candidate recovery point; and Update the search start time and the time corresponding to the candidate recovery point parameters based on the time point corresponding to the recovery point, and update the HA DB corresponding to the candidate recovery point parameters based on the HA DB corresponding to the recovery point.

11. The method according to claim 10, wherein, Selecting a recovery point as the candidate recovery point includes: In response to determining that among the plurality of recovery points not selected as candidate recovery points is a recovery point corresponding to an HA DB in an active state, the recovery point corresponding to the HA DB in an active state is selected as the candidate recovery point; or, In response to determining that the recovery points not selected as candidate recovery points do not include the recovery points corresponding to the HA DB in an active state, any recovery point corresponding to the HA DB is selected as the candidate recovery point.

12. The method according to claim 9, wherein, Determining the optimal recovery point based on the recovery point parameters includes: In response to determining that the candidate recovery point parameter is not empty, the timestamp included in the candidate recovery point parameter is used as the time point corresponding to the optimal recovery point; and the HA DB included in the recovery point parameter is used as the HA DB corresponding to the optimal recovery point; or, In response to determining that the recovery point parameter is empty and no optimal recovery point has been found, the data fault recovery method is terminated.

13. The method according to claim 1, wherein, The data fault recovery based on the optimal recovery point in the HA DB cluster includes: Based on the time point corresponding to the optimal recovery point and the HA DB instruction backup system, the system extracts the historical data backed up by the HA DB at that time point; and The extracted historical data is copied to each HA DB in the HA DB cluster.

14. A data fault recovery device, comprising: HA DB Backup Monitor is used to obtain backup logs of a high availability database HA DB cluster. HA DB Status Monitor is used to obtain the status logs of the HA DB cluster; as well as The HA data recovery module is used to merge the backup logs and status logs of the HA DB cluster to generate historical data backup logs for the HA DB cluster; locate the optimal recovery point based on the historical data backup logs of the HA DB cluster; wherein the optimal recovery point corresponds to a point in time and an HA DB; the backup logs of each HA DB include continuous historical data backup records; and perform data fault recovery in the HA DB cluster based on the optimal recovery point. The process of locating the optimal recovery point based on the historical data backup logs of the HA DB cluster includes: Set the initial values ​​for the incremental time range and the search time parameter PIT, and set the recovery point parameter to an empty value, then perform the following steps; A. In response to determining that the incremental time range is less than a preset time threshold, execute step X; or, in response to determining that the incremental time range is greater than or equal to the preset time threshold, execute step B; B. Identify the HA DB that is in an active state at the time point corresponding to the PIT, and take it as the target HA DB; C. Instruct the backup system associated with the target HA DB to export the historical data backed up at the time point corresponding to the PIT as PIT data to the test database; D. Prompt the user to check the PIT data in the test database, and receive the user's check results for the PIT data; E. In response to determining, based on the verification result, that the PIT data is historical data that has not been destroyed, proceed to step F; or, in response to determining, based on the verification result, that the PIT data is historical data that has been destroyed, proceed to step G; F. Update the incremental time range, the recovery point parameter, and the PIT according to the preset first method, and then return to step A; G. In response to determining that the recovery point parameter is not null, execute step H; or, in response to determining that the recovery point parameter is null, execute step I; H. Update the incremental time range and the PIT according to the pre-set second method, and then return to step A; I. Update the incremental time range and the PIT according to the pre-set third method, and then return to step A; and X. Determine the optimal recovery point based on the recovery point parameters.

15. An electronic device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the data fault recovery method as described in any one of claims 1-13.

16. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the data fault recovery method according to any one of claims 1-13.

17. A computer program product comprising computer program instructions that, when executed on a computer, cause the computer to perform the data fault recovery method as described in any one of claims 1-13.

Images