Data failure recovery method and related equipment

Abstract

The invention provides a data failure recovery method. The data failure recovery method comprises the steps of obtaining a backup log of a high availability database (HA DB) cluster; obtaining a state log of the HA DB cluster; the backup log of the HA DB cluster and the state log of the HA DB cluster are combined, and a historical data backup log of the HA DB cluster is generated; positioning an optimal recovery point based on a historical data backup log of the HA DB cluster; wherein the optimal recovery point corresponds to one time point and one HA DB; and performing data fault recovery in the HA DB cluster based on the optimal recovery point. The invention further provides a data failure recovery device, electronic equipment, a storage medium and a program product.

Description

Technical Field

[0001] The present disclosure relates to the field of data processing technology, and in particular to a data failure recovery method and related equipment. Background Art

[0002] At present, enterprises usually use the recovery time objective (RTO) to define their acceptable downtime. RTO is a measure of the time required for a business to recover from a faulty state to a running state, representing the total downtime from the occurrence of a business fault to the recovery of the business. For example, a 5-minute RTO means that the business application may be unavailable for 5 minutes. Therefore, reducing or eliminating the RTO of a business has become the goal of most enterprises. Summary of the invention

[0003] In view of this, an embodiment of the present disclosure provides a data failure recovery method. The above method includes: obtaining a backup log of an HADB cluster; obtaining a 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 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 HADB; and performing data failure recovery in the HA DB cluster based on the optimal recovery point.

[0004] In an embodiment of the present disclosure, the above-mentioned obtaining the backup log of each HA DB in the HA DB cluster includes: obtaining the backup log of each HA DB from the backup system corresponding to each HA DB in the HA DB cluster; generating the backup log of the HA DB cluster based on the backup log of each HA DB; and determining the target time range corresponding to the backup log of the HA DB cluster.

[0005] In an embodiment of the present disclosure, the above-mentioned acquisition of 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 notification of each HA DB; and extracting the 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 an embodiment of the present disclosure, the backup logs of the above-mentioned respective HA DBs include continuous historical data backup records; the positioning of 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, and setting the recovery point parameter to a null value, and then executing the following steps;

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

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

[0009] C. instructing 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. Prompting the user to check the PIT data in the test database, and receiving the user's verification result on the PIT data;

[0011] E. In response to determining that the PIT data is undamaged historical data based on the verification result, executing step F; in response to determining that the PIT data is damaged historical data based on the verification result, executing step G;

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

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

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

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

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

[0017] In an embodiment of the present disclosure, the above-mentioned setting of the incremental time range and the initial value of PIT includes: determining the initial value of the incremental time range based on the user's selection or a pre-set default value; and taking the difference between the current time point and the incremental time range as the initial value of the PIT.

[0018] In an embodiment of the present disclosure, the above-mentioned updating of the incremental time range, the recovery point parameters and the PIT in a pre-set first manner includes: updating the recovery point parameters to: the PIT and the HA DB that is 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 an embodiment of the present disclosure, updating the incremental time range and the PIT in a preset second manner includes: updating the incremental time range to half of the incremental time range before updating; and updating the PIT to the difference between the PIT before updating and the incremental time range after updating.

[0020] In an embodiment of the present disclosure, the above-mentioned updating of the incremental time range and the PIT in a pre-set third manner 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, updating the incremental time range 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, keeping the incremental time range unchanged; and updating the PIT to the difference between the PIT before the update and the incremental time range after the update.

[0021] In an embodiment of the present 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, using the PIT included in the 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; and in response to determining that the recovery point parameters are empty, failing to search for the optimal recovery point, and ending the data failure recovery method.

[0022] In an embodiment of the present disclosure, the backup logs of the above-mentioned respective HA DBs include recovery point logs; the 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 be 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 closest to the search start time point, and update the candidate recovery point parameter and / or the search start point parameter based on the determined candidate recovery point;

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

[0025] c. Prompting the user to check the PIT data in the test database, and receiving the user's verification result on the PIT data;

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

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

[0028] In an embodiment of the present disclosure, starting from the time point corresponding to the search start time point parameter, traversing backward in time in the recovery point log to determine the next candidate recovery point closest to the search start time point includes: starting from the time point corresponding to the search start time point parameter, determining in the recovery point log a target time point of an existing recovery point closest to the search start time point; determining the number of recovery points at the target time point that have not been selected as candidate recovery points; in response to determining that there is only one recovery point that has not been selected as a candidate recovery point, using the recovery point as the candidate recovery point; in response to determining that there are multiple recovery points that have not been selected as candidate recovery points, selecting a 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 an embodiment of the present disclosure, the above-mentioned selection of a recovery point as the candidate recovery point includes: in response to determining that the multiple recovery points that are 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 multiple recovery points that are not selected as candidate recovery points do not include a recovery point corresponding to an HA DB in an active state, selecting a recovery point corresponding to any HA DB therefrom as the candidate recovery point.

[0030] In an embodiment of the present 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, failing to search for the optimal recovery point, and terminating the data failure recovery method.

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

[0032] Based on the above data failure recovery method, the embodiment of the present disclosure further discloses a data failure recovery device, including:

[0033] HADB backup monitor, used to obtain the backup log of HA DB cluster;

[0034] A HADB status monitor, configured to obtain a status log of the HA DB 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 a historical data backup log of the HA DB cluster; locate the best recovery point based on the historical data backup log of the HA DB cluster; wherein the best recovery point corresponds to a time point and an HA DB; and perform data failure recovery in the HADB cluster based on the best recovery point.

[0036] In addition, an embodiment of the present disclosure further 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 implements the above-mentioned data failure recovery method when executing the program.

[0037] An embodiment of the present disclosure further provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the above-mentioned data failure recovery method.

[0038] An embodiment of the present disclosure further provides a computer program product, including computer program instructions. When the computer program instructions are executed on a computer, the computer executes the above-mentioned data failure recovery method.

[0039] It can be seen from this that the data failure recovery method and related equipment provided by the embodiments of the present disclosure can support application developers or database administrators (DBA) to quickly locate the optimal recovery point when a data failure occurs, and complete the data failure recovery of the HADB cluster based on the above optimal recovery point with the lowest possible recovery point objective and recovery time objective. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the present disclosure or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0041] Figure 1 An example of deploying a high-availability database (HA DB) in two data centers according to an embodiment of the present disclosure is shown.

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

[0043] Figure 3 An example of implementing data failure recovery in an HA DB cluster according to an embodiment of the present disclosure is shown.

[0044] Figure 4A An example of the HA DB status monitor 3100 according to an embodiment of the present disclosure is shown.

[0045] Figure 4B The specific process of the HADB status monitor 3100 generating the status log 4010 of the HA DB cluster according to the embodiment of the present disclosure is shown.

[0046] Figure 4C The specific processing process of the HA DB status monitor 3100 when the HA data recovery module 3300 queries the status log of the HA DB cluster according to the embodiment of the present disclosure is shown.

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

[0048] Figure 5B The specific process of the HADB backup monitor 3200 querying the backup log 5010 according to the embodiment of the present disclosure is shown.

[0049] Figure 6 The specific process of the HA data recovery module 3300 described in some embodiments of the present disclosure recovering HA DB data failure based on continuous historical data backup records is shown.

[0050] Figure 7 An exemplary search process of locating the best recovery point in the continuous historical data backup records by the HA data recovery module 3300 according to the embodiment of the present disclosure is shown.

[0051] Figure 8The specific process of restoring HA DB data by the HA data recovery module 3300 described in some other embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0052] In order to make the objectives, technical solutions and advantages of the present disclosure more clearly understood, the present disclosure is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0053] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present disclosure should be understood by people with ordinary skills in the field to which the present disclosure belongs. The "first", "second" and similar words used in the embodiments of the present disclosure do not indicate any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used 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 above, reducing or eliminating the RTO of a business has become the goal of most enterprises. As of now, since the high-availability database (HA DB) cluster configuration allows IT services to fail over quickly, more and more enterprises have begun to use HA DB clusters to deploy their mission-critical databases (DB), file servers, data object servers, etc. to reduce the RTO of the business. Deploying an HA DB cluster is very important for enterprises with critical applications. In this HA DB cluster, data services can fail over without causing downtime. Specifically, the failover of data services can reduce or eliminate the downtime caused by system equipment failures, thereby achieving the RTO target, and the failover of data services can cover scenarios where system maintenance such as software upgrades is required. Therefore, by deploying the HADB cluster in the data center, the business can minimize the downtime caused by unpredictable major disasters. In applications, the above-mentioned HA DB cluster can usually be composed of active-active (Active-Active) or active-passive (Active-Passive) data service nodes (that is, HA DB). Among them, the above-mentioned active-passive data service nodes can also be called active-standby (Active-Standby) data service nodes.

[0055] In order to further reduce or eliminate the RTO of the business, some enterprises establish two or more data centers and deploy HA DB in these data centers in a geographically distributed manner. In addition, one active data service node and two or more standby / passive data service nodes can be deployed in the above two or more data centers.

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

[0057] In addition, in the embodiments of the present disclosure, the above-mentioned data services are usually executed in a server, which can be a virtual machine, a virtual device or a physical server, and the present disclosure does not limit this. In the embodiments of the present disclosure, the term "node" or "data service node" can be used to describe a virtual server or a physical server on which a data service is executed, so it can also be called a data server or a database server. The DB or DB server described in the embodiments of the present disclosure refers to a server on which a data service is executed. The HA DB described in the embodiments of the present disclosure generally refers to a high availability database server.

[0058] Figure 1 An example of deploying HA DB in two data centers according to an embodiment of the present disclosure is shown.

[0059] exist Figure 1 In the example shown, four HA DBs are shown: DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140. The four HA DBs are deployed in two data centers: data center-1 1010 and data center-2 1020. The data centers 1010 and 1020 can be connected via a wide area network (WAN) 1030. DB-a 1110 and DB-b 1120 are connected via their local intranet 1012. DB-c 1130 and DB-d 1140 are connected via their local intranet 1022. The DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140 are connected to each other and can communicate with the WAN 1030 via their intranets 1012 and 1022.

[0060] It should be noted that the network is a specialized field and may be quite complex, and the purpose of this disclosure is not to provide a detailed description of the network. That is to say, the above-mentioned WAN 1030 and the above-mentioned local intranets 1012 and 1022 can be implemented according to the existing WAN and local intranet standards and implementation methods, which will not be repeated here.

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

[0062] also, Figure 1 The data storage devices 1111, 1112, 1131 and 1141 respectively deployed in the HA DBs are also shown. The above data storage devices are used to store data of the corresponding 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-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140) are further shown. It should be noted that the above HA DBs communicate via the intranet 1012, 1022 and WAN 1030 ( Figure 2 not shown).

[0064] exist Figure 2 In the example shown, the status of DB-a 1110 is active and the read and write functions are enabled. In this example, the application (also referred to as application) 2010 can read data from the data storage 1111 through DB-a 1110 and write the read data to 2012 DB-a 1110. The status of DB-b 1120 is full hot standby (Hot-Standby), and the application 2020 has enabled the read-only function 2022. The status of DB-c 1130 and DB-c 1140 is warm standby (Warm-Standby), which means that the data storage is not allowed to be accessed. The full 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, that is, switch from the standby state to the active state, when the active DB-a 1110 fails, or when the IT administrator decides to shut down DB-a 1110 for maintenance purposes. The process of switching from the standby state to the active state in the HA DB cluster is called failover or switchover. Generally, the above failover or switchover can be implemented through failover control.

[0065] like Figure 2As shown, DB-a 1110 in the active state can copy 2110, 2120, 2130 all its data modifications to DB-b 1120, DB-c 1130 and DB-d 1140. The above-mentioned copying 2110, 2120, 2130 operations can be performed in a synchronous manner or an asynchronous manner. In the case of performing synchronous copying 2110, 2120, 2130, when the application 2010 issues a data update request to DB-a 1110, it is necessary to submit the changes at each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) to successfully complete the above-mentioned data update request. In the case of performing asynchronous copying 2110, 2120, 2130, when the application 2010 issues a data update request to DB-a 1110, it is only necessary to submit the changes at DB-a 1110 to successfully complete the above-mentioned data update request. For asynchronous replication, data modifications made at DB-a 1110 in the active state may be replicated 2110, 2120, 2130 to other HA DBs (e.g., DB-b 1120, DB-c 1130, and DB-d 1140) in the standby state periodically by streaming or batching after transactions are completed according to the configuration.

[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 operating costs, as well as the risk of difficulty in recovering from data corruption.

[0067] As can be understood, regarding capital and operational costs, in order to implement an HA DB cluster, two or more HA DB hosts and software must be purchased and managed, rather than just one HA DB host. Moreover, when an HA DB cluster is deployed on two or more data centers, operational complexity increases significantly. Administrators must configure, manage, and monitor the data replication process and perform failover control when necessary. When configuring automatic failover, administrators may have to manually check the status of the HADB periodically to monitor the HA DB in the 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 is corrupted, the corrupted data is also replicated from the active HADB to all the standby HA DBs. In some cases, this situation may cause a momentary failure of the business application. In other cases, the corrupted data may not be discovered for a period of time. At this stage, the arduous task of finding a point in time when data failure can be recovered and restoring the data of all HA DBs to the correct data state when a data failure occurs is usually only handled manually by application developers and DB administrators (DBAs). It is also in the interest of application developers or DBAs to restore the HA DB cluster to a state with minimal data loss, that is, to achieve a lower recovery point objective (RPO). It should be noted that RPO is a measure of 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 you manually find the time point with the least data loss before the data failure occurs (usually understood as the time point when the data is not damaged and is closest to the current time), that is, find the best time point for data failure recovery to achieve the best RPO, RTO may take up to several hours or even days.

[0069] For the convenience of description, in the embodiment of the present disclosure, the time point at which data failure recovery can be performed can be identified by a recovery point. Moreover, since there are multiple HA DBs in the HA DB cluster in the embodiment of the present disclosure, in addition to determining the time point for data failure recovery, it is also necessary to identify which HA DB backup data is used to perform data failure recovery at this time point. Therefore, in the embodiment of the present disclosure, each recovery point will point to a time point and an HA DB. Based on the determined recovery point, undamaged data can be obtained, so that data failure recovery of the HA DB cluster can be performed. It can be understood that in the process of data failure recovery, multiple recovery points may be found. Different recovery points may correspond to different time points or different HA DBs. In order to improve the efficiency of data failure recovery, the time point with the least data loss before the data failure occurs (the time point closest to the current moment) and the corresponding HA DB are found from multiple recovery points to become the target of data failure recovery. In the embodiment of the present disclosure, the above-mentioned process of finding the time point with the least data loss before the data failure occurs and the corresponding HA DB can be referred to as the process of searching or locating the best recovery point.

[0070] It can be seen that even if there is an HA DB cluster, it cannot completely solve the problem of recovery point objective (RPO) and recovery time objective (RTO) of key business applications. Therefore, the embodiments of the present disclosure propose solutions to solve the above problems.

[0071] Figure 3 An example of implementing data failure recovery in an HA DB cluster provided by an embodiment of the present disclosure is shown. Figure 3 As shown, in order to solve the RPO and RTO problems of key business applications, an HA data recovery assistant (HA DR Assistant) 3010 will be further deployed in the above HA DB cluster. In addition, a backup system (backup system-1 3204 and backup system-2 3208) and a test DB (Test-DB1 3222 and Test-DB2 3224) for data testing in each data center will also be deployed in each data center. Each test DB will include a test data storage (Test-store-1 3226 and Test-store-2 3228).

[0072] Based on the above Figure 2 The deployment of the HA DB shown, an embodiment of the present disclosure provides a data failure recovery method, which is applied to the above-mentioned HA DR Assistant 3010, and is used to support application developers or 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 above-mentioned best recovery point with the lowest possible RPO and RTO.

[0073] In an embodiment of the present disclosure, the HADR Assistant 3010 can work together with the backup system. Since the business using the HA DB cluster cannot tolerate long-term application downtime or excessive data loss, the backup system used should have the ability to frequently or continuously back up data. Therefore, in an embodiment of the present disclosure, a backup system of the continuous data protection (CDP) or near continuous data protection (nCDP) type is the first choice for the backup system-1 3204 and the backup system-2 3208.

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

[0075] In the process of locating the best recovery point, the HADR Assistant 3010 of the embodiment of the present disclosure needs to first 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, so as to confirm whether these candidate recovery points are real recovery points. This is the purpose of deploying test DBs (for example, Test-DB1 3222 and Test-DB-2 3224). In the embodiment of the present disclosure, the test DB is used to store data extracted based on the candidate recovery points. In this way, the application developer or DBA can only check and confirm whether the data in the test DB is damaged to confirm whether the candidate recovery point is a real recovery point, without having to check all the backed-up data of the HADB cluster. Therefore, the time required for data inspection is greatly shortened, so that the lowest possible RPO and RTO targets can be achieved.

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

[0077] It is necessary to mention that the embodiment of the present disclosure deploys two backup systems and two test DBs. However, in actual applications, it is not necessary to deploy exactly two backup systems and test DBs, and the purpose can be achieved by deploying one or more such backup systems and test DBs.

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

[0079] As part of the data failure recovery process, the HA data recovery module 3300 may request 3302 the HA DB cluster status log from the HA DB status monitor 3100 ( Figure 4A 4010 in the figure). The status log of the above-mentioned HA DB cluster is composed of the status of each HA DB at multiple time points. The HA DB status monitor 3100 can receive the status information of HA DB 3102, 3104, 3106, 3108 from each HA DB (for example, DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140) respectively by query and notification, thereby generating the status log of the above-mentioned HA DB cluster. In other embodiments, the HA DB status monitor 3100 can also receive HADB status information from other system monitoring software without directly communicating with the HADB. The specific process of the HA DB status monitor 3100 collecting the status information from each HA DB (for example, DB-a 1110, DB-b 1120, DB-c 1130, DB-d 140) can be as shown in the figure. Figure 4B As shown, we will skip this for now.

[0080] As part of the data failure recovery process, the HA data recovery module 3300 may also request 3304 the backup log of the HA DB cluster from the HA DB backup monitor 3200. Figure 5A Then, the HADB backup monitor 3200 may request the backup records of each HADB in 3202 and 3206 from the backup systems 3204 and 3208, and after generating the HA DB backup records, the HA DB backup monitor 3200 is returned, and the HA data recovery module 3300 generates the backup log of the HA DB cluster. The process of the HA DB backup monitor 3200 collecting each HA DB backup record may be as follows: Figure 5B As shown, we will skip it here for now.

[0081] Furthermore, during the data failure recovery process, the HA data recovery module 3300 will combine the status log of the HA DB cluster and the backup log of the HA DB cluster to search for the time point with the least data loss before the data failure occurs, that is, the best recovery point. Usually, since there may be multiple recovery points for data, it is difficult for the HA data recovery module 3300 to locate the best recovery point at once. Usually, a candidate recovery point is first located, and after confirming whether it is a real recovery point, the best recovery point is further searched based on the confirmed recovery point. This is usually a cyclic search process.

[0082] In addition, as mentioned above, since the current HADB cluster includes multiple HADBs, and each HA DB stores its own data, in the embodiment of the present disclosure, the above recovery point not only identifies the time point, but also identifies a specific HA DB, that is, indicates the source of the backup data. In this way, in the process of data failure recovery, the HA data recovery module 3300 will export 3221, 3223 the data backup of the corresponding time point to Test-DB1 3222 or Test-DB2 3224 based on the time point indicated by the determined candidate recovery point and the backup system 3204, 3208 corresponding to the HA DB instructions 3306, 3308, so that the application developer or DBA can check the data.

[0083] The following will use Figures 3 to 8 The illustrated embodiment is used to illustrate a data failure recovery method applied to an HA DB cluster.

[0084] Figure 3 The module diagram of HA DR Assistant 3010 is shown, and the data failure recovery method in the current HA DB cluster is exemplified. Figure 3 As shown, there are three main modules in the HA DR Assistant 3010, namely, the HA DB status monitor 3100, the HA DB backup monitor 3200 and the HA data recovery module 3300.

[0085] In the above embodiment, the HADB status monitor 3100 can interact 3102, 3104, 3106, 3108 with each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) 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 by registering. In an alternative embodiment, the above HA DB 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 according to an embodiment of the present disclosure is shown. In the current embodiment, as Figure 4A As shown, when the HADB state monitor 3100 receives 3102, 3104, 3106, 3108 notifications of state changes to a certain HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, or DB-d 1140) or when the HA DB state monitor 3100 periodically queries 3102, 3104, 3106, 3108 and obtains the state of each HA DB, the HA DB state monitor 3100 saves the obtained state information of the HA DB to the state log (HA DB-State-Log) 4010 of the HA DB cluster. Table 1 below shows an example of the HA DB cluster state information recorded in the state log 4010 of the HA DB cluster.

[0087] It should be noted that, in an embodiment of the present disclosure, the status information of the above-mentioned HA DB may include UP-ACTIVE, UP-STANDBY or DOWN. Among them, both the full hot standby state and the hot standby state will be recorded as UP-STANDBY. In different embodiments, different backup modes may be recorded as different states. UP-ACTIVE means that HA DB is UP (available) and is in an active state and can be used for reading and writing. UP-STANDBY means that HA DB is in UP (available) state, but is in a full hot standby state (read-only) or a hot standby state (neither readable nor writable). DOWN means that HA DB is unavailable and the system is shut down.

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

[0089] OK Timestamp DB-a 1110 DB-b 1120 DB-c 1130 DB-d 1140 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 the above Table 1 is an example of a status log 4010 of an HA DB cluster, which can be monitored by the HA DB status monitor 3100 through Figure 4B The specific process shown is generated.

[0091] In Table 1, each row of data consists of a timestamp representing a time point and the status information of all HA DBs at the time point represented by the timestamp. For this HA DB cluster, at any time, only one HADB can have the status information UP-ACTIVE, and the other HA DBs are either in the UP-STANDBY state, ready to take over the active role of the UP-ACTIVE HA DB when the UP-ACTIVE HA DB fails (failover), or 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", and the status information of DB-b 1120, 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 becomes "DOWN". At this time, DB-b 1120 takes over the active role of DB-a 1110, so its status information will be changed to "UP-ACTIVE".

[0092] Figure 4B The specific process of the HA DB status monitor 3100 generating the status log 4010 of the HA DB cluster according to some embodiments of the present disclosure is shown.

[0093] In step 4100, the HA DB status monitor 3100 starts capturing HA DB status information.

[0094] In step 4102, each HA DB is configured to provide HADB state change notifications to the HA DB state monitor 3100 when their states change.

[0095] In the embodiment of the present disclosure, the HADB state change notification will include: a timestamp corresponding to the time point when the state change occurs and state information of the HA DB after the state change.

[0096] Alternatively, in the above step 4102, the external HA DB monitoring software may also be configured to provide the HA DB state change notification to the HADB state monitor 3100 when the state of the HA DB changes.

[0097] At step 4120, the HA DB state monitor 3100 creates a listener to wait for HA DB state change notifications.

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

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

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

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

[0102] In step 4110, if the HADB state monitor 3100 has not terminated, the process returns to step 4104 to continue to periodically query the state of the HADB. Otherwise, the process proceeds to step 4140.

[0103] At step 4140, the HADB state monitor 3100 ends its processing.

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

[0105] In step 4122, when the HA DB state monitor 3100 receives the state change notification of 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, and enters it into the HA DB cluster status log 4010. Then, the process returns to step 4120 to continue to monitor notifications.

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

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

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

[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 The detailed processing procedure of the HADB status monitor 3100 is shown when the HA data recovery module 3300 queries the status log of the HA DB cluster.

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

[0113] At step 4202 , the HA DB status monitor 3100 receives a request for obtaining the HA DB cluster status log from the HA data recovery module 3300 .

[0114] Among them, in the embodiment of the present disclosure, the above-mentioned request for obtaining the HA DB cluster status log will be used to indicate the query of the status log record of the HA DB cluster within a period of time (from a start time to an end time), that is, the above-mentioned request for obtaining the HA DB cluster status log usually includes a start time and an end time.

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

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

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

[0118] Figure 5AFIG. 3 shows an example of the HADB backup monitor 3200 according to an embodiment of the present disclosure. Figure 5A As shown, after the HADB backup monitor 3200 collects the backup records of each HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) from the backup systems 3204 and 3208, a backup log 5010 of the HA DB cluster can be generated. Figure 5A Two backup systems are shown, but the method described in the embodiment of the present disclosure can be applied to a scenario where one or any number of backup systems are deployed in one or more data centers.

[0119] like Figure 3 As shown, during the normal execution of the business, 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 3212, 3214, 3216, 3118 to the backup systems 3204, 3208. In other words, the backup systems 3204, 3208 can obtain the historical data of each HA DB backup and the time point of the backup.

[0120] In an embodiment of the present disclosure, the backup system can back up the historical data of the HA DB in one of two different forms: continuous historical data backup or recovery point backup. Some continuous data protection (CDP) backup systems can store protected historical data in a continuous manner. Based on these stored historical data, the data of the HADB can be restored to any time point in the past. However, it can be understood that the method of storing continuous historical data is very resource-intensive. Most CDP backup systems or near-continuous data protection (nCDP) systems will save historical data regularly, and for the convenience of description, the HADB of each backed-up historical data and its corresponding time point are collectively referred to as recovery points. This backup method is also called a recovery point-based backup method. In the recovery point-based backup method, the data of the HADB can be restored to a time point corresponding to any recovery point in the past.

[0121] In an embodiment of the present disclosure, if the historical data backed up by the backup system is continuous, the backup log 5010 of the HADB 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 HADB cluster may look like the example shown in Table 2B.

[0122] In order to illustrate in conjunction with the data in Table 1, the example data in Table 2A is aligned with the HA DB state timeline in Table 1. That is, in this example, the backup of historical data starts from the time point corresponding to the timestamp "20240101:00:00:00". As shown in Table 2A, in the column "DB-a 1110", the historical data of DB-a 1110 can be continuously obtained from "20240101:00:00:00" to "20240118:05:10:39". However, the historical data of DB-a 1110 will no longer be obtained thereafter, because starting from "20240118:00 05:10:39", DB-a 1111 fails and is closed (DOWN). Among them, in Table 2A, "^" represents historical data that has backup; and "X" represents historical data that does not have backup. In the "DB-b1120" column, the historical data of DB-b 1120 can be continuously obtained from "20240101:00:00:00" to "20240105:12:28:05", and then from "20240108:19:03:17" to "NOW" (now). However, from "20240105:12:28:05" to "20240108:19:03:17", because DB-b 1120 fails and is closed (DOWN), the historical data of DB-b 1120 cannot be obtained. Since DB-c 1130 and DB-d 1140 are not faulty, the historical data of these two HADBs can be continuously obtained from "0240101:00:00:00" to "NOW".

[0123] Table 2A: HADB cluster backup log 5010 - continuous historical data backup record

[0124]

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

[0126] Similarly, in order to illustrate in conjunction with the data in Table 1, the example data in Table 2B is aligned with the HA DB state timeline in Table 1. In the example in Table 2B, the backup record of historical data also starts from "20240101:00:00:00". Unlike Table 2A, the historical data in Table 2B can only be obtained at each time point when the backup occurs.

[0127] In fact, each of DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140 may have its own backup schedule, resulting in different recovery points for each HA DB. However, for simplicity of description, 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) are backed up using the same schedule. Assume that in the example in Table 2B, the backup plan is executed every 6 hours, at 00:00:00, 06:00:00, 12:00:00, and 18:00:00 every day, respectively.

[0128] Based on the above assumptions about the data backup schedule, as shown in Table 1, during the period from “20240101:00:00:00” to “20240105:12:00:00”, DB-a 1110, DB-b 1120, DB-c 1130, and DB-d 1140 all operate normally. 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, during "20240105:18:00:00" to "20240108:18:00:00 (time period 2), DB-b1120 fails (the status is DOWN starting from 20240105:12:28:05 in Table 1). Therefore, DB-b 1120 does not have any recovery points. The other DB-a 1110, DB-c 1130, and DB-d 1140 still have 13 recovery points respectively. Although Table 2B does not show all recovery points, these recovery points should include: {20240108:18:00:00, 20240108:12:00:00, ..., 20240106:00:00:00, 20240105:18:00:00}.

[0130] Assuming that the current time NOW is 20240118:18:00:00, similarly, consistent with Table 1, DB-a 1110 starts to fail (DOWN) from 20240118:05:10:39, so from "20240118:06:00:00" to "20240118:18:00:00 (NOW)" (i.e., time period 4), DB-a 1110 will not have any recovery points. The other DB-b 1120, DB-c 1130, and DB-d 1140 still have three recovery points respectively. Although Table 2B does not show all recovery points, these recovery points should include: {20240118:06:00:002020118:12:0:002020118:18:00:00}.

[0131] Table 2B: Backup log 5010 of HA DB cluster - recovery point

[0132]

[0133] As can be seen from the above examples, in the embodiments of the present disclosure, the above recovery points not only indicate the time when the data backup occurs, but also indicate the HA DB that performs the data backup. That is, in the embodiments of the present disclosure, each recovery point corresponds to a time point (the time point when the data backup occurs, which can be identified by a timestamp) and an HA DB (the HA DB that performs the data backup).

[0134] Figure 5B The specific process of the HA DB backup monitor 3200 querying the backup log according to the embodiment of the present disclosure is shown.

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

[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 log.

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

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

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

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

[0141] Figure 6 The specific process of the HA data recovery module 3300 according to the embodiment of the present disclosure recovering HADB data failure from continuous historical data is shown.

[0142] Figure 6 A specific process is presented that allows application developers or DBAs to perform data failure recovery of an HADB cluster based on the continuous history of backed-up data. In other words, Figure 6 The process shown is suitable for a backup system that can capture and store continuous historical data of HADB.

[0143] The above data failure recovery process starts at step 6000.

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

[0145] As mentioned above Figure 5B As shown, based on the request for obtaining the HADB cluster backup log 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 in this embodiment, the backup log 5010 of the HADB cluster contains backup records of continuous historical data, the backup log 5010 of the HA DB cluster received by the HA data recovery module 3300 looks like the example in Table 2A.

[0146] Thus, in step 6002, after obtaining the backup log 5010 of the HADB cluster, the HA data recovery module 3300 will further determine the target time range corresponding to the backup log of the HA DB cluster from the backup log 5010 of the HADB cluster. The above target time range refers to the time from the current time to the earliest time of the backup record therein. The earliest time is referred to as LastPIT in the present disclosure. LastPIT corresponds to the time point of the earliest historical data backed up in the backup system, and there is no old data before this time point.

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

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

[0149] In an embodiment of the present disclosure, the state log 4010 of the HA DB cluster contains the historical state of each HADB (eg, DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) in the HA DB cluster at multiple time points in the past.

[0150] As mentioned above Figure 4C As shown in the specific process, in step 4202, the HA DB state monitor 3100 will receive the above request to obtain the HA DB cluster state log. In step 4204, the HA DB state monitor 3100 will extract the state log of the HA DB cluster that falls within the above target time range. It should be noted that at the same time, the state log 4010 recording process of the HA DB cluster (from steps 4100 to 4140) is also in progress. In step 4206, the HA DB state monitor 3100 returns the extracted state log of the HA DB cluster to the HA data recovery module 3300.

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

[0152] In an embodiment of the present disclosure, the above-mentioned HA continuous historical data log may also be referred to as the historical data backup log of the HA DB cluster. An example of the above-mentioned HA continuous historical data log may be shown in Table 3A below. The above-mentioned HA continuous historical data record log contains a combination of the historical status of the HA DB and its continuous historical data backup record. The example in Table 3A is the result obtained by combining Table 1 and Table 2A above. Table 3A contains the historical status of each HA DB (for example, DB-a 1110, DB-b 1120, DB-c1130, DB-d 1140) and its continuous historical data backup record (recorded in the "CH" column under each HA DB in Table 3A).

[0153] Table 3A: HA continuous historical data backup log

[0154]

[0155]

[0156] From the embodiment of the present disclosure, it can be seen that Table 3A adds a new row (row 0) with a timestamp of "NOW", which stands for now. 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 of the status column of each HA DB (eg, DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) is from Table 1; and the data of its "CH" column is from Table 2A.

[0158] Specifically, the "CH" column under DB-a 1110 indicates the continuous historical data backup record of DB-a 1110. As shown in Table 2A, the failure of DB-a 1110 starts at the time point corresponding to the timestamp "20240118:05:10:39" (row 1), therefore, the "CH" of row 0 and row 1 of the corresponding data of DB-a 1110 is "X", which means that there is no historical data backup record (that is, no data backup is performed at the time point corresponding to this timestamp). Before the time point (row 1) corresponding to the timestamp "20240118:05:10:39", DB-a 1110 has no failure, therefore, the "CH" of row 2 to row 8 of the corresponding data of DB-a 1110 is "^", indicating that its continuous historical data backup record exists (that is, data backup is performed at the time point corresponding to this timestamp). Furthermore, as shown in Table 1, in three different time periods starting from the time points corresponding to timestamps 20240101:00:00:00, 20240108:19:03:17 and 20240115:21:05:35, DB-a 1110 is in the UP-ACTIVE state, that is, its role is the active HA DB in the HA DB cluster.

[0159] The columns of DB-b 1120, DB-c 1130, and DB-d 1140 in Table 3A are also the data of Table 1 and Table 2A combined in the same manner as DB-a 1110. The description will not be repeated here.

[0160] Back to Figure 6 After merging the backup log of the HA DB cluster (as shown in Table 2A) and the status log of the HA DB cluster (as shown in Table 1) to generate the HA continuous historical data backup log (as shown in Table 3A), the HA data recovery module 3300 can feed back the above HA continuous historical data backup log to the user (application developer or DBA), and continue to search the above HA continuous historical data backup log according to the method shown in steps 6008 to 6044 to locate the time point with the least data loss before the data failure occurs in the backed up historical data, that is, the best recovery point.

[0161] It can be seen that the HA data recovery module 3300 can locate the closest undamaged data by efficiently traversing the timeline, and can help users quickly find the recovery point with the least data loss, thereby achieving the best recovery point objective (RPO). In the most unfortunate case, the data may have been damaged for a long time before being discovered, and the entire backed-up historical data is damaged data, and there is no recoverable data in any backup system (as shown in step 6042).

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

[0163] exist Figure 7 , the sample recovery point shown in box 7100 is different from the style of the example in Table 3A, but it contains similar information, including the historical status of each HA DB and its historical data backup record. Among them, each small box 7111-7147 in box 7100 corresponds to a time slot and an HA DB respectively. For example, in the time slot corresponding to box 7111, the status of DB-a 1110 is "DOWN", and no historical data backup record is obtained in its backup system (no arrow). The solid arrows in boxes 7112, 7116, 7117, 7124, 7131, 7135, and 7143 indicate that their related HA DBs are in the active state in the time slots corresponding to these boxes, and there are historical data backup records. The dotted arrows indicate that the related HA DBs are in the standby state in the time slots corresponding to these boxes, but these HA DBs have historical data backup records in the backup system.

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

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

[0166] That is, in the above step 6008, 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 ​​of multiple search parameters are set before the search begins. The above search parameters include:

[0168] LastGood – This parameter corresponds to the recovery point indicating the one that can be used for data failure recovery, and can also be referred to as the recovery point parameter. In the embodiments 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 can be NIL (representing null). It can be understood that if the LastGood parameter is not empty, the HA DB and the 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 failure recovery of the HA DB cluster can be completed accordingly.

[0169] In the embodiments of the present disclosure, the initial value of LastGood can be set to NIL.

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

[0171] In the embodiments 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 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, this 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 in is 1 second, but this is not a hard limit of the present disclosure. In fact, the minimum D can be set based on experience, for example, at the sub-second level.

[0176] In step 6014, the HA data recovery module 3300 determines the HA DB in the active state in the above-mentioned PIT as the target HA DB.

[0177] Take scenario 1 7200 as an example. Figure 7 In the example, based on the determined PIT, the HA DB in the active state in the above PIT is DB-b 1120 , and 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, since at the time point corresponding to the PIT, the HA DB in the active state is DB-b 1120, its related backup system should be the backup system 3204, and 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. Further, 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 about the PIT data provided by the user. If the PIT data is undamaged historical data, the process jumps to step 6020; otherwise, the process jumps to step 6022.

[0181] If the process jumps to step 6020, it means that undamaged historical data has been located, and the historical data can be used for data failure recovery. However, the historical data may not be the historical data with the least data loss, that is, it may not be the data corresponding to the best recovery point. In other words, there may be other undamaged historical data from the above PIT to NOW, and because its corresponding timestamp is closer to NOW, its data loss is less. In order to further search for the best recovery point, you can then further search between the current PIT and NOW to find a time point when the data is not damaged, so as to achieve the least amount of data failure recovery. Therefore, in step 6020, the following operations will be performed.

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

[0183] In the embodiment of the present disclosure, the above-mentioned updating of the search parameters in the pre-set first manner may specifically include the following aspects:

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

[0185] use Figure 7 As an example, the location pointed to by arrow 7202 is the location where the uncorrupted historical data record is found. In this case, the timestamp in the LastGood parameter can be set to the current PIT, that is, the time slot corresponding to box 7124. In addition, the LastGood parameter will also include the identifier of the HA DB in the active state in the above PIT, that is, the identifier of DB-b 1120.

[0186] 2) Update the incremental time range D to half of the previous D value, that is, 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 PIT before the update and the incremental time range D after the update, that is, let PIT = PIT + D. The goal is to find the latest time point where the data is not corrupted.

[0188] After the above search parameters are updated according to the above first method, the search process will return to the aforementioned step 6012.

[0189] Still using Figure 7In scenario 1 7200, the previously searched undamaged PIT historical data is located at 7202, and the LastGood parameters can be updated to include: PIT = 7124 and DB-b1120. D is further divided by half to obtain the updated incremental time range 0.5d, where d represents the initial value of the incremental time range D. Further, update PIT = PIT + 0.5d, and the updated PIT will be located at the position pointed by arrow 7204. Assuming that 0.5d is still greater than 1 second, continue to use Figure 7 Scenario 17200 is taken as an example. In step 6014, the updated PIT is the position pointed by arrow 7204, the HA DB in the active state in the 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 to Test-DB1 3222 as PIT data, and the user is prompted to perform a data check.

[0190] Assume that after checking, it is determined that the PIT data is damaged. This scenario is shown in 7206. At this time, the HA data recovery module 3300 must go back in time to find the recovery point corresponding to the historical data that was not damaged before the PIT. In this way, after step 6018, the above process jumps to step 6022.

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

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

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

[0194] In the embodiment of the present disclosure, updating the search parameters in the preset second manner may include the following aspects:

[0195] 1) Update the incremental time range D to half of the value of D before the update, that is, set D=D / 2, so that data search can be performed within a narrower incremental time range.

[0196] exist Figure 7In Scenario 1 of 7200, 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 the update and the updated incremental time range D, that is, let PIT = PIT - D.

[0198] Still use Figure 7 Scenario 1 of 7200 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 when the above PIT is in the active state, the HA DB 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 according to the first method, 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 active HA DB is DB - d1140; D = D / 2; and 3) PIT = PIT + D.

[0199] In Figure 7 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 according to the preset third method, and then returns to 6012.

[0201] In the embodiments of the present disclosure, the above-mentioned updating of the search parameters according to the preset third method 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 the update and the updated incremental time range D, that is, let PIT = PIT - D.

[0204] Assuming that the currently updated incremental time range D is equal to or less than 1 second (a pre-set 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] That is, the timestamp in the LastGood parameter is used as the time point corresponding to the best recovery point, and the HA DB identifier in the LastGood parameter is used 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 above-mentioned optimal recovery point to each HADB.

[0208] The above data failure recovery process will be successfully completed at step 6046.

[0209] It should be noted that the data failure recovery of the above HA DB cluster 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 scenes, scene 2 7300 and scene 3 7400, are also shown.

[0211] In scenario 2 7300, at step 6018, the user reports that PIT data 7124 (data at the location pointed by arrow 7302) has been damaged. Then the process jumps to step 6022, and the search parameters are updated at step 6024. Since no undamaged PIT data has been found, LastGood = NIL is still maintained. Next, at step 6026, the HA data recovery module 3300 moves the PIT further back to the incremental time range D, and the updated PIT is at the location pointed by arrow 7304. Assuming that the new PIT data (data 7117) is not damaged through data inspection, the process continues as follows. Figure 6 The method shown in FIG. 7 is to update the timestamp of the LastGood parameter to the timeslot corresponding to box 7117, and obtain a new D (0.5d) and set PIT = PIT + 0.5d, that is, to move D forward to obtain a new PIT (the position pointed to by arrow 7306). In this case, assuming that the new PIT data (box 7116) is not damaged by data inspection, continue to follow Figure 6The method shown in FIG. 1 updates the LastGood parameter to the time slot corresponding to box 7116, and obtains a new D (0.25d) and sets PIT = PIT + 0.25d, that is, continues to move PIT forward by D to obtain a new PIT (the position indicated by arrow 7308). Assuming that the new PIT data (data 7135) is damaged by data inspection, D (0.125D) is updated and PIT = PIT + 0.125d, that is, PIT is moved backward by D to obtain a new PIT (the position indicated by arrow 7310) ..., and the best recovery point can be determined by continuing in this way.

[0212] exist Figure 7 In scenario 3 7400, it is assumed that the PIT data at the position pointed by arrow 7402 has been damaged, and then the process jumps to step 6022. Since the undamaged PIT data is currently found, that is, LastGood=NIL, in step 6026, the HA data recovery module 3300 further moves the PIT backward by the incremental time range D, and the new PIT is the position pointed by arrow 7404. If it is assumed that the PIT data at the position pointed by arrow 7404 has also been damaged, then the process jumps to step 6022 again. Since the undamaged PIT data is still found, that is, LastGood=NIL, in step 6026, the HA data recovery module 3300 further moves the PIT backward by the incremental time range D, and the updated PIT exceeds the LastPIT of the historical data record. In step 6026, D needs to be adjusted, and the new PIT is set to LastPIT, that is, the position pointed by arrow 7406. After checking the data again, if the PIT historical data is still damaged, 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, that is, no backup historical data is found to be used to recover the data failure.

[0213] From the above process, it can be seen that Figure 6 This paper presents an algorithm for quickly traversing continuous historical data of HA DB, allowing users to quickly identify the time point of undamaged data closest to the current time point, that is, locate the best recovery point, thereby achieving the best RPO. In addition, the above method can also quickly recover data failures of HA DB cluster, thereby achieving the best RTO.

[0214] In other embodiments of the present disclosure, the backup system will periodically capture and back up the historical data of the HA DB (e.g., DB-a 1110, DB-b 1120, DB-c 1130, DB-d 1140) in a discrete form. 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 point in time in the past, but can only be restored to one of the time points of the backup historical data. Figure 8 The process shown in is to support the above scenario. Specifically, Figure 8 The specific process of restoring HA DB data by the HA data recovery module 3300 described in some embodiments is shown.

[0215] It should be noted that, depending on how to obtain and back up historical data, the method of the embodiment of the present disclosure may include two processes.

[0216] and Figure 6 The purpose is the same, Figure 8 It also shows a specific process that allows application developers and DBAs to perform data failure recovery in an HA DB cluster.

[0217] The data failure recovery process described in the embodiment of the present disclosure starts from step 8000.

[0218] In step 8002 , the HA data recovery module 3300 sends a request 3304 for obtaining a backup log of the HA DB cluster to the HA DB backup monitor 3200 , so as to obtain a backup log 5010 of the HA DB cluster.

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

[0220] Also 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. The target time range is from the current time to the earliest time when there are no more historical data backup records. Among them, in the embodiment of the present disclosure, the earliest time is called LastPIT. It can be understood that LastPIT is the time point corresponding to the earliest historical data backup record in the backup system. There is no earlier historical data record before this time point.

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

[0222] It should be noted that, in the embodiment of the present disclosure, the state log 4010 of the HA DB cluster obtained is the state log 4010 of the HA DB cluster within the target time range (from now to LastPIT).

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

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

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

[0226] In the disclosed embodiment, the above recovery point log may also be referred to as a historical data backup log of the HA DB cluster. Table 3B shows an example of a recovery point log. The time point corresponding to the above recovery point is described as a timestamp in the example of Table 3B.

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

[0228] Table 3B: Recovery Point Log

[0229]

[0230]

[0231] Assume that the backup starts at "20240101:00:00:00" (line 16). At this time point, the status of DB-a 1110 is active, and the other HA DBs (e.g., DB-b 1120, DB-c 1130, DB-d 1140) are in standby status. Moreover, corresponding to this time point, each HA DB has a corresponding recovery point (the time point corresponding to the recovery point is "20240101:00:00:00", and the corresponding HA DBs are each HA DB).

[0232] At "20240101:05:03:39" (line 15), DB-b 1120 becomes active, and DB-a 1110, DB-c 1130, and DB-d 1140 become standby. Since the example in Table 2B shows that the backup is performed every 6 hours, when the status of DB-a 1110 and DB-b 1120 changes, there is no corresponding recovery point between the start time of "20240101:00:00:00" (line 16) and "202401010:05:03:39" (line 15).

[0233] From time "20240101:06:00:00" to time "20240105:12:00:00" (row 14), each HA DB in the HA DB cluster was backed up 18 times, so each HA DB in the HA DB cluster (for example, DB-a 1110, DB-b1120, DB-c 1130, DB-d 1140) has 18 corresponding recovery points, and their corresponding time points are shown as the timestamps listed in the corresponding rows and columns in Table 3B. Among them, the generation interval of adjacent recovery points corresponding to the same HA DB is 6 hours. In addition, the status of each HA DB in the data of row 14 is the same as that of row 15. It should be noted that, similar to Table 2B, the example in Table 3B assumes that all HA DBs are backed up at the same time for ease of explanation.

[0234] At "20240105:12:28:05" (row 13), DB-b 1120 fails (DOWN), DB-c 1130 switches to the active terminal, and DB-a 1110 and DB-d 1140 switch to the standby state. Similarly, since the example in Table 2B shows that the backup is performed every 6 hours, from this time to the last backup time, each HA DB has no recovery point. In other words, row 13 of Table 3B only shows the state change.

[0235] From "20240105:18:00:00" to "20240108:18:00:00 (row 12), each HADB in the HA DB cluster has 13 backups, so 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 row 14, for simplicity, row 12 in Table 3B does not fully describe the list of timestamps corresponding to the 13 recovery points. In addition, the state of each HA DB in row 12 is the same as that in row 13.

[0236] In line 11, the state of the HA DB changes. After that, in line 10, each HA DB has 13 corresponding recovery points. The state of the HA DB changes again in line 9. Then in line 8, each HA DB has 6 corresponding recovery points, and so on. At "20240118:05:10:39" in line 3, DB-a 1110 fails (DOWN), DB-b 1120 switches to the active state, and DB-c 1130 and DB-d 1140 switch to the standby state. Later, in line 2, DB-a 1110 is unavailable throughout the time period from "20240118:06:00:00" to "20240118:18:00:00". Therefore, there are no recovery points 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 the status log 4010 of the HA DB cluster and the backup log 5010 of the HA DB cluster are merged into the recovery point log as shown in Table 3B, step 8008 will continue to be executed.

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

[0239] In an embodiment of the present disclosure, the setting of the initial value of the above search parameter includes:

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

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

[0242] In step 8010, the HA data recovery module 3300 starts from the above value of T and traverses backward in time in the recovery point log to determine the next candidate recovery point 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 (row 1), the timestamp corresponding to the next candidate recovery point should be "20240118:18:00:00", which is located in row 2.

[0244] It should be noted that in the second row, DB-b 1120, DB-c 1130, and DB-d 1140 each have three corresponding recovery points, where each recovery point is 6 hours apart (20240118:06:00:00, 20240118:12:00:00, and 20240118:18:00:00). Since DB-a 1110 has been shut down, there is no corresponding recovery point for DB-a 1110. Therefore, corresponding to the above timestamp "20240118:18:00:00", a total of three recovery points can be located, and these three recovery points correspond to the same timestamp, but correspond to different HA DBs.

[0245] Assuming that multiple recovery points are located in the above step 8010, and one of the recovery points is from the active HA DB (eg, DB-b 1120), in an embodiment of the present disclosure, the recovery point corresponding to the active HA DB can be selected as the above candidate recovery point.

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

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

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

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

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

[0251] As mentioned above, each recovery point corresponds to a time point and an HA DB. In the embodiment of the present disclosure, in the above step 8014, the HA data recovery module 3300 will instruct the backup system corresponding to the HA DB corresponding to 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 above 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 related 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 check the PIT data 3222 from Test-DB1.

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

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

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

[0257] As mentioned above, the above RP value includes PIT, which is a timestamp corresponding to a time point, and an HA DB. In the current example, the above RP value includes: PIT = "20240118:18:00:00", HA DB = DB-b 1120. Therefore, the above optimal recovery point refers to the historical data backed up by DB-b 1120 at the time point "20240118:18:00:00". In this way, in the above step 8044, 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 refer to the aforementioned embodiment, and will not be repeated here.

[0258] If it is determined that the PIT data in the test DB has been damaged, 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, and if so, continues to execute step 8022. If not, continues to execute 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 execute step 8022.

[0261] In step 8022, the candidate recovery point and the candidate recovery point parameters in the search parameters are updated, and the process returns to step 8014.

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

[0263] Thereafter, the 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. If the PIT data is still damaged data, the HA data recovery module 3300 will try the recovery point corresponding to DB-d 1140 at the same PIT. After testing all recovery points at the same PIT of all databases, no undamaged historical data that can be used for data failure recovery is found. The search process will jump to step 8024. As mentioned above, if undamaged historical data that can be used for data failure recovery is found, the search process will jump to the above-mentioned 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 updating of the 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 above example, after traversing all the recovery points corresponding to the HA DB at the time point "20240118:18:00:00", no undamaged data is found. In the above steps, the HA data recovery module 3300 updates the T value to "20240118:18:00:00"; the RP value is set to NULL. Then, return to step 8010. At this point, the HA data recovery module 3300 traverses other recovery points backward in the HA recovery point history log again starting from T ("20240118:18:00:00"). Continuing with the current example, the time point corresponding to the next recovery point is "20240118:12:00:00" (PIT time point), at which time point, DB-b 1120 is also an HA DB in the active state. Therefore, a new candidate recovery point may be determined, and the RP value may be 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 damaged, the best recovery point is found, and 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 best recovery point to back up the historical data backed up at the time point indicated by the best recovery point to each HA DB in the HA DB cluster to complete data failure recovery.

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

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

[0271] It can be seen that the above method can be simply summarized as follows: first, 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 closest to the search start time point, and update the candidate recovery point parameters and / or search start point parameters based on the determined candidate recovery point. Next, further determine whether the candidate recovery point is the best recovery point by determining whether the relevant historical data corresponding to the candidate recovery point is undamaged historical data. If it is the best recovery point, perform data failure recovery based on the located best recovery point; if it is not the best recovery point, perform the above backward traversal steps in a loop until the best recovery point is located.

[0272] The method described in the embodiment of the present disclosure enables users to quickly locate the best recovery point of the HA DB in the HA DB cluster and complete data failure recovery of the HA DB cluster based on the located best recovery point, wherein the best recovery point represents the backup location of historical data with the least data loss and no data damage.

[0273] Although the above Figure 6 This chapter describes the process of data failure recovery when all HA DBs have continuous historical data. Figure 8 The data failure recovery process is applied to the scenario of discrete historical data. However, the method described in the embodiment of the present disclosure can be applied to the scenario where some HA DBs in the cluster have continuous historical data backup records, while other HA DBs in the cluster have discrete historical data backup records. Specifically, in practical applications, Figure 6 The search process in the search process searches the continuous historical data backup records to locate the first best recovery point, and at the same time, uses Figure 8 The search process in searches for discrete historical data backup records to locate the second best recovery point. Then, the recovery point closest to the current time is selected from the two best recovery points as the final best recovery point.

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

[0275] Although this disclosure focuses its description on HA DBs, the same approach can be applied to any HA data system, such as an object store or a file system.

[0276] Although the accompanying drawings corresponding to the embodiments of the present disclosure show an HA DB cluster with one active node and three standby or unavailable (DOWN) nodes, the method described in the embodiments of the present disclosure is not limited to this configuration. The method described in the embodiments of the present disclosure can be applied to a cluster in which two or more data nodes in one or more data centers are deployed.

[0277] Although the above example shows two data centers, the HA DB cluster can be deployed in only one data center or in more than two data centers. Therefore, the method described in the embodiment of the present disclosure is 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 the present disclosure show two data centers and two backup systems, each of which is deployed in one of the data centers. The method described in the embodiments of the present disclosure does not require such a specific configuration. The method described in the embodiments of the present disclosure is applicable to one or more backup systems in one or more data centers. All data in the HA DB cluster can be backed up to one backup system, or each data node can be backed up to a single backup system.

[0279] As can be seen from the above examples, the data fault recovery method provided by the embodiments of the present disclosure may include: obtaining a backup log of an HA DB cluster; obtaining a 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 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 HADB; and performing data fault recovery in the HADB cluster based on the optimal recovery point.

[0280] In an embodiment of the present disclosure, the above-mentioned obtaining the backup log of each HA DB in the HA DB cluster includes: obtaining the backup log of each HA DB from the backup system corresponding to each HA DB in the HA DB cluster; generating the backup log of the HA DB cluster based on the backup log of each HA DB; and determining the target time range corresponding to the backup log of the HA DB cluster.

[0281] In an embodiment of the present disclosure, the above-mentioned acquisition of 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 notification of each HA DB; and extracting the 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 an embodiment of the present disclosure, the backup logs of the above-mentioned respective HA DBs include continuous historical data backup records; the positioning of 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, and setting the recovery point parameter to a null value, and then executing the following steps;

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

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

[0285] C. instructing 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. Prompting the user to check the PIT data in the test database, and receiving the user's verification result on the PIT data;

[0287] E. In response to determining that the PIT data is undamaged historical data based on the verification result, executing step F; in response to determining that the PIT data is damaged historical data based on the verification result, executing step G;

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

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

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

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

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

[0293] In an embodiment of the present disclosure, the above-mentioned setting of the incremental time range and the initial value of PIT includes: determining the initial value of the incremental time range based on the user's selection or a pre-set default value; and taking the difference between the current time point and the incremental time range as the initial value of the PIT.

[0294] In an embodiment of the present disclosure, the above-mentioned updating of the incremental time range, the recovery point parameters and the PIT in a pre-set first manner includes: updating the recovery point parameters to: the PIT and the HA DB that is 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 an embodiment of the present disclosure, updating the incremental time range and the PIT in a preset second manner includes: updating the incremental time range to half of the incremental time range before updating; and updating the PIT to the difference between the PIT before updating and the incremental time range after updating.

[0296] In an embodiment of the present disclosure, the above-mentioned updating of the incremental time range and the PIT in a pre-set third manner 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, updating the incremental time range 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, keeping the incremental time range unchanged; and updating the PIT to the difference between the PIT before the update and the incremental time range after the update.

[0297] In an embodiment of the present 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, using the PIT included in the 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; and in response to determining that the recovery point parameters are empty, failing to search for the optimal recovery point, and ending the data failure recovery method.

[0298] In an embodiment of the present disclosure, the backup logs of the above-mentioned respective HA DBs include recovery point logs; the 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 be 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 closest to the search start time point, and update the candidate recovery point parameter and / or the search start point parameter based on the determined candidate recovery point;

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

[0301] c. Prompting the user to check the PIT data in the test database, and receiving the user's verification result on the PIT data;

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

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

[0304] In an embodiment of the present disclosure, starting from the time point corresponding to the search start time point parameter, traversing backward in time in the recovery point log to determine the next candidate recovery point closest to the search start time point includes: starting from the time point corresponding to the search start time point parameter, determining in the recovery point log a target time point of an existing recovery point closest to the search start time point; determining the number of recovery points at the target time point that have not been selected as candidate recovery points; in response to determining that there is only one recovery point that has not been selected as a candidate recovery point, using the recovery point as the candidate recovery point; in response to determining that there are multiple recovery points that have not been selected as candidate recovery points, selecting a 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 an embodiment of the present disclosure, the above-mentioned selection of a recovery point as the candidate recovery point includes: in response to determining that the multiple recovery points that are 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 multiple recovery points that are not selected as candidate recovery points do not include a recovery point corresponding to an HA DB in an active state, selecting a recovery point corresponding to any HA DB therefrom as the candidate recovery point.

[0306] In an embodiment of the present 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, failing to search for the optimal recovery point, and terminating the data failure recovery method.

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

[0308] Accordingly, an embodiment of the present disclosure further discloses a data failure recovery device, comprising:

[0309] HADB backup monitor, used to obtain the backup log of the high availability database HA DB cluster;

[0310] A HADB status monitor, configured to obtain a status log of the HA DB cluster; and

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

[0312] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present 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 when the processor executes the program, the data failure recovery method described in any of the above embodiments is implemented.

[0313] The electronic device may include: a processor, a memory, an input / output interface, a communication interface, and a bus, wherein the processor, the memory, the input / output interface, and the communication interface are connected to each other in communication within the device via the bus.

[0314] The processor can be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an 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 device, dynamic storage device, etc. The memory can store operating systems and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory and called and executed by the processor.

[0316] The input / output interface is used to connect input / output devices to realize information input and output. Among them, the input / output device can be configured in the device as a component, or it can be externally connected to the device to provide corresponding functions. Among them, the input device can include a microphone, various sensors, etc., and the output device can include a display, a speaker, a vibrator, an indicator light, etc.

[0317] The communication interface is used to connect the communication module to realize the communication interaction between the device and other devices. The communication module can realize communication through wired mode (such as USB, network cable, etc.) or wireless mode (such as mobile network, WIFI, Bluetooth, etc.).

[0318] The bus comprises a pathway that transmits information between the various components of a device (eg, processor, memory, input / output interface, and communication interface).

[0319] It should be noted that, although the above device only shows a processor, a memory, an input / output interface, a communication interface, and a bus, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

[0320] The electronic device of the above embodiment is used to implement the corresponding data failure recovery method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0321] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present disclosure also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the data failure recovery method 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, modules of programs, 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 technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0323] The computer instructions stored in the storage medium of the above embodiments are used to enable the computer to execute the task processing method 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 illustrative and is not intended to imply that the scope of the present disclosure (including the claims) is limited to these examples. Based on the concept of the present disclosure, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present disclosure as described above, which are not provided in detail for the sake of simplicity.

[0325] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present disclosure difficult to understand, the known power / ground connections to the integrated circuit (IC) chips and other components may or may not be shown in the provided figures. In addition, the device can be shown in the form of a block diagram to avoid making the embodiments of the present disclosure difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform on which the embodiments of the present disclosure will be implemented (that is, these details should be fully within the scope of understanding of those skilled in the art). Where specific details (e.g., circuits) are set forth to describe exemplary embodiments of the present disclosure, it is apparent to those skilled in the art that the embodiments of the present disclosure can be implemented without these specific details or with changes in these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0326] Although the present disclosure has been described in conjunction with specific embodiments of the present disclosure, many replacements, 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 use the embodiments discussed.

[0327] The embodiments of the present disclosure are 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 the embodiments of the present disclosure should be included in the scope of protection of the present disclosure.

Claims

1. A data failure recovery method, comprising: Get the backup log of the high availability database 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 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; as well as Data failure recovery is performed in the HADB cluster based on the optimal recovery point.

2. The method according to claim 1, wherein: The step of obtaining the backup log of the HA DB cluster includes: Obtaining the backup log of each HA DB from the backup system corresponding to each HA DB in the HA DB cluster; Generating a backup log of the HA DB cluster based on the backup logs of each HA DB; and Determine a target time range corresponding to the backup log of the HA DB cluster.

3. The method according to claim 2, wherein: The obtaining of the status log of the HA DB cluster comprises: Based on the received status change notifications of the respective HA DBs, updating the status log record table of the respective HA DBs; and The records within the target time range are extracted from the status log record table of each HA DB as the status log of the HADB cluster.

4. The method according to claim 1, wherein: The backup log of each HA DB includes continuous historical data backup records; The positioning of the best recovery point based on the historical data backup log of the HA DB cluster includes: Set the initial values ​​of the incremental time range and search time parameters PIT, and set the recovery point parameter to a null value, and then perform the following steps; A. In response to determining that the incremental time range is less than a preset time threshold, executing step X; or, in response to determining that the incremental time range is greater than or equal to the preset time threshold, executing step B; B. Determine the HA DB that is in the active state at the time point corresponding to the PIT, and use it as the target HA DB; C. instructing 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. Prompting the user to check the PIT data in the test database, and receiving the user's verification result on the PIT data; E. In response to determining that the PIT data is undamaged historical data based on the verification result, executing step F; or, in response to determining that the PIT data is damaged historical data based on the verification result, executing step G; F. Update the incremental time range, the recovery point parameter and the PIT according to a preset first method, and then return to step A; G. In response to determining that the recovery point parameter is not a null value, executing step H; or, in response to determining that the recovery point parameter is a null value, executing step I; H. Update the incremental time range and the PIT according to a preset second method, and then return to step A; I. Update the incremental time range and the PIT according to a preset third method, and then return to step A; and X. Determine an optimal recovery point based on the recovery point parameters.

5. The method according to claim 4, wherein: The steps of setting the incremental time range and the initial value of PIT include: Determining an initial value of the incremental time range based on the user's selection or a preset default value; and The difference between the current time point and the incremental time range is used as the initial value of the PIT.

6. The method according to claim 4, wherein: The updating of the incremental time range, the recovery point parameter and the PIT in a predetermined first manner comprises: Updating the recovery point parameter to the PIT and the HADB in the active state at the time point corresponding to the PIT; updating the incremental time range to half of the incremental time range before updating; and The PIT is updated to be the sum of the PIT before the update and the incremental time range after the update.

7. The method according to claim 4, wherein: The updating of the incremental time range and the PIT according to a preset second manner includes: updating the incremental time range to half of the incremental time range before updating; and The PIT is updated to be the difference between the PIT before the update and the incremental time range after the update.

8. The method according to claim 4, wherein: The updating of the incremental time range and the PIT according to a preset third manner 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, updating the incremental time range 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, maintaining the incremental time range unchanged; and The PIT is updated to be the difference between the PIT before the update and the incremental time range after the update.

9. The method according to claim 4, wherein: Determining the optimal recovery point based on the recovery point parameters comprises: In response to determining that the recovery point parameter is not empty, taking the PIT included in the recovery point parameter as the time point corresponding to the optimal recovery point; and taking the HA DB included in the recovery point parameter as the HA DB corresponding to the optimal recovery point; or, In response to determining that the recovery point parameter is empty, the best recovery point is not searched, and the data failure recovery method is terminated.

10. The method according to claim 1, wherein: The backup logs of each HA DB include recovery point logs; The positioning of the best recovery point based on the historical data backup log of the HA DB cluster includes: Set the initial value of the search start time point parameter to the current time point, and set the initial value of the candidate recovery point parameter 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 closest to the search start time point, and update the candidate recovery point parameters and the search start point parameters based on the determined candidate recovery point; b. instructing the backup system to export data related to the candidate recovery point as PIT data to the test database; c. Prompting the user to check the PIT data in the test database, and receiving the user's verification result on the PIT data; d. In response to determining that the PIT data is uncorrupted historical data based on the verification result, executing step x; or, in response to determining that the PIT data is corrupted historical data based on the verification result, executing step a; and x. Determine an optimal recovery point based on the recovery point parameters.

11. The method according to claim 10, wherein: Starting from the time point corresponding to the search start time point parameter, traversing backward in time in the recovery point log to determine the next candidate recovery point closest to the search start time point includes: Starting from the time point corresponding to the search start time point parameter, determining in the recovery point log a target time point of an existing recovery point closest to the search start time point; Determining the number of recovery points at the target time point that are not selected as candidate recovery points; In response to determining that there is only one recovery point that has not been selected as a candidate recovery point, selecting the recovery point as the candidate recovery point; or, in response to determining that there are multiple recovery points that have not been selected as candidate recovery points, selecting a recovery point as the candidate recovery point; and The search start time point and the time point corresponding to the candidate recovery point parameter are updated based on the time point corresponding to the recovery point, and the HA DB corresponding to the candidate recovery point parameter is updated based on the HA DB corresponding to the recovery point.

12. The method according to claim 11, wherein: The selecting a recovery point as the candidate recovery point comprises: In response to determining that the recovery points that are not selected as candidate recovery points include the recovery point corresponding to the HA DB in the active state, selecting the recovery point corresponding to the HA DB in the active state as the candidate recovery point; or, In response to determining that the recovery points that are not selected as candidate recovery points do not include a recovery point corresponding to an HA DB in an active state, a recovery point corresponding to any HA DB is selected as the candidate recovery point.

13. The method according to claim 10, wherein: Determining the optimal recovery point based on the recovery point parameters comprises: In response to determining that the candidate recovery point parameter is not empty, taking the timestamp included in the candidate recovery point parameter as the time point corresponding to the optimal recovery point; and taking the HA DB included in the recovery point parameter as the HA DB corresponding to the optimal recovery point; or, In response to determining that the recovery point parameter is empty, the best recovery point is not searched, and the data failure recovery method is terminated.

14. The method according to claim 1, wherein: The performing of data failure recovery in the HA DB cluster based on the optimal recovery point includes: Based on the time point corresponding to the optimal recovery point and the HA DB instructing the backup system to extract the historical data backed up by the HA DB at the time point; and The extracted historical data is copied to each HA DB in the HA DB cluster.

15. A data failure recovery device, comprising: HA DB backup monitor, used to obtain the backup log of the high availability database HA DB cluster; HADB status monitor, used to obtain the status log of the HA DB cluster; as well as The HA data recovery module is used to merge the backup log of the HA DB cluster and the status log of the HA DB cluster to generate a historical data backup log of the HA DB cluster; locate the best recovery point based on the historical data backup log of the HA DB cluster; wherein the best recovery point corresponds to a time point and an HA DB; and perform data failure recovery in the HA DB cluster based on the best recovery point.

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

17. A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the data failure recovery method according to any one of claims 1 to 14.

18. A computer program product, comprising computer program instructions, which, when executed on a computer, enable the computer to execute the data failure recovery method according to any one of claims 1 to 14.

Images