Database backup optimization method and device, equipment, storage medium and program product

Abstract

The invention discloses a database backup optimization method and device, equipment, a storage medium and a program product, and the method comprises the steps: determining a backup task as a backup failure task if a failure alarm occurs in the backup task in a cloud database; the backup failure task is within a preset backup time interval; analyzing the backup failure task to obtain a backup failure reason; based on the backup failure reason, determining a solution corresponding to the backup failure reason; and optimizing the backup process of the backup task based on the solution.

Description

Technical Field

[0001] The present application relates to the field of cloud computing and big data, and in particular to a database backup optimization method, device, equipment, storage medium and program product. Background Art

[0002] In the current information society, data has become an important asset in all industries. Therefore, protecting data and preventing it from being illegally tampered with, deleted or leaked is an important task that must be faced. Backing up the database is an effective means to protect data security while preventing data loss. However, the database backup method provided in the relevant technology relies on the processing experience of the operation and maintenance personnel in the event of backup anomalies, and the time and labor costs are high, resulting in limitations in improving the backup success rate. Summary of the invention

[0003] In order to solve the above technical problems, the embodiments of the present invention provide a database backup optimization method, device, equipment, storage medium and program product.

[0004] The database backup optimization method provided in the embodiment of the present application includes:

[0005] If a backup task in the cloud database has a failure alarm, the backup task is determined to be a failed backup task; and the failed backup task is within a preset backup time interval;

[0006] Analyze the failed backup task to obtain the reason for the backup failure;

[0007] Based on the backup failure reason, determining a solution corresponding to the backup failure reason;

[0008] Based on the solution, the backup process of the backup task is optimized.

[0009] The database backup optimization device provided in the embodiment of the present application includes:

[0010] A determination unit, configured to determine that a backup task in a cloud database is a failed backup task if a failure alarm occurs in the backup task; and the failed backup task is within a preset backup time interval;

[0011] An analysis unit, used to analyze the failed backup task to obtain the reason for the backup failure;

[0012] The determining unit is further configured to determine a solution corresponding to the backup failure cause based on the backup failure cause;

[0013] An optimization unit is used to optimize the backup process of the backup task based on the solution.

[0014] The processing device provided in the embodiment of the present application includes: a processor and a memory, the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute any one of the above-mentioned database backup optimization methods.

[0015] The computer-readable storage medium provided in the embodiment of the present application is used to store a computer program, and the computer program enables a computer to execute any one of the above-mentioned database backup optimization methods.

[0016] The computer program product provided in the embodiment of the present application includes computer program instructions, which enable a computer to execute any one of the above-mentioned database backup optimization methods.

[0017] In the technical solution of the embodiment of the present application, if a failure alarm occurs in a backup task in a cloud database, the backup task is determined to be a backup failure task, and the backup failure task is analyzed to obtain the backup failure cause. Based on the backup failure cause, a solution corresponding to the backup failure cause is determined, and based on the solution, the backup process of the backup task is optimized; wherein the backup failure task is within a preset backup time interval. In this way, in the case of a backup task failure, by adding a detection step for the backup failure cause, unnecessary backup retries can be reduced, and time and labor costs can be reduced. In addition, by arranging solutions corresponding to different backup failure causes, the detection and self-healing functions of the backup failure cause can be iteratively optimized, thereby optimizing the backup process of the backup task and improving the overall success rate of cloud database backup. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a flowchart of a database backup optimization method provided in an embodiment of the present application;

[0019] Figure 2 It is a flowchart of a backup optimization method for improving the backup reliability of a cloud database provided in an embodiment of the present application;

[0020] Figure 3 It is a flowchart of a backup failure cause detection method provided in an embodiment of the present application;

[0021] Figure 4 It is a flow chart of a method for detecting sub-health causes in a standby database instance provided in an embodiment of the present application;

[0022] Figure 5 It is a flowchart of a method for performing a corresponding self-healing operation according to a standby database instance type provided in an embodiment of the present application;

[0023] Figure 6 It is a flow chart of a method for detecting and self-healing the cause of iterative optimization backup failure provided in an embodiment of the present application;

[0024] Figure 7 It is a structural diagram of a database backup optimization device provided in an embodiment of the present application;

[0025] Figure 8 It is a schematic diagram of the structure of the processing device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0026] The following will describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0027] In the description of the embodiments of the present application, the term "corresponding" may indicate a direct or indirect correspondence between two items, or an association relationship between the two items, or a relationship between indication and being indicated, configuration and being configured, and the like.

[0028] To facilitate understanding of the technical solutions of the embodiments of the present application, the relevant technologies of the embodiments of the present application are described below. The following related technologies can be arbitrarily combined with the technical solutions of the embodiments of the present application as optional solutions, and they all belong to the protection scope of the embodiments of the present application.

[0029] In the current information society, data has become an important asset in all industries. Therefore, protecting data and preventing it from being illegally tampered with, deleted or leaked is an important task that must be faced at present. Backing up the database is an effective means to protect data security while preventing data loss. At present, the backup of traditional databases is generally performed by setting a scheduled task, calling the corresponding script on the operating system on a weekly or monthly basis to perform the backup task. Among them, for containerized database instances and cloud database MySQL clusters of tens of thousands, improving the backup success of cloud databases requires backup error checking and using automated means to improve backup reliability. Based on this, in the cloud database backup and recovery method provided by the relevant technology, the instance of the cloud database runs in the form of a POD instance in Kubernetes, and resources are scheduled through Kubernetes orchestration. The scheduled task (crone job) of Kubernetes is called multiple times to improve the backup success rate.

[0030] However, the multiple calls method has limitations on the backup success rate of cloud databases, especially when the backup space is insufficient, the backup instance is in a sub-healthy state, or the database parameter settings are abnormal. Retrying the backup multiple times does not increase the backup success rate, but will waste additional system resources (generating crone job containers multiple times). In addition, in the absence of a self-healing function, handling backup failures requires manual logging into the Kubernetes cluster and manually determining the cause of the backup failure. If it is due to an abnormality in the backup instance, it is necessary to manually repair the abnormal instance and then manually call the backup task again to perform a re-backup. However, with the increase in instances in the Kubernetes cluster, it becomes increasingly difficult to manually handle database backup failures.

[0031] In summary, although the database backup and recovery method provided by the relevant technology can improve the database backup success rate by calling cronejob multiple times, the detection of the cause of backup failure depends on the operation and maintenance personnel's familiarity with the relevant components and resources of cloud database backup. For example, insufficient space allocated by the cloud database, occasional performance problems of the storage cluster leading to backup abnormalities, and occasional fluctuations in the network all have a certain impact on the database backup success rate. The specific problems include the following:

[0032] (1) When the backup space is insufficient, no matter how many times the backup task is called again, the backup will still fail, thus wasting backup-related resources.

[0033] (2) During the backup process, if the backup database (such as MySQL Slave) is in an unhealthy state and there are exceptions in the backup database synchronization, the backup task will not succeed even if it is called multiple times; and if there is a master-slave delay in the backup database, the success rate of calling the backup task multiple times is not high.

[0034] (3) As the number of database instances in the Kubernetes cluster increases, the number of abnormal backup instances that can be manually handled within the backup time interval set by the customer is extremely limited, and manual intervention takes a long time.

[0035] (4) If the customer does not set the database parameters properly, multiple calls to the backup task will not succeed. For example, if the customer does not enable the innodb log file size (innodb_log_file_size) and binary log (binlog) parameter settings, incremental physical backup will not be possible. In addition, which specific parameter affects the failure of the cloud database instance backup depends on the operation and maintenance personnel's experience.

[0036] In order to solve the above technical problems, the present application proposes a backup optimization method for improving the reliability of cloud database backup. By increasing the detection and self-healing process of backup failure causes, the number of instances requiring manual intervention is reduced to an acceptable range, thereby reducing time costs and labor costs, and reducing unnecessary backup retries; and, by arranging solutions corresponding to different backup failure causes, the detection and self-healing functions of backup failure causes are iteratively optimized, thereby optimizing the backup process of the backup task, which can improve the overall success rate of cloud database backup.

[0037] To facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions of the present application are described in detail below through specific embodiments. The above related technologies can be combined arbitrarily with the technical solutions of the embodiments of the present application as optional solutions, and they all belong to the protection scope of the embodiments of the present application. The embodiments of the present application include at least part of the following contents.

[0038] The present application embodiment proposes a database backup optimization method. Figure 1 is a flow chart of the database backup optimization method provided in the embodiment of the present application, such as Figure 1 As shown, the method comprises the following steps:

[0039] Step 101: If a failure alarm occurs in a backup task in the cloud database, the backup task is determined to be a backup failure task.

[0040] In an embodiment of the present application, the instance of the cloud database runs in the form of a POD instance in Kubernetes. Each POD instance in the Kubernetes cluster will set a corresponding backup task at a relatively less busy time according to the user's business characteristics and status. At the corresponding time, the scheduled task function of Kubernetes starts and calls the backup task of the corresponding instance. After the backup task in the cloud database starts to execute, the backup result of the backup task is judged. If it is judged that the backup task has a failure alarm, the backup task is determined to be a backup failure task. At the same time, if it is judged that the backup failure task is within the preset backup time interval, the backup failure task continues to be analyzed for the reason of the backup failure. Among them, the preset backup time interval is the time interval or time period for data backup in the cloud database. Its specific size is set according to different business characteristics and status, and it is not limited here.

[0041] Here, if it is determined that the backup failure task is not within the preset backup time interval, a backup exception work order is directly generated and sent to the operation and maintenance personnel, so that the operation and maintenance personnel can manually analyze the cause of the backup failure. After obtaining a clear cause of failure, the relevant information is added to the exception list (Exception List) to join the subsequent failure cause detection process and consider the feasibility of self-healing.

[0042] Step 102: Analyze the failed backup task to obtain the reason for the backup failure.

[0043] In the embodiment of the present application, after determining the failed backup tasks within the preset backup time interval, the failed backup tasks can be analyzed. Specifically, the log information related to the failed backup tasks is analyzed to extract the target keyword, and the content corresponding to the target keyword is determined as the cause of the backup failure. Among them, the log information of the failed backup tasks usually contains keywords such as "ERROR" or "failed", and the specific content corresponding to these keywords can be used to find the cause of the backup failure.

[0044] It should be noted that if the backup fails after multiple retries, the number of failures will be recorded in the log information. For example, if the backup fails after 3 retries, the log information will have a record of "Backup retry failed 3times".

[0045] In some implementations, step 102 may specifically include:

[0046] Get log information related to failed backup tasks;

[0047] Match the keywords in the log information with the preset keywords to obtain the target keywords;

[0048] Based on the target keywords, determine the cause of backup failure.

[0049] Here, you can query the log file of the backup task to obtain the log information related to the failed backup task. Specifically, you can use the query statement to check the status of the backup task. If the backup task status is displayed as failed, you can query the view to obtain the log file of the backup task, and then retrieve the detailed error information (log information) of the failed backup task in the corresponding log file. After obtaining the log information of the failed backup task, you can write a script or use a log analysis tool to match the keywords in the log information with the preset keywords in the Exception List to obtain the target keyword. The content corresponding to the target keyword is the backup failure reason of the failed backup task. Among them, the Exception List includes common error codes, error messages, descriptions of abnormal behaviors, etc.

[0050] It should be noted that if the keywords in the log information do not match the preset keywords in the Exception List, the log information can be preprocessed to remove irrelevant information and retain key error information, or the log information can be further analyzed, or the Exception List can be updated to include new error type information.

[0051] Step 103: Based on the backup failure reason, determine a solution corresponding to the backup failure reason.

[0052] Step 104: Based on the solution, the backup process of the backup task is optimized.

[0053] In the embodiment of the present application, since the failed backup task is caused by the occurrence of different abnormal conditions, such as insufficient backup space, unreasonable database parameter settings, abnormal database storage connection, etc., in order to speed up the investigation of the cause of the backup failure, after obtaining the backup failure cause of the failed backup task, the corresponding solution can be determined according to the different categories of failure causes in the backup failure cause, so that the backup process of the backup task can be optimized and managed based on different solutions. In this way, by distinguishing the reasons for backup failure, invalid backup resource calls can be reduced, time costs can be saved, and the reliability and success rate of data backup can be improved by optimizing the backup process through different solutions.

[0054] In some implementations, step 103 may specifically include:

[0055] If it is determined that the cause of the backup failure is caused by an abnormal condition occurring in the cloud database, the cause of the backup failure is classified to obtain different categories of failure causes; based on the different categories of failure causes, solutions corresponding to the different categories of failure causes are determined.

[0056] Here, the reasons for backup failure can be divided into user-side reasons and cloud-side reasons. If it is determined that the reason for backup failure is caused by abnormal operation of the user (user-side reason), such as insufficient backup space set by the user, unreasonable database parameters set by the user, etc., the analysis process of the failed backup task will be directly ended, and the reason for backup failure will be sent to the user, such as outputting the reason code of abnormal backup to the monitoring center to remind the user the next day so that the user can make corresponding adjustments to the backup space or database parameters according to the reason for backup failure.

[0057] If it is determined that the cause of the backup failure is caused by an abnormal condition in the cloud database (cloud-side reason), the reasons for the backup failure are further classified and divided into network reasons, backup database reasons, and backup task reasons, thereby obtaining different categories of failure reasons. Based on the different categories of failure reasons, the corresponding solutions can be determined in a targeted manner, so that the backup process can be optimized and managed through the corresponding solutions.

[0058] In some implementations, the multiple categories of failure reasons include one or more of the following: the standby database is in a sub-healthy state, the connectivity of the storage cluster is abnormal, and the resources of the backup task are abnormal; wherein, for the failure reasons based on different categories, determining solutions corresponding to the failure reasons of different categories may specifically include:

[0059] If it is determined that the connectivity of the storage cluster is abnormal or the resources of the backup task are abnormal, delete the failed backup task and call a new backup task; or,

[0060] If it is determined that the standby warehouse is in a sub-healthy state, the sub-healthy causes of the standby warehouse are classified to obtain different categories of sub-healthy causes; based on the different categories of sub-healthy causes, solutions corresponding to the different categories of sub-healthy causes are determined.

[0061] Here, if it is determined that the reason for the backup failure is due to network reasons or backup task reasons, that is, the connectivity of the storage cluster is abnormal or the resources of the backup task are abnormal, indicating that the nodes in the storage cluster cannot communicate normally or a resource abnormality occurs during the execution of the backup task, the failed backup task is deleted, and it is determined whether the current time is within the preset backup time interval. If so, a new backup task is re-called within the preset backup time interval, otherwise the analysis process is terminated directly. For example, unstable network connection, incorrect IP address and port settings, firewalls or security policies blocking communication, etc. may all lead to abnormal connectivity of the storage cluster, and insufficient resources, failed resource creation, and failure to find a scheduling node may all cause the backup task to get stuck, resulting in abnormal resources of the backup task.

[0062] Among them, determining whether the connectivity of the storage cluster is abnormal can be determined through keywords related to "ping" in the log information of the failed backup task, and determining whether the resources of the backup task are abnormal can be determined through keywords such as "scheduling error", "scheduling failure", and "abnormal resource status" in the log information of the failed backup task.

[0063] If it is determined that the backup task is caused by the standby database, that is, the standby database is in a sub-healthy state, the sub-healthy reasons of the standby database are further classified and divided into delay reasons and abnormal status reasons, thereby obtaining different categories of sub-healthy reasons. Based on different categories of sub-healthy reasons, corresponding solutions can be determined in a targeted manner, so that the sub-healthy state of the standby database can be restored through the corresponding solutions.

[0064] The determination that the standby database is in a sub-healthy state may be determined by the keyword "cannot find an available backup database" in the log information of the failed backup task.

[0065] In some implementations, the sub-health reasons of the standby database include one or more of the following: data synchronization of the standby database is delayed, and the data synchronization state of the standby database is abnormal; wherein, for sub-health reasons based on different categories, determining solutions corresponding to different categories of sub-health reasons may specifically include:

[0066] If it is determined that there is a delay in data synchronization of the standby database, query the status of the standby database; determine the delay time of the standby database based on the status of the standby database, and if it is determined that the time point corresponding to the delay time is reached, delete the failed backup task and call a new backup task; or,

[0067] The delay time of the backup database is determined based on the preset strategy. When the time point corresponding to the delay time is determined to be reached, the failed backup task is deleted and a new backup task is called.

[0068] Here, if it is determined that the reason for the sub-health of the backup database is the delay, that is, there is a delay in the data synchronization of the backup database, then it is necessary to wait for the delay to disappear, wherein the delay time of the backup database can be determined, and after waiting for the length of the delay time, the failed backup task can be deleted, and a new backup task can be called again within the preset backup time interval. Specifically, to determine the delay time of the backup database, the status of the backup database can be directly queried through the command "SHOW SLAVE STATUS" to determine the delay time of the backup database, and in the case of a large delay in the backup database, the delay time of the backup database can also be determined based on the preset strategy, so that the delay time of the backup database can be viewed at the estimated time point to avoid blindly and frequently querying the status of the backup database and save system resource overhead.

[0069] In some implementations, determining the delay time of the standby database based on a preset strategy may specifically include:

[0070] Within a preset number of iterations, the delay time of the standby database is collected based on a preset interval time to obtain a sampling time series and a delay time series of the standby database;

[0071] The sampling time series and the delay time series are fitted based on a preset function to obtain a fitting function; and the delay time corresponding to the backup database at the estimated time point is predicted based on the fitting function.

[0072] Here, the delay time of the standby database is determined based on a preset strategy, that is, the delay situation of the standby database is fitted by a preset function to obtain a fitting function, and then the delay time of the standby database corresponding to the estimated time point is determined based on the fitting function.

[0073] Specifically, within a preset number of iterations, the delay time of the backup warehouse is collected based on a preset interval time, and the time of each collection is recorded, wherein the interval time of each collection is determined according to the delay time of the backup warehouse currently collected, if the delay time of the backup warehouse currently collected is greater than or equal to the delay time of the backup warehouse collected last time, then the interval time of the next collection increases to a preset multiple of the interval time of the previous collection, otherwise the interval time of the next collection continues to use the interval time of the previous collection, and so on. After the preset number of iterations, the corresponding sampling time series and delay time series can be obtained; after obtaining the sampling time series and the delay time series, the sampling time series and the delay time series can be fitted based on a preset function (such as a linear function) to obtain a determination coefficient (such as the slope and intercept in the linear function), and the corresponding fitting function is determined based on the determination coefficient, so that the delay time corresponding to the backup warehouse at the estimated time point can be predicted by the fitting function.

[0074] For example, if the preset function is a linear function, its expression is y=kx+b, where k and b are unknown slope and intercept, x is the sampling time, and y is the delay time. Then the sampling time series and the delay time series can be input into the expression, and the sampling time series and the delay time series can be fitted based on the expression to obtain k and b in the expression, so that the corresponding fitting function can be obtained based on k and b, and the delay time corresponding to the estimated time point can be determined according to the fitting function.

[0075] In some implementations, if it is determined that the data synchronization state of the standby database is abnormal, the types of standby databases are classified to obtain different types of standby databases; based on the different types of standby databases, self-healing processes corresponding to the different types of standby databases are determined.

[0076] Here, if it is determined that the reason for the sub-health of the standby database is the abnormal status, that is, the data synchronization status of the standby database is abnormal, the disk type used by the cloud database can be classified into cloud disk type and local disk type. Among them, the disk used by the cloud database is the standby database, and the disk type is the standby database type. Since different types of standby databases have different corresponding processing methods, the self-healing processes corresponding to different types of standby databases can be determined based on different types of standby databases.

[0077] Here, the database whose disk is a cloud disk stores data through the Simple Storage Service (S3), and the database whose disk is a local disk stores data through the Node node. In addition, the database whose disk is a cloud disk can usually restore the standby database to a healthy state by restarting, while the database whose disk is a local disk usually requires an automatic reconstruction of the master and slave to restore the standby database to normal.

[0078] In some implementations, different types of standby repositories include one or more of the following: a cloud disk, a local disk; wherein, for different types of standby repositories, determining the self-healing process corresponding to the different types of standby repositories may specifically include:

[0079] Restart the standby database and determine whether the data synchronization status of the standby database after the restart is restored to normal: If the data synchronization status of the standby database after the restart is restored to normal, delete the failed backup task and call a new backup task; or,

[0080] If the backup database is determined to be a cloud disk, and the data synchronization status of the restarted backup database has not returned to normal, determine the corresponding self-healing process based on different abnormal reasons; or,

[0081] If the backup database is determined to be a local disk, and the data synchronization status of the backup database has not returned to normal after the restart, rebuild the backup database and perform the master-slave synchronization operation.

[0082] Here, regardless of whether the backup database is a cloud disk or a local disk, you can first restart the backup database and determine whether the data synchronization status of the backup database after the restart has returned to normal. For example, you can use specific commands or monitoring tools to determine whether the master-slave synchronization status has returned to normal. If the data synchronization status of the backup database after the restart has returned to normal, delete the failed backup task and call a new backup task again within the preset backup time interval.

[0083] If the backup database is determined to be a cloud disk, and the data synchronization status of the backup database after restart has not returned to normal, the reasons for the abnormal status are further classified to obtain different abnormal reasons, and the corresponding self-healing process is determined based on different abnormal reasons. For example, it can be determined whether the backup database is still mounted on the Node node before the restart after the restart. If so, the backup database can be remounted to the new Node node through specific commands or tools to maintain master-slave synchronization, or it can be determined whether the image file version of the cloud database is too low. If so, the image file version can be upgraded by patching.

[0084] If it is determined that the backup database is a local disk, and the data synchronization status of the restarted backup database has not returned to normal, the corresponding self-healing process can be entered, that is, rebuilding the backup database and performing master-slave synchronization operations. Specifically, if the persistent storage volume (Persistent Volume Claim, PVC) of the local disk is deleted and the ordered set (StatefulSet, STS) is restarted, the restorer container will trigger the rebuilding of the backup database and the master-slave synchronization operation; before rebuilding the backup database, the data volume of the backup database can be calculated, and the data volume of the preset size (for example, 10G) can be restored per minute as a benchmark to determine whether it can be successfully restored within the preset backup time interval. If it can be successfully restored, the backup database is directly rebuilt and master-slave synchronization is performed; if it cannot be successfully restored within the preset backup time interval, the lost global transaction identifier (GlobalTransaction ID, GTID) is analyzed to see if it is a transaction that updates the heartbeat table. If so, such transactions are gradually skipped, and the backup database replication process (START SLAVE) is started, and then the synchronization process is started.

[0085] Here, if the above two types of backup database self-healing are successful, the failed backup task will be deleted and a new backup task will be called again within the preset backup time interval; if the self-healing fails, the failed backup task will be output to the alarm center for manual analysis by the operation and maintenance personnel.

[0086] It should be noted that for scenarios that are not covered, operation and maintenance personnel are required to conduct manual analysis and then incorporate them into the self-healing process, so as to iteratively optimize the self-healing function of the backup database.

[0087] In some embodiments, after calling a new backup task, during the backup process of the new backup task, if it is determined that the new backup task has a failure alarm, new log information corresponding to the new backup task is obtained; the new backup task is within a preset backup time interval; the new log information is sent to the operation and maintenance personnel, so that the operation and maintenance personnel can iteratively optimize the detection of the cause of the backup failure and the self-healing process based on the new log information.

[0088] Here, after the backup database self-heals successfully and the new backup task is re-called, if the new backup task still fails to complete the backup successfully within the preset backup time interval, manual intervention is required to analyze the specific failure cause in order to iteratively optimize the detection and self-healing functions of the backup failure cause. Specifically, when a failure alarm occurs in the new backup task, the new log information corresponding to the new backup task is obtained, wherein the new log information includes the error log information of the failure of the new backup task, and the error log information is sent to the operation and maintenance personnel for the operation and maintenance personnel to analyze the cause of the backup failure.

[0089] Specifically, if the operation and maintenance personnel determine that the reason for the failure of the new backup task is unreasonable database parameter settings, the failure reason is added to the unreasonable parameter setting judgment list, the failure reason is sent to the user, and the analysis process is terminated; if the operation and maintenance personnel determine that the failure reason of the new backup task is that the standby database is in a sub-healthy state, it is further determined whether there is a delay in the standby database. If so, it means that the backup time interval set by the user is unreasonable. The failure reason is sent to the user and the analysis process is terminated. Otherwise, the sub-health reason of the standby database continues to be investigated. If a new sub-health reason arises that causes the new backup task to fail, the sub-health reason is included in the self-healing scenario to iteratively optimize the self-healing function of the standby database.

[0090] It should be noted that after the error log information of the new backup task failure is sent to the operation and maintenance personnel, the operation and maintenance personnel will add the error log information to the Exception List to update the error type information.

[0091] In the technical solution of the embodiment of the present application, if a failure alarm occurs in a backup task in a cloud database, the backup task is determined to be a backup failure task, and the backup failure task is analyzed to obtain the backup failure cause. Based on the backup failure cause, a solution corresponding to the backup failure cause is determined, and based on the solution, the backup process of the backup task is optimized; wherein the backup failure task is within a preset backup time interval. In this way, in the case of a backup task failure, by adding a detection step for the backup failure cause, unnecessary backup retries can be reduced, and time and labor costs can be reduced. In addition, by arranging solutions corresponding to different backup failure causes, the detection and self-healing functions of the backup failure cause can be iteratively optimized, thereby optimizing the backup process of the backup task and improving the overall success rate of cloud database backup.

[0092] The present application also proposes a backup optimization method for improving the reliability of cloud database backup. Figure 2 is a flowchart of a backup optimization method for improving the reliability of cloud database backup provided by an embodiment of the present application, such as Figure 2 As shown, the method comprises the following steps:

[0093] Step 201: Start the backup task.

[0094] Here, each instance in the Kubernetes cluster will set up corresponding backups during relatively less business hours according to the customer's business characteristics and status. At the corresponding time, the scheduled task function in Kubernetes will start calling the backup function of the corresponding instance.

[0095] Step 202: Determine the backup result of the backup task. If the backup task is successful, proceed to step 216; otherwise, proceed to step 203.

[0096] Step 203: Determine that the backup task is a backup failure task, and issue a failure alarm.

[0097] Step 204: Determine the backup time interval of the failed backup task. If the backup time interval exceeds the backup time interval set by the customer, proceed to step 205; otherwise, proceed to step 206.

[0098] Step 205: Send a backup exception work order to the operation and maintenance personnel.

[0099] Here, if the backup failure task exceeds the backup time interval set by the customer, the backup exception work order will be directly sent to the operation and maintenance personnel for manual analysis of the cause of the backup failure. The cause will be manually investigated based on the log information of the backup failure task, and the relevant information will be added to the Exception List, added to the next round of failure cause judgment process and consider the feasibility of self-healing.

[0100] Step 206: Retrieve the backup log of the failed backup task.

[0101] Step 207: Determine the backup failure reason of the failed backup task according to the backup log.

[0102] Here, if the failed backup task does not exceed the backup time interval set by the customer, the backup log of the failed backup task is retrieved, and the cause of the log information in the backup log is analyzed. Specifically, the keywords in the log information are matched with the preset keywords in the Exception List to determine the target keywords, and the cause of the backup failure is determined based on the content corresponding to the target keywords. Among them, the components and products involved in the backup will have specific keywords when an exception occurs. For example, unreasonable parameter settings will return MYSQL errors, storage connection exceptions will return S3 storage exceptions, and backup task exceptions will return resource exceptions in Kubernetes (scheduling nodes not found, etc.).

[0103] In order to speed up the investigation of the cause of backup failure, the causes of backup failure can be classified to obtain different categories of failure causes, and corresponding solutions can be determined according to the different categories of failure causes.

[0104] in, Figure 3 is a flowchart of a backup failure cause detection method provided in an embodiment of the present application, such as Figure 3 As shown, the method comprises the following steps:

[0105] Step S301: Add the resources that failed to be backed up to the analysis list in resource pool units. The result status of the cron job container can be used to determine whether the backup task is successful. ERROR means that the cloud database backup failed.

[0106] Step S302: Retrieve the log information in the crone job container and perform cause analysis, that is, match the preset keywords in the Exception List with the keywords in the log information, determine the corresponding backup failure cause based on the matching result, and perform different operation processes based on different backup failure causes.

[0107] Step S303: When the backup fails due to abnormal operation of the customer, the reason code of the backup exception or the reason for the backup failure is output; when there are occasional connectivity problems in the network, occasional performance problems in the storage cluster, and occasional exceptions in the backup task itself, the crone job container of the failed backup generated in the Kubernetes cluster is deleted, and a new backup task is regenerated within the set backup time interval; when the standby database instance is sub-healthy, if the standby database instance only has a delay, skip this round of detection until the delay disappears. If the data synchronization status of the standby database is abnormal, enter the self-healing process of the standby database.

[0108] Step 208: If the reason for the backup failure is that the backup space set by the customer is insufficient or the set parameters are unreasonable, then go to step 216 and send the reason for the backup failure to the customer.

[0109] Here, if the backup failure is caused by abnormal operation of the customer, such as insufficient backup space set by the customer, unreasonable database parameters set by the customer, such as binlog not being enabled or unreasonable innodb_log_file_size setting, etc., the backup process can be terminated directly and the reason for the backup failure can be sent to the customer, or the reason code for the backup abnormality can be output to the monitoring center and the customer can be reminded so that the customer can make corresponding adjustments to the backup space or database parameters according to the reason for the backup failure.

[0110] Step 209: If the backup failure is caused by the standby database instance being in a sub-healthy state, proceed to step 210.

[0111] Step 210: Determine the reason why the standby database instance is sub-healthy.

[0112] Step 211: If the reason for the sub-health is that the backup database is delayed due to customer business, wait until the delay of the backup database disappears and then proceed to step 214.

[0113] Here, if the reason for the backup failure is that the backup instance is sub-healthy, the reasons for the sub-health are classified. If the reason for the sub-health is that the backup instance has a delay (master-slave delay), the status of the backup is queried, and the delay time of the backup instance is determined by the status of the backup, or the delay time of the backup instance is estimated based on the preset strategy. After waiting for the delay to disappear, that is, when the time point corresponding to the delay time is reached, the backup task is called again. Among them, before calling the backup task again, it is necessary to delete the backup resource container that failed to be backed up, and delete the instance in the backup exception list.

[0114] in, Figure 4 is a flow chart of a method for detecting sub-health causes in a standby database instance provided in an embodiment of the present application, such as Figure 4 As shown, the method comprises the following steps:

[0115] Step S401: determine whether the backup database instance is in a sub-healthy state through the keyword "could not find backupinstance" in the log information in the crone job container.

[0116] Step S402: Check the status of the standby database through the command "SHOW SLAVE STATUS". If there is a delay in the standby database instance, skip this round of detection and determine the delay time of the standby database instance according to the status of the standby database or the preset strategy until the delay disappears; if the data synchronization status (master-slave status) of the standby database is abnormal, directly enter the self-healing process of the standby database.

[0117] Step S403: Delete the crone job container that failed to back up, delete the instance in the backup exception list (Backup ExceptionList), and then call the crone job to regenerate the backup resources.

[0118] Among them, determining the delay time of the standby database instance according to the preset strategy can avoid frequent automatic detection of whether there is a delay state when a particularly large delay occurs. Specifically, a linear function can be used to fit the delay time of the standby database instance. First, the delay time of the first collection of the standby database instance is recorded as n1, and 30 seconds later, the delay time of the second collection of the standby database instance is recorded as n2. If n2≥n1, the next collection time interval increases to 1 minute. If n2≤n1, it means that the delay time of the standby database instance may be converging, and the next collection time still uses a time interval of 30 seconds; and so on. If the delay time of the standby database instance currently collected is less than the delay time of the standby database instance collected last time, the next collection will continue to use the time interval T of the previous collection. n-1 Otherwise, the next acquisition interval will be twice the previous acquisition interval (2T). n-1; Through continuous collection, each collection time and the corresponding standby database instance delay time are recorded in an array. If it is found that the delay time collected to the standby database instance is 0, the backup task can be directly called again.

[0119] Exemplarily, the basic algorithm of the above fitting process is as follows:

[0120] The time interval for initializing data collection is T0=30, and the delay time for initializing the standby database instance is Lag0=60 (a delay greater than 60 will affect the database backup process);

[0121] While the number of iterations n≤10 and Time i ≥Current time do:

[0122] Get the delay time of the current standby database instance as Lag i ;

[0123] If Lag i ≥Lag i-1 :

[0124] T i =T i-1 *2;

[0125] Time i =Time i+1 +T i ;

[0126] If Lag i ≤Lag i-1 :

[0127] T i =T i-1 ;

[0128] Time i =Time i+1 +T i ;

[0129] When the number of iterations reaches 10, the collection time list is [Time0, Time1, ..., Time 10 ], the delay time list of the standby database instance is [Lag0,Lag1,...,Lag 10 ], the collection time list and the standby database instance delay time list are fitted through a linear function to obtain the corresponding fitting function. The fitting function can be used to determine the standby database instance delay time corresponding to the estimated time point, thereby effectively avoiding blindly calling system resources to detect the delay of the standby database instance and saving computing resources.

[0130] Step 212: If the sub-health reason is that the data synchronization state of the standby database instance is abnormally terminated, the self-healing process of the standby database instance is entered. After the self-healing operation of the standby database instance is completed, step 214 is entered.

[0131] Here, if the backup failure is caused by the abnormal data synchronization state (master-slave synchronization state) of the standby database instance, the self-healing process of the standby database instance will be entered. Among them, the processing methods are different for different disk types used by cloud databases. For example, cloud disk type databases (cloud disk databases) are mounted with S3 storage to store data, and local disk type databases (local disk databases) store data on the corresponding Node nodes. In addition, most of the standby database instances (cloud disk instances) of cloud disk databases can be restored to a healthy state by restarting, while the standby database instances (local disk instances) of local disk databases generally require automatic re-building of the master-slave method to restore the standby database instances to normal.

[0132] in, Figure 5 is a flow chart of a method for performing a corresponding self-healing operation according to a standby database instance type provided in an embodiment of the present application, such as Figure 5 As shown, the method comprises the following steps:

[0133] Step S501: Determine the disk type used by the cloud database and restart the standby database instance that needs self-healing.

[0134] Step S502: If the standby database instance is a cloud disk instance, and the data synchronization status of the standby database instance after restart is restored to normal, then directly call the backup task again, otherwise check whether the cloud disk is still mounted on the previous Node node, or check whether the image version of the cloud database is too low, and repair the mounting location of the cloud disk or upgrade the image file of the cloud database; if the standby database instance is a local disk instance, and the data synchronization status of the standby database instance after restart is restored to normal, then check whether the status of the standby database instance has become pending, and decide whether it is necessary to lift the scheduling ban on the local disk node, and then call the backup task again, otherwise rebuild the standby database instance and perform master-slave synchronization operations.

[0135] Step S503: For rebuilding the standby database instance and performing master-slave synchronization operations, calculate the data size of the standby database instance, and determine whether it can be successfully restored within the set backup time interval based on the data volume of 10G restored per minute. If it can be successfully restored, directly rebuild the standby database instance and perform master-slave synchronization; if it cannot be successfully restored within the set backup time interval, analyze whether the lost GTID is a transaction that updates the heartbeat table. If so, gradually skip such transactions, start START SLAVE, and start the synchronization process.

[0136] Step S504: If the standby database instance self-heals successfully, the backup task is directly re-invoked; if the standby database instance self-heals unsuccessfully, the standby database instance that failed to be backed up is output to the alarm center so that the operation and maintenance personnel can perform manual analysis.

[0137] It should be noted that for scenarios that are not covered, manual analysis is required and they need to be incorporated into the self-healing process to iteratively optimize the self-healing function of the standby database instance.

[0138] Step 213: If the backup failure is caused by abnormal connectivity of the storage cluster or abnormality of the backup task itself, proceed to step 214.

[0139] Here, if the reason for the backup failure is that the connectivity of the storage cluster is abnormal, it means that the nodes in the storage cluster cannot communicate normally or the data transmission fails. For example, unstable network connection, incorrect IP address and port settings, firewall or security policy blocking communication, etc. may cause abnormal connectivity of the storage cluster, resulting in the failure of the backup task; if the reason for the backup failure is the abnormality of the backup task itself, it means that insufficient resources or configuration errors occurred when executing the backup task. For example, insufficient resources, failed resource creation, and failure to find the scheduling node may cause the backup task to be stuck, resulting in the failure of the backup task; if the reason for the backup failure is the above two situations, delete the backup resource container where the backup failed, delete the instance in the backup exception list, and call the backup task again.

[0140] Step 214: Determine whether the current time is in the backup time interval, if so, proceed to step 215; otherwise, proceed to step 216.

[0141] Step 215: Re-call the backup task within the backup time interval.

[0142] Step 216: End the backup process.

[0143] Here, after completing the self-healing process (self-healing is successful) and re-calling the backup task, if the backup is still not successfully completed within the set backup time interval, manual intervention is required and the specific cause of failure is analyzed to iteratively optimize the detection of backup failure causes and the self-healing function. Figure 6 is a flow chart of a method for detecting and self-healing the cause of iterative optimization backup failure provided by an embodiment of the present application, such as Figure 6 As shown, the method comprises the following steps:

[0144] Step 601: Start analyzing failed backup tasks.

[0145] Step 602: Analyze the log information of the failed backup task.

[0146] Step 603: Determine the backup failure reason of the failed backup task.

[0147] Step 604: If the reason for the backup failure is unreasonable parameter settings, proceed to steps 605 and 606.

[0148] Step 605: Add the backup failure reason to the unreasonable parameter setting judgment list, and proceed to step 611.

[0149] Step 606: Notify the customer of the reason for the backup failure and proceed to step 611.

[0150] Step 607: If the reason for the backup failure is that the standby database instance is in a sub-healthy state, proceed to step 608.

[0151] Step 608: Determine whether there is a delay in the standby database instance. If so, it means that the backup time interval set by the customer is unreasonable, and go to step 606; otherwise, go to step 609.

[0152] Step 609: Check the reasons why the standby database instance is sub-healthy.

[0153] Step 610: If a new sub-health reason occurs in the standby database instance, causing the backup task to fail, the sub-health reason is included in the self-healing scenario, and the process goes to step 611.

[0154] Step 611: End the analysis process.

[0155] In summary, when the amount of data in the cloud database is large, it is difficult to ensure the backup success rate of a large-scale database cluster by implementing scheduled backup of the cloud database through crone job in Kubernetes. Based on this, the technical solution of the embodiment of the present application is based on the containerized cloud database of Kubernetes, and improves the failure verification mechanism of the crone job backup service in Kubernetes, that is, by detecting and segmenting the reasons for backup failure, instead of directly retrying the backup without judgment, it reduces invalid backup resource calls and saves unnecessary resource waste; and, by automatically discovering backup anomalies in the cloud database, performing backup retries and self-healing processes of abnormal backup instances according to different scenarios, the reliability and success rate of data backup are improved compared to existing backup methods.

[0156] The present application also provides a database backup optimization device. Figure 7 is a schematic diagram of the structure of the database backup optimization device provided in the embodiment of the present application, such as Figure 7 As shown, the device comprises:

[0157] The determination unit 701 is used to determine that the backup task is a failed backup task if a failure alarm occurs in the backup task in the cloud database; the failed backup task is within a preset backup time interval.

[0158] The analyzing unit 702 is used to analyze the failed backup task to obtain the reason for the backup failure.

[0159] The determining unit 701 is further configured to determine a solution corresponding to the backup failure reason based on the backup failure reason.

[0160] The optimization unit 703 is used to optimize the backup process of the backup task based on the solution.

[0161] In some implementations, the analysis unit 702 is specifically configured to obtain log information related to the failed backup task; match keywords in the log information with preset keywords to obtain target keywords; and determine the cause of the failed backup based on the target keywords.

[0162] In some embodiments, the determination unit 701 is specifically used to classify the backup failure cause to obtain different categories of failure causes if it is determined that the backup failure cause is caused by an abnormal condition occurring in the cloud database; based on the different categories of failure causes, determine solutions corresponding to the different categories of failure causes.

[0163] In some embodiments, the determination unit 701 is further specifically used to delete the failed backup task and call a new backup task if it is determined that the connectivity of the storage cluster is abnormal or the resources of the backup task are abnormal; or, if it is determined that the standby database is in a sub-healthy state, classify the sub-health reasons of the standby database to obtain different categories of sub-health reasons; based on different categories of sub-health reasons, determine solutions corresponding to different categories of sub-health reasons; wherein multiple categories of failure reasons include one or more of the following: the standby database is in a sub-healthy state, the connectivity of the storage cluster is abnormal, and the resources of the backup task are abnormal.

[0164] In some embodiments, the determination unit 701 is further specifically used to query the status of the standby database if it is determined that there is a delay in data synchronization of the standby database; determine the delay time of the standby database based on the status of the standby database, and when it is determined that the time point corresponding to the delay time is reached, delete the failed backup task and call a new backup task; or, determine the delay time of the standby database based on a preset strategy, and when it is determined that the time point corresponding to the delay time is reached, delete the failed backup task and call a new backup task.

[0165] In some embodiments, the determination unit 701 is further specifically used to classify the types of standby databases to obtain different types of standby databases if it is determined that the data synchronization status of the standby database is abnormal; based on the different types of standby databases, determine the self-healing processes corresponding to the different types of standby databases; wherein the sub-health reasons of the standby database include one or more of the following: there is a delay in the data synchronization of the standby database, and the data synchronization status of the standby database is abnormal.

[0166] In some embodiments, the determination unit 701 is further specifically used to collect the delay time of the backup database based on a preset interval time within a preset number of iterations to obtain a sampling time series and a delay time series of the backup database; fit the sampling time series and the delay time series based on a preset function to obtain a fitting function; and predict the delay time corresponding to the backup database at an estimated time point based on the fitting function.

[0167] In some embodiments, the determination unit 701 is also specifically used to restart the backup database and determine whether the data synchronization status of the backup database after the restart has returned to normal: if the data synchronization status of the backup database after the restart has returned to normal, the failed backup task is deleted, and a new backup task is called; or, if it is determined that the backup database is a cloud disk, and the data synchronization status of the backup database after the restart has not returned to normal, the corresponding self-healing process is determined based on different abnormal reasons; or, if it is determined that the backup database is a local disk, and the data synchronization status of the backup database after the restart has not returned to normal, the backup database is rebuilt and the master-slave synchronization operation is performed; wherein, different types of backup databases include one or more of the following: cloud disk, local disk.

[0168] In some embodiments, the optimization unit 703 is also used to obtain new log information corresponding to the new backup task if it is determined that a failure alarm occurs in the new backup task; the new backup task is within a preset backup time interval; and the new log information is sent to the operation and maintenance personnel, so that the operation and maintenance personnel can iteratively optimize the detection of the cause of the backup failure and the self-healing process based on the new log information.

[0169] In the technical solution of the embodiment of the present application, if a failure alarm occurs in a backup task in a cloud database, the backup task is determined to be a backup failure task, and the backup failure task is analyzed to obtain the backup failure cause. Based on the backup failure cause, a solution corresponding to the backup failure cause is determined, and based on the solution, the backup process of the backup task is optimized; wherein the backup failure task is within a preset backup time interval. In this way, in the case of a backup task failure, by adding a detection step for the backup failure cause, unnecessary backup retries can be reduced, and time and labor costs can be reduced. In addition, by arranging solutions corresponding to different backup failure causes, the detection and self-healing functions of the backup failure cause can be iteratively optimized, thereby optimizing the backup process of the backup task and improving the overall success rate of cloud database backup.

[0170] Those skilled in the art should understand that Figure 7 The implementation functions of each unit in the database backup optimization device shown can be understood by referring to the relevant description of the aforementioned method. Figure 7 The functions of each unit in the database backup optimization device shown can be implemented by a program running on a processor, or by a specific logic circuit.

[0171] Figure 8 is a schematic diagram of the structure of a processing device provided in an embodiment of the present application. The processing device may be a terminal device or a network device. Figure 8 The processing device shown includes a processor 801, which can call and run a computer program from a memory to implement the method in the embodiment of the present application.

[0172] Alternatively, if Figure 8 As shown, the processing device may further include a memory 802. The processor 801 may call and run a computer program from the memory 802 to implement the method in the embodiment of the present application.

[0173] The memory 802 may be a separate device independent of the processor 801 , or may be integrated into the processor 801 .

[0174] Alternatively, if Figure 8 As shown, the processing device may further include a transceiver 803, and the processor 801 may control the transceiver 803 to communicate with other devices, specifically, may send information or data to other devices, or receive information or data sent by other devices.

[0175] The transceiver 803 may include a transmitter and a receiver. The transceiver 803 may further include an antenna, and the number of antennas may be one or more.

[0176] The processing device may specifically be a database backup optimization device of the embodiment of the present application, and the processing device may implement the corresponding processes of the various methods implemented in the embodiment of the present application, which will not be described in detail here for the sake of brevity.

[0177] It should be understood that the processor of the embodiment of the present application may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method embodiment can be completed by the hardware integrated logic circuit or software instructions in the processor. The above processor can be a general processor, a digital signal processor (Digital Signal Processor, DSP), an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or the hardware and software modules in the decoding processor are combined and performed. The software module can be located in a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, and other mature storage media in the art. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0178] It can be understood that the memory in the embodiments of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct RAM bus random access memory (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0179] It should be understood that the above-mentioned memory is exemplary but not restrictive. For example, the memory in the embodiments of the present application may also be static random access memory (static RAM, SRAM), dynamic random access memory (dynamic RAM, DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (synch link DRAM, SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DR RAM), etc. That is to say, the memory in the embodiments of the present application is intended to include but not limited to these and any other suitable types of memory.

[0180] The embodiment of the present application also provides a computer-readable storage medium for storing a computer program. The computer-readable storage medium can be applied to the processing device in the embodiment of the present application, and the computer program enables the computer to execute the corresponding process of each method implemented in the embodiment of the present application, which will not be described here for the sake of brevity.

[0181] The embodiment of the present application also provides a computer program product, including computer program instructions. The computer program product can be applied to the processing device in the embodiment of the present application, and the computer program instructions enable the computer to execute the corresponding process of each method implemented in the embodiment of the present application, which will not be described here for the sake of brevity.

[0182] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0183] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0184] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0185] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0186] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0187] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory,) ROM, random access memory (RandomAccess Memory, RAM), disk or optical disk and other media that can store program codes.

[0188] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A database backup optimization method, characterized in that: The method comprises: If a backup task in the cloud database has a failure alarm, the backup task is determined to be a failed backup task; and the failed backup task is within a preset backup time interval; Analyze the failed backup task to obtain the reason for the backup failure; Based on the backup failure reason, determining a solution corresponding to the backup failure reason; Based on the solution, the backup process of the backup task is optimized.

2. The method according to claim 1, characterized in that The analyzing the failed backup task to obtain the reason for the backup failure includes: Obtaining log information related to the failed backup task; Matching the keywords in the log information with preset keywords to obtain target keywords; Based on the target keyword, the reason for the backup failure is determined.

3. The method according to claim 1, characterized in that: The determining, based on the backup failure cause, a solution corresponding to the backup failure cause includes: If it is determined that the backup failure cause is caused by an abnormal condition occurring in the cloud database, the backup failure cause is classified to obtain failure causes of different categories; based on the failure causes of different categories, solutions corresponding to the failure causes of different categories are determined.

4. The method according to claim 3, characterized in that The multiple categories of failure reasons include one or more of the following: the backup database is in a sub-healthy state, the connectivity of the storage cluster is abnormal, and the resources of the backup task are abnormal; The determining, based on the different categories of failure causes, solutions corresponding to the different categories of failure causes includes: If it is determined that the connectivity of the storage cluster is abnormal or the resources of the backup task are abnormal, the failed backup task is deleted and a new backup task is called; or, If it is determined that the standby warehouse is in a sub-healthy state, the sub-healthy causes of the standby warehouse are classified to obtain different categories of sub-healthy causes; based on the different categories of sub-healthy causes, solutions corresponding to the different categories of sub-healthy causes are determined.

5. The method according to claim 4, characterized in that The sub-health reasons of the standby database include one or more of the following: data synchronization of the standby database is delayed, and the data synchronization state of the standby database is abnormal; the determining of solutions corresponding to the different categories of sub-health reasons based on the different categories of sub-health reasons includes: If it is determined that there is a delay in data synchronization of the standby database, query the status of the standby database; determine the delay time of the standby database based on the status of the standby database, and when it is determined that the time point corresponding to the delay time is reached, delete the failed backup task and call a new backup task; or, The delay time of the backup database is determined based on a preset strategy. When it is determined that a time point corresponding to the delay time has been reached, the failed backup task is deleted and a new backup task is called.

6. The method according to claim 5, characterized in that The method further comprises: If it is determined that the data synchronization state of the standby database is abnormal, the types of the standby databases are classified to obtain different types of standby databases; Based on the different types of standby databases, self-healing processes corresponding to the different types of standby databases are determined.

7. The method according to claim 5, characterized in that The determining the delay time of the standby database based on a preset strategy includes: Within a preset number of iterations, the delay time of the standby database is collected based on a preset interval time to obtain a sampling time series and a delay time series of the standby database; The sampling time series and the delay time series are fitted based on a preset function to obtain a fitting function; and the delay time corresponding to the standby database at the estimated time point is predicted based on the fitting function.

8. The method according to claim 6, characterized in that The different types of standby repositories include one or more of the following: a cloud disk and a local disk; and determining the self-healing process corresponding to the different types of standby repositories based on the different types of standby repositories includes: Restart the standby database and determine whether the data synchronization status of the restarted standby database is restored to normal: if the data synchronization status of the restarted standby database is restored to normal, delete the failed backup task and call a new backup task; or, If it is determined that the backup database is the cloud disk, and the data synchronization status of the restarted backup database has not returned to normal, then determine the corresponding self-healing process based on different abnormal reasons; or, If it is determined that the standby database is the local disk, and the data synchronization status of the standby database after restart has not returned to normal, the standby database is rebuilt and the master-slave synchronization operation is performed.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: If it is determined that a failure alarm occurs in the new backup task, new log information corresponding to the new backup task is obtained; the new backup task is within the preset backup time interval; The new log information is sent to the operation and maintenance personnel so that the operation and maintenance personnel can iteratively optimize the detection of the cause of the backup failure and the self-healing process based on the new log information.

10. A database backup optimization device, characterized in that: The device comprises: A determination unit, configured to determine that a backup task in a cloud database is a failed backup task if a failure alarm occurs in the backup task; and the failed backup task is within a preset backup time interval; An analysis unit, used to analyze the failed backup task to obtain the reason for the backup failure; The determining unit is further configured to determine a solution corresponding to the backup failure cause based on the backup failure cause; An optimization unit is used to optimize the backup process of the backup task based on the solution.

11. A processing device, characterized in that: include: A processor and a memory, the memory being used to store a computer program, the processor being used to call and run the computer program stored in the memory to execute the method as claimed in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein the computer program causes a computer to execute the method according to any one of claims 1 to 9.

13. A computer program product, characterized in that The method comprises computer program instructions which cause a computer to execute the method as claimed in any one of claims 1 to 9.

Images