Database cluster anomaly handling methods, devices, equipment and media

Abstract

This invention relates to the field of operations and maintenance, providing a method, apparatus, device, and medium for handling database cluster anomalies. It can initiate different threads to monitor the operational status and service usage of the database cluster, performing targeted monitoring at both the database metric and service levels. Based on the target anomaly scenario, it queries a logic algorithm library to obtain the target anomaly handling logic, effectively avoiding the impact of varying personnel skill levels on fault handling results. Different processing methods are applied to database internal self-healing types and database cluster self-healing types, thus integrating scattered, point-based anomaly scenarios into a complete anomaly handling system. This system links the entire anomaly handling lifecycle, from monitoring to location, processing, and aftercare, providing full lifecycle coverage and effectively improving the efficiency and accuracy of fault handling. Furthermore, this invention also relates to blockchain technology, with the logic algorithm library stored in blockchain nodes.

Description

Technical Field

[0001] This invention relates to the field of operation and maintenance technology, and in particular to a method, apparatus, device and medium for handling database cluster anomalies. Background Technology

[0002] As businesses grow and their data volumes increase dramatically, the demand for databases also rises. Therefore, in order to ensure the normal operation of business, it is necessary to handle database anomalies in a timely and effective manner.

[0003] Most existing solutions employ a reverse fault diagnosis approach, lacking an integrated process and implementation. Each fault requires dedicated operations and maintenance personnel to assess the database's operational status, which not only consumes a significant amount of their time but also easily leads to low efficiency in restoring the database's service status. Furthermore, due to differences in the technical skills and psychological qualities of each operations and maintenance personnel, unexpected factors may arise during each fault handling process.

[0004] Therefore, the key to reducing risk is to reduce the involvement of operations and maintenance personnel in database fault handling, and to avoid human factors affecting the efficiency and accuracy of database anomaly recovery. Summary of the Invention

[0005] In view of the above, it is necessary to provide a database cluster anomaly handling method, apparatus, device and medium, aiming to solve the problem of low efficiency and accuracy in database cluster anomaly handling.

[0006] A database cluster anomaly handling method, the database cluster anomaly handling method comprising:

[0007] In response to an exception handling command for the database cluster, the first thread is started to monitor the real-time running status of the database cluster and obtain the first monitoring result.

[0008] At preset time intervals, a second thread is started to perform service usage detection and monitoring on the database cluster, and a second monitoring result is obtained.

[0009] When the first monitoring result and / or the second monitoring result are detected to be abnormal, the target abnormal scenario is determined;

[0010] Based on the target anomaly scenario, a query is performed in a pre-configured logic algorithm library to obtain the target anomaly handling logic;

[0011] When the target anomaly handling logic corresponds to the database internal self-healing type, the database cluster is subjected to first anomaly handling based on the target anomaly handling logic to obtain a first processing result.

[0012] When the target anomaly handling logic corresponds to the database cluster self-healing type, the database cluster is subjected to second anomaly handling based on the target anomaly handling logic to obtain the second processing result.

[0013] Send the first processing result and / or the second processing result to the designated terminal.

[0014] According to a preferred embodiment of the present invention, the step of real-time monitoring of the operational status of the database cluster to obtain a first monitoring result includes:

[0015] The databases in the service are obtained from the database cluster as target databases, and a target database set is constructed based on the target databases;

[0016] The running status of each target database in the target database set is collected in real time;

[0017] Obtain pre-configured database metrics and the risk threshold for each database metric;

[0018] The real-time values ​​of each database indicator corresponding to each target database are determined based on the operating status of each target database.

[0019] When a real-time value of a database indicator is detected to be greater than the risk threshold of the detected database indicator, the detected database indicator is identified as an abnormal indicator, and the target database corresponding to the abnormal indicator is identified as the first abnormal database. The first monitoring result is then generated based on the first abnormal database and the abnormal indicator, wherein the first monitoring result is abnormal; or

[0020] When no real-time value of a database indicator is detected that is greater than the risk threshold of the detected database indicator, the first monitoring result is determined to be normal.

[0021] According to a preferred embodiment of the present invention, the step of performing service usage probing and monitoring on the database cluster to obtain a second monitoring result includes:

[0022] Obtain the set of tasks to be monitored, and simulate the operation of each task in the set of tasks on the database cluster;

[0023] When an anomaly is detected in a task to be monitored, the detected task is identified as an abnormal task, and the database executing the abnormal task is identified as a second abnormal database. A second monitoring result is generated based on the second abnormal database and the abnormal task, wherein the second monitoring result is abnormal; or

[0024] If no abnormal return is detected for the task to be monitored, the second monitoring result is determined to be normal.

[0025] According to a preferred embodiment of the present invention, before performing a query in a pre-configured logical algorithm library based on the target abnormal scenario, the method further includes:

[0026] Obtain historical anomaly data from the database cluster;

[0027] Extract the abnormal scenarios and corresponding abnormal handling logic from the historical abnormal data, and determine the mapping relationship between the abnormal scenarios and the corresponding abnormal handling logic.

[0028] At least one fault model is established based on the abnormal scenario, the corresponding abnormal handling logic, and the mapping relationship.

[0029] Receive the uploaded supplementary mapping relationship, and establish at least one supplementary fault model based on the supplementary mapping relationship;

[0030] The at least one fault model and the at least one supplementary fault model are written into the logic algorithm library.

[0031] According to a preferred embodiment of the present invention, the step of performing first exception handling on the database cluster based on the target exception handling logic to obtain a first processing result includes:

[0032] Retrieve the abnormal database from the database cluster;

[0033] Perform a load reduction operation on the abnormal database until the abnormal database returns to normal, and obtain the first processing result.

[0034] According to a preferred embodiment of the present invention, the second exception handling performed on the database cluster based on the target exception handling logic includes:

[0035] Obtain the abnormal database from the database cluster, and obtain the backup database corresponding to the abnormal database from the database cluster;

[0036] The backup database is designated as the primary database, and the faulty database is used to replace it for service.

[0037] According to a preferred embodiment of the present invention, after determining the backup database as the primary database and replacing the faulty database for service, the method further includes:

[0038] Configure a backup database for the primary database;

[0039] Synchronize the data in the main database to the backup database.

[0040] A database cluster anomaly handling device, the database cluster anomaly handling device comprising:

[0041] The monitoring unit is used to respond to the abnormal handling command of the database cluster, start the first thread to monitor the real-time running status of the database cluster, and obtain the first monitoring result.

[0042] The monitoring unit is also used to start a second thread every preset time period to perform service usage detection and monitoring on the database cluster and obtain a second monitoring result.

[0043] The determining unit is used to determine the target abnormal scenario when the first monitoring result and / or the second monitoring result are detected to be abnormal;

[0044] The query unit is used to query a pre-configured logic algorithm library based on the target abnormal scenario to obtain the target abnormal handling logic;

[0045] The processing unit is configured to perform first exception processing on the database cluster based on the target exception processing logic when the target exception processing logic corresponds to the database internal self-healing type, and obtain a first processing result.

[0046] The processing unit is further configured to perform a second exception processing on the database cluster based on the target exception processing logic when the target exception processing logic corresponds to the database cluster self-healing type, and obtain a second processing result.

[0047] The sending unit is used to send the first processing result and / or the second processing result to a designated terminal.

[0048] A computer device, the computer device comprising:

[0049] Memory, storing at least one instruction; and

[0050] The processor executes instructions stored in the memory to implement the database cluster exception handling method.

[0051] A computer-readable storage medium storing at least one instruction, which is executed by a processor in a computer device to implement the database cluster exception handling method.

[0052] As can be seen from the above technical solution, the present invention can respond to anomaly handling instructions for a database cluster by starting a first thread to monitor the real-time operating status of the database cluster and obtaining a first monitoring result. At preset time intervals, a second thread is started to monitor the service usage of the database cluster and obtain a second monitoring result. This allows for targeted monitoring of the database cluster from both the database metric and service levels. When anomalies are detected in the first and / or second monitoring results, a target anomaly scenario is determined. Based on the target anomaly scenario, a query is performed in a pre-configured logic algorithm library to obtain the target anomaly handling logic. This effectively avoids the impact of varying personnel skill levels on fault handling results. In response to the impact of the results, when the target anomaly handling logic corresponds to the database's internal self-healing type, the database cluster is subjected to first anomaly handling based on the target anomaly handling logic to obtain a first processing result. When the target anomaly handling logic corresponds to the database cluster's self-healing type, the database cluster is subjected to second anomaly handling based on the target anomaly handling logic to obtain a second processing result. The first processing result and / or the second processing result are sent to a designated terminal, thereby integrating scattered point-like anomaly scenarios into a complete anomaly handling system. This links the entire anomaly handling lifecycle, from monitoring to location to processing to aftercare, providing full lifecycle coverage and effectively improving the efficiency and accuracy of fault handling. Attached Figure Description

[0053] Figure 1 This is a flowchart of a preferred embodiment of the database cluster anomaly handling method of the present invention.

[0054] Figure 2 This is a functional block diagram of a preferred embodiment of the database cluster anomaly handling device of the present invention.

[0055] Figure 3 This is a schematic diagram of the structure of a computer device that implements a preferred embodiment of the database cluster exception handling method of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0057] like Figure 1 The diagram shown is a flowchart of a preferred embodiment of the database cluster anomaly handling method of the present invention. The order of the steps in this flowchart can be changed, and some steps can be omitted, depending on different requirements.

[0058] The database cluster anomaly handling method is applied to one or more computer devices. The computer device is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0059] The computer device can be any electronic product that can interact with the user, such as a personal computer, tablet computer, smartphone, personal digital assistant (PDA), game console, interactive network television (IPTV), smart wearable device, etc.

[0060] The computer equipment may also include network equipment and / or user equipment. The network equipment includes, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud based on cloud computing consisting of a large number of hosts or network servers.

[0061] The server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0062] Artificial intelligence (AI) is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results.

[0063] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0064] The network in which the computer device is located includes, but is not limited to, the Internet, wide area network, metropolitan area network, local area network, and virtual private network (VPN).

[0065] S10, in response to the exception handling instruction for the database cluster, start the first thread to monitor the real-time running status of the database cluster and obtain the first monitoring result.

[0066] In at least one embodiment of the present invention, the exception handling instruction for the database cluster can be triggered by relevant operation and maintenance personnel or test personnel, and the present invention does not limit this.

[0067] In this embodiment, the database cluster may include at least one database, and each database may store data generated by different services. Of course, the database may also include alternative databases, which will be described later and will not be elaborated here.

[0068] In at least one embodiment of the present invention, the step of real-time monitoring of the operational status of the database cluster to obtain a first monitoring result includes:

[0069] The databases in the service are obtained from the database cluster as target databases, and a target database set is constructed based on the target databases;

[0070] The running status of each target database in the target database set is collected in real time;

[0071] Obtain pre-configured database metrics and the risk threshold for each database metric;

[0072] The real-time values ​​of each database indicator corresponding to each target database are determined based on the operating status of each target database.

[0073] When a real-time value of a database indicator is detected to be greater than the risk threshold of the detected database indicator, the detected database indicator is identified as an abnormal indicator, and the target database corresponding to the abnormal indicator is identified as the first abnormal database. The first monitoring result is then generated based on the first abnormal database and the abnormal indicator, wherein the first monitoring result is abnormal; or

[0074] When no real-time value of a database indicator is detected that is greater than the risk threshold of the detected database indicator, the first monitoring result is determined to be normal.

[0075] It should be noted that since the database cluster also includes standby databases that are not in service, the metrics of these databases do not need to be monitored in real time in order to reduce the waste of system resources.

[0076] In at least one embodiment of the present invention, the database metrics may include, but are not limited to, a set of one or more of the following metrics:

[0077] CPU (central processing unit) utilization, memory usage, number of active sessions, redo volume, and undo volume.

[0078] In at least one embodiment of the present invention, the threshold for each database metric can be configured by combining the performance of each database and its historical operating data, and the present invention does not limit this.

[0079] Furthermore, when the real-time value of a database indicator exceeds the corresponding threshold, it indicates that the corresponding database is working under overload, which may affect the operation results. Therefore, the first monitoring result is generated based on the abnormal database and the abnormal indicator, wherein the first monitoring result is abnormal, so as to handle the abnormality in a timely manner.

[0080] The above monitoring process is equivalent to real-time white-box monitoring of the database cluster's operating status, recording various indicators during the database cluster's operation.

[0081] Through the above implementation method, it is possible to perform real-time monitoring of various operational indicators of databases in service status in a targeted manner, and to lock the monitoring target to specific database indicators to ensure the real-time service performance of each database.

[0082] S11, every preset time period, start the second thread to perform service usage detection and monitoring on the database cluster, and obtain the second monitoring result.

[0083] In at least one embodiment of the present invention, the preset time period can be customized.

[0084] For example, in order to detect whether the database cluster can guarantee normal operation during normal service, the preset time period can be configured to be a certain period of time during the normal service period of the database cluster.

[0085] In at least one embodiment of the present invention, the step of performing service usage probing and monitoring on the database cluster to obtain a second monitoring result includes:

[0086] Obtain the set of tasks to be monitored, and simulate the operation of each task in the set of tasks on the database cluster;

[0087] When an anomaly is detected in a task to be monitored, the detected task is identified as an abnormal task, and the database executing the abnormal task is identified as a second abnormal database. A second monitoring result is generated based on the second abnormal database and the abnormal task, wherein the second monitoring result is abnormal; or

[0088] If no abnormal return is detected for the task to be monitored, the second monitoring result is determined to be normal.

[0089] In at least one embodiment of the present invention, the set of tasks to be monitored can be configured according to actual task requirements, such as tasks for topping up mobile phone credit, tasks for purchasing financial products, etc.

[0090] Furthermore, when the set of tasks to be monitored includes a phone bill top-up task, a phone bill top-up operation can be simulated based on a pre-embedded plugin or a packaged script, and the phone bill top-up operation can be detected as being executed normally.

[0091] The above monitoring process is equivalent to black-box monitoring of the database cluster, used to simulate the availability monitoring of database operations by production line businesses.

[0092] Through the above implementation methods, the database cluster can be probed from the service level to monitor the execution status of specific tasks in a targeted manner.

[0093] S12, when the first monitoring result and / or the second monitoring result are detected to be abnormal, the target abnormal scenario is determined.

[0094] In this embodiment, the target abnormal scenario can correspond to a specific abnormal subclass, such as too many query operations or too many active sessions.

[0095] Specifically, the target abnormal scenario can be determined by querying a pre-configured list of abnormal scenarios based on keywords from the first monitoring result and / or the second monitoring result.

[0096] In the above implementation, as long as an anomaly is detected, the anomaly scenario is determined so that the anomaly can be handled in a timely manner.

[0097] S13, based on the target abnormal scenario, query the pre-configured logic algorithm library to obtain the target abnormality handling logic.

[0098] In at least one embodiment of the present invention, before querying a pre-configured logical algorithm library according to the target abnormal scenario, the method further includes:

[0099] Obtain historical anomaly data from the database cluster;

[0100] Extract the abnormal scenarios and corresponding abnormal handling logic from the historical abnormal data, and determine the mapping relationship between the abnormal scenarios and the corresponding abnormal handling logic.

[0101] At least one fault model is established based on the abnormal scenario, the corresponding abnormal handling logic, and the mapping relationship.

[0102] Receive the uploaded supplementary mapping relationship, and establish at least one supplementary fault model based on the supplementary mapping relationship;

[0103] The at least one fault model and the at least one supplementary fault model are written into the logic algorithm library.

[0104] In this embodiment, the at least one fault model and the at least one supplementary fault model can be in the form of a Python logic algorithm.

[0105] Furthermore, a query is performed in a pre-configured logic algorithm library based on the target abnormal scenario, and the abnormal handling logic corresponding to the target abnormal scenario is determined as the target abnormal handling logic.

[0106] Through the above implementation method, based on the fault phenomena when different faults occurred in the past, the abstract database operation abnormality scenarios are combined into different fault models. Then, combined with expert experience, a unified processing logic is formed under different fault models, which effectively avoids the impact of the varying business level of personnel on the fault handling results.

[0107] S14, when the target exception handling logic corresponds to the database internal self-healing type, the database cluster is subjected to first exception handling based on the target exception handling logic to obtain the first processing result.

[0108] In this embodiment, the database internal self-healing type corresponds to the abnormal handling of the operating indicators of each database in the database cluster.

[0109] In at least one embodiment of the present invention, the step of performing first exception handling on the database cluster based on the target exception handling logic to obtain a first processing result includes:

[0110] Retrieve the abnormal database from the database cluster;

[0111] Perform a load reduction operation on the abnormal database until the abnormal database returns to normal, and obtain the first processing result.

[0112] For example: when it is determined that database A is abnormal and there are too many query operations corresponding to database A, kill the query operations of database A until database A returns to normal, and generate the first processing result based on the processing result of database A.

[0113] In the above implementation, the database internal self-healing type corresponds to the situation where the database instance's operating environment is overloaded. When the database instance's operating load rises to a dangerous level, the self-healing program will automatically reduce the load so that the database can return to normal operation as soon as possible.

[0114] S15, when the target anomaly handling logic corresponds to the database cluster self-healing type, the database cluster is subjected to second anomaly handling based on the target anomaly handling logic to obtain the second processing result.

[0115] In at least one embodiment of the present invention, performing second exception handling on the database cluster based on the target exception handling logic includes:

[0116] Obtain the abnormal database from the database cluster, and obtain the backup database corresponding to the abnormal database from the database cluster;

[0117] The backup database is designated as the primary database, and the faulty database is used to replace it for service.

[0118] For example, when an anomaly is detected in the database cluster service, the abnormal database B is obtained, and a backup database for database B is obtained. The backup database for database B is then used to replace database B for operation.

[0119] In the above implementation, the database cluster self-healing type corresponds to the situation where the database cluster service is damaged. By switching the instance role status within the database cluster (i.e., master-slave switch), the database cluster service can be quickly restored.

[0120] Furthermore, after determining the backup database as the primary database and replacing the faulty database for service, the method further includes:

[0121] Configure a backup database for the primary database;

[0122] Synchronize the data in the main database to the backup database.

[0123] It should be noted that the primary and backup databases have the same performance and can replace each other for operation.

[0124] In this embodiment, the backup database can be an abnormal database that has been replaced by the main database, or it can be any other database; the present invention does not limit this.

[0125] The above implementation methods can achieve high availability of the database cluster, avoid affecting the normal service of the entire database cluster when the service of one database is damaged, and improve the robustness of the database cluster service.

[0126] S16, send the first processing result and / or the second processing result to the designated terminal.

[0127] In this embodiment, the designated terminal may include the terminal equipment of relevant personnel such as operation and maintenance and testing staff, so that relevant personnel can understand the abnormal handling status of the database cluster in a timely manner and facilitate timely response.

[0128] In this embodiment, scattered point-like anomaly scenarios are integrated into a complete anomaly handling system. Specifically, the operational status of the database is abstracted and refined into a series of indicators, and corresponding thresholds are set for each indicator based on the healthy operating status of the database. The database's operational indicators are monitored in real time. Once the threshold is exceeded, a fault model is matched, and anomaly handling is performed according to the anomaly handling logic encapsulated in the corresponding fault model until the database cluster returns to normal operation, which means that the database cluster anomaly self-healing process is complete.

[0129] This implementation method links the entire lifecycle of anomaly handling, from monitoring to location to processing to follow-up, covering the entire lifecycle and effectively improving the efficiency and accuracy of fault handling.

[0130] It should be noted that, in order to further improve data security and prevent data from being maliciously tampered with, the logic algorithm library can be stored in the blockchain node.

[0131] As can be seen from the above technical solution, the present invention can respond to anomaly handling instructions for a database cluster by starting a first thread to monitor the real-time operating status of the database cluster and obtaining a first monitoring result. At preset time intervals, a second thread is started to monitor the service usage of the database cluster and obtain a second monitoring result. This allows for targeted monitoring of the database cluster from both the database metric and service levels. When anomalies are detected in the first and / or second monitoring results, a target anomaly scenario is determined. Based on the target anomaly scenario, a query is performed in a pre-configured logic algorithm library to obtain the target anomaly handling logic. This effectively avoids the impact of varying personnel skill levels on fault handling results. In response to the impact of the results, when the target anomaly handling logic corresponds to the database's internal self-healing type, the database cluster is subjected to first anomaly handling based on the target anomaly handling logic to obtain a first processing result. When the target anomaly handling logic corresponds to the database cluster's self-healing type, the database cluster is subjected to second anomaly handling based on the target anomaly handling logic to obtain a second processing result. The first processing result and / or the second processing result are sent to a designated terminal, thereby integrating scattered point-like anomaly scenarios into a complete anomaly handling system. This links the entire anomaly handling lifecycle, from monitoring to location to processing to aftercare, providing full lifecycle coverage and effectively improving the efficiency and accuracy of fault handling.

[0132] like Figure 2 The diagram shown is a functional block diagram of a preferred embodiment of the database cluster anomaly handling device of the present invention. The database cluster anomaly handling device 11 includes a monitoring unit 110, a determining unit 111, a querying unit 112, a processing unit 113, and a sending unit 114. The module / unit referred to in this invention refers to a series of computer program segments that can be executed by the processor 13 and perform a fixed function, and are stored in the memory 12. In this embodiment, the functions of each module / unit will be described in detail in subsequent embodiments.

[0133] In response to the abnormal handling command for the database cluster, the monitoring unit 110 starts the first thread to monitor the real-time operating status of the database cluster and obtains the first monitoring result.

[0134] In at least one embodiment of the present invention, the exception handling instruction for the database cluster can be triggered by relevant operation and maintenance personnel or test personnel, and the present invention does not limit this.

[0135] In this embodiment, the database cluster may include at least one database, and each database may store data generated by different services. Of course, the database may also include alternative databases, which will be described later and will not be elaborated here.

[0136] In at least one embodiment of the present invention, the monitoring unit 110 performs real-time monitoring of the operating status of the database cluster and obtains a first monitoring result including:

[0137] The databases in the service are obtained from the database cluster as target databases, and a target database set is constructed based on the target databases;

[0138] The running status of each target database in the target database set is collected in real time;

[0139] Obtain pre-configured database metrics and the risk threshold for each database metric;

[0140] The real-time values ​​of each database indicator corresponding to each target database are determined based on the operating status of each target database.

[0141] When a real-time value of a database indicator is detected to be greater than the risk threshold of the detected database indicator, the detected database indicator is identified as an abnormal indicator, and the target database corresponding to the abnormal indicator is identified as the first abnormal database. The first monitoring result is then generated based on the first abnormal database and the abnormal indicator, wherein the first monitoring result is abnormal; or

[0142] When no real-time value of a database indicator is detected that is greater than the risk threshold of the detected database indicator, the first monitoring result is determined to be normal.

[0143] It should be noted that since the database cluster also includes standby databases that are not in service, the metrics of these databases do not need to be monitored in real time in order to reduce the waste of system resources.

[0144] In at least one embodiment of the present invention, the database metrics may include, but are not limited to, a set of one or more of the following metrics:

[0145] CPU (central processing unit) utilization, memory usage, number of active sessions, redo volume, and undo volume.

[0146] In at least one embodiment of the present invention, the threshold for each database metric can be configured by combining the performance of each database and its historical operating data, and the present invention does not limit this.

[0147] Furthermore, when the real-time value of a database indicator exceeds the corresponding threshold, it indicates that the corresponding database is working under overload, which may affect the operation results. Therefore, the first monitoring result is generated based on the abnormal database and the abnormal indicator, wherein the first monitoring result is abnormal, so as to handle the abnormality in a timely manner.

[0148] The above monitoring process is equivalent to real-time white-box monitoring of the database cluster's operating status, recording various indicators during the database cluster's operation.

[0149] Through the above implementation method, it is possible to perform real-time monitoring of various operational indicators of databases in service status in a targeted manner, and to lock the monitoring target to specific database indicators to ensure the real-time service performance of each database.

[0150] The monitoring unit 110 starts a second thread every preset time period to perform service usage detection and monitoring on the database cluster, and obtains a second monitoring result.

[0151] In at least one embodiment of the present invention, the preset time period can be customized.

[0152] For example, in order to detect whether the database cluster can guarantee normal operation during normal service, the preset time period can be configured to be a certain period of time during the normal service period of the database cluster.

[0153] In at least one embodiment of the present invention, the monitoring unit 110 performs service usage probing and monitoring on the database cluster to obtain a second monitoring result, including:

[0154] Obtain the set of tasks to be monitored, and simulate the operation of each task in the set of tasks on the database cluster;

[0155] When an anomaly is detected in a task to be monitored, the detected task is identified as an abnormal task, and the database executing the abnormal task is identified as a second abnormal database. A second monitoring result is generated based on the second abnormal database and the abnormal task, wherein the second monitoring result is abnormal; or

[0156] If no abnormal return is detected for the task to be monitored, the second monitoring result is determined to be normal.

[0157] In at least one embodiment of the present invention, the set of tasks to be monitored can be configured according to actual task requirements, such as tasks for topping up mobile phone credit, tasks for purchasing financial products, etc.

[0158] Furthermore, when the set of tasks to be monitored includes a phone bill top-up task, a phone bill top-up operation can be simulated based on a pre-embedded plugin or a packaged script, and the phone bill top-up operation can be detected as being executed normally.

[0159] The above monitoring process is equivalent to black-box monitoring of the database cluster, used to simulate the availability monitoring of database operations by production line businesses.

[0160] Through the above implementation methods, the database cluster can be probed from the service level to monitor the execution status of specific tasks in a targeted manner.

[0161] When the first monitoring result and / or the second monitoring result are detected to be abnormal, the determination unit 111 determines the target abnormal scenario.

[0162] In this embodiment, the target abnormal scenario can correspond to a specific abnormal subclass, such as too many query operations or too many active sessions.

[0163] Specifically, the target abnormal scenario can be determined by querying a pre-configured list of abnormal scenarios based on keywords from the first monitoring result and / or the second monitoring result.

[0164] In the above implementation, as long as an anomaly is detected, the anomaly scenario is determined so that the anomaly can be handled in a timely manner.

[0165] The query unit 112 queries the pre-configured logic algorithm library according to the target abnormal scenario to obtain the target abnormal handling logic.

[0166] In at least one embodiment of the present invention, historical abnormal data of the database cluster is obtained before querying the pre-configured logical algorithm library according to the target abnormal scenario;

[0167] Extract the abnormal scenarios and corresponding abnormal handling logic from the historical abnormal data, and determine the mapping relationship between the abnormal scenarios and the corresponding abnormal handling logic.

[0168] At least one fault model is established based on the abnormal scenario, the corresponding abnormal handling logic, and the mapping relationship.

[0169] Receive the uploaded supplementary mapping relationship, and establish at least one supplementary fault model based on the supplementary mapping relationship;

[0170] The at least one fault model and the at least one supplementary fault model are written into the logic algorithm library.

[0171] In this embodiment, the at least one fault model and the at least one supplementary fault model can be in the form of a Python logic algorithm.

[0172] Furthermore, a query is performed in a pre-configured logic algorithm library based on the target abnormal scenario, and the abnormal handling logic corresponding to the target abnormal scenario is determined as the target abnormal handling logic.

[0173] Through the above implementation method, based on the fault phenomena when different faults occurred in the past, the abstract database operation abnormality scenarios are combined into different fault models. Then, combined with expert experience, a unified processing logic is formed under different fault models, which effectively avoids the impact of the varying business level of personnel on the fault handling results.

[0174] When the target anomaly handling logic corresponds to the database internal self-healing type, the processing unit 113 performs first anomaly handling on the database cluster based on the target anomaly handling logic to obtain a first processing result.

[0175] In this embodiment, the database internal self-healing type corresponds to the abnormal handling of the operating indicators of each database in the database cluster.

[0176] In at least one embodiment of the present invention, the processing unit 113 performs first exception handling on the database cluster based on the target exception handling logic, and obtains a first processing result including:

[0177] Retrieve the abnormal database from the database cluster;

[0178] Perform a load reduction operation on the abnormal database until the abnormal database returns to normal, and obtain the first processing result.

[0179] For example: when it is determined that database A is abnormal and there are too many query operations corresponding to database A, kill the query operations of database A until database A returns to normal, and generate the first processing result based on the processing result of database A.

[0180] In the above implementation, the database internal self-healing type corresponds to the situation where the database instance's operating environment is overloaded. When the database instance's operating load rises to a dangerous level, the self-healing program will automatically reduce the load so that the database can return to normal operation as soon as possible.

[0181] When the target anomaly handling logic corresponds to the database cluster self-healing type, the processing unit 113 performs second anomaly handling on the database cluster based on the target anomaly handling logic to obtain a second processing result.

[0182] In at least one embodiment of the present invention, the processing unit 113 performs second exception handling on the database cluster based on the target exception handling logic, including:

[0183] Obtain the abnormal database from the database cluster, and obtain the backup database corresponding to the abnormal database from the database cluster;

[0184] The backup database is designated as the primary database, and the faulty database is used to replace it for service.

[0185] For example, when an anomaly is detected in the database cluster service, the abnormal database B is obtained, and a backup database for database B is obtained. The backup database for database B is then used to replace database B for operation.

[0186] In the above implementation, the database cluster self-healing type corresponds to the situation where the database cluster service is damaged. By switching the instance role status within the database cluster (i.e., master-slave switch), the database cluster service can be quickly restored.

[0187] Furthermore, after determining the backup database as the primary database and replacing the abnormal database for service, a backup database is configured for the primary database;

[0188] Synchronize the data in the main database to the backup database.

[0189] It should be noted that the primary and backup databases have the same performance and can replace each other for operation.

[0190] In this embodiment, the backup database can be an abnormal database that has been replaced by the main database, or it can be any other database; the present invention does not limit this.

[0191] The above implementation methods can achieve high availability of the database cluster, avoid affecting the normal service of the entire database cluster when the service of one database is damaged, and improve the robustness of the database cluster service.

[0192] The sending unit 114 sends the first processing result and / or the second processing result to the designated terminal.

[0193] In this embodiment, the designated terminal may include the terminal equipment of relevant personnel such as operation and maintenance and testing staff, so that relevant personnel can understand the abnormal handling status of the database cluster in a timely manner and facilitate timely response.

[0194] In this embodiment, scattered point-like anomaly scenarios are integrated into a complete anomaly handling system. Specifically, the operational status of the database is abstracted and refined into a series of indicators, and corresponding thresholds are set for each indicator based on the healthy operating status of the database. The database's operational indicators are monitored in real time. Once the threshold is exceeded, a fault model is matched, and anomaly handling is performed according to the anomaly handling logic encapsulated in the corresponding fault model until the database cluster returns to normal operation, which means that the database cluster anomaly self-healing process is complete.

[0195] This implementation method links the entire lifecycle of anomaly handling, from monitoring to location to processing to follow-up, covering the entire lifecycle and effectively improving the efficiency and accuracy of fault handling.

[0196] It should be noted that, in order to further improve data security and prevent data from being maliciously tampered with, the logic algorithm library can be stored in the blockchain node.

[0197] As can be seen from the above technical solution, the present invention can respond to anomaly handling instructions for a database cluster by starting a first thread to monitor the real-time operating status of the database cluster and obtaining a first monitoring result. At preset time intervals, a second thread is started to monitor the service usage of the database cluster and obtain a second monitoring result. This allows for targeted monitoring of the database cluster from both the database metric and service levels. When anomalies are detected in the first and / or second monitoring results, a target anomaly scenario is determined. Based on the target anomaly scenario, a query is performed in a pre-configured logic algorithm library to obtain the target anomaly handling logic. This effectively avoids the impact of varying personnel skill levels on fault handling results. In response to the impact of the results, when the target anomaly handling logic corresponds to the database's internal self-healing type, the database cluster is subjected to first anomaly handling based on the target anomaly handling logic to obtain a first processing result. When the target anomaly handling logic corresponds to the database cluster's self-healing type, the database cluster is subjected to second anomaly handling based on the target anomaly handling logic to obtain a second processing result. The first processing result and / or the second processing result are sent to a designated terminal, thereby integrating scattered point-like anomaly scenarios into a complete anomaly handling system. This links the entire anomaly handling lifecycle, from monitoring to location to processing to aftercare, providing full lifecycle coverage and effectively improving the efficiency and accuracy of fault handling.

[0198] like Figure 3 The diagram shown is a schematic representation of the structure of a computer device that implements the database cluster exception handling method of the present invention.

[0199] The computer device 1 may include a memory 12, a processor 13 and a bus, and may also include a computer program stored in the memory 12 and executable on the processor 13, such as a database cluster exception handling program.

[0200] Those skilled in the art will understand that the schematic diagram is merely an example of computer device 1 and does not constitute a limitation on computer device 1. Computer device 1 can be either a bus topology or a star topology. Computer device 1 may also include more or fewer other hardware or software than shown in the diagram, or different component arrangements. For example, computer device 1 may also include input / output devices, network access devices, etc.

[0201] It should be noted that the computer device 1 described is merely an example. Other existing or future electronic products that are adaptable to this invention should also be included within the scope of protection of this invention and are incorporated herein by reference.

[0202] The memory 12 includes at least one type of readable storage medium, such as flash memory, portable hard drive, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 12 can be an internal storage unit of the computer device 1, such as a portable hard drive of the computer device 1. In other embodiments, the memory 12 can be an external storage device of the computer device 1, such as a plug-in portable hard drive, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the computer device 1. Furthermore, the memory 12 can include both internal storage units and external storage devices of the computer device 1. The memory 12 can be used not only to store application software and various types of data installed on the computer device 1, such as the code of database cluster exception handling programs, but also to temporarily store data that has been output or will be output.

[0203] In some embodiments, the processor 13 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits packaged with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 13 is the control unit of the computer device 1, connecting various components of the computer device 1 via various interfaces and lines. It executes programs or modules stored in the memory 12 (e.g., executing database cluster exception handling programs) and calls data stored in the memory 12 to perform various functions of the computer device 1 and process data.

[0204] The processor 13 executes the operating system of the computer device 1 and various installed applications. The processor 13 executes the applications to implement the steps in the above-described embodiments of the database cluster exception handling methods, for example... Figure 1 The steps are shown.

[0205] For example, the computer program may be divided into one or more modules / units, which are stored in the memory 12 and executed by the processor 13 to complete the present invention. The one or more modules / units may be a series of computer-readable instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device 1. For example, the computer program may be divided into a monitoring unit 110, a determining unit 111, a querying unit 112, a processing unit 113, and a sending unit 114.

[0206] The integrated unit implemented as a software functional module described above can be stored in a computer-readable storage medium. This software functional module, stored in a storage medium, includes several instructions to cause a computer device (which may be a personal computer, computer equipment, or network device, etc.) or processor to execute portions of the database cluster exception handling methods described in the various embodiments of this invention.

[0207] If the modules / units integrated in the computer device 1 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware devices. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above.

[0208] The computer program includes computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory, etc.

[0209] Furthermore, the computer-readable storage medium may primarily include a stored program area and a stored data area, wherein the stored program area may store the operating system, an application program required for at least one function, etc.; and the stored data area may store data created based on the use of blockchain nodes, etc.

[0210] The blockchain referred to in this invention is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0211] The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, in... Figure 3 The bus is represented by only one straight line, but this does not mean that there is only one bus or one type of bus. The bus is configured to enable communication between the memory 12 and at least one processor 13, etc.

[0212] Although not shown, the computer device 1 may also include a power supply (such as a battery) to power various components. Preferably, the power supply can be logically connected to the at least one processor 13 through a power management device, thereby enabling functions such as charging management, discharging management, and power consumption management. The power supply may also include one or more DC or AC power supplies, recharging devices, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components. The computer device 1 may also include various sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be described in detail here.

[0213] Furthermore, the computer device 1 may also include a network interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), which is typically used to establish a communication connection between the computer device 1 and other computer devices.

[0214] Optionally, the computer device 1 may further include a user interface, which may be a display, an input unit (such as a keyboard), and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the computer device 1 and to display a visual user interface.

[0215] It should be understood that the embodiments described are for illustrative purposes only and are not limited to this structure in the scope of the patent application.

[0216] Figure 3 Only computer device 1 with components 12-13 is shown; those skilled in the art will understand that... Figure 3 The structure shown does not constitute a limitation on the computer device 1, and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0217] Combination Figure 1 The memory 12 in the computer device 1 stores multiple instructions to implement a database cluster exception handling method, and the processor 13 can execute the multiple instructions to achieve the following:

[0218] In response to an exception handling command for the database cluster, the first thread is started to monitor the real-time running status of the database cluster and obtain the first monitoring result.

[0219] At preset time intervals, a second thread is started to perform service usage detection and monitoring on the database cluster, and a second monitoring result is obtained.

[0220] When the first monitoring result and / or the second monitoring result are detected to be abnormal, the target abnormal scenario is determined;

[0221] Based on the target anomaly scenario, a query is performed in a pre-configured logic algorithm library to obtain the target anomaly handling logic;

[0222] When the target anomaly handling logic corresponds to the database internal self-healing type, the database cluster is subjected to first anomaly handling based on the target anomaly handling logic to obtain a first processing result.

[0223] When the target anomaly handling logic corresponds to the database cluster self-healing type, the database cluster is subjected to second anomaly handling based on the target anomaly handling logic to obtain the second processing result.

[0224] Send the first processing result and / or the second processing result to the designated terminal.

[0225] Specifically, the processor 13's implementation method for the above instructions can be found in [reference needed]. Figure 1 The descriptions of the relevant steps in the corresponding embodiments are not repeated here.

[0226] It should be noted that all the data involved in this case was legally obtained.

[0227] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0228] This invention can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

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

[0230] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0231] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0232] Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within the invention. No appended diagram markings in the claims should be construed as limiting the scope of the claims.

[0233] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices described in this invention can also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

[0234] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A database cluster exception handling method, characterized by, The database cluster exception processing method comprises: In response to an exception processing instruction for a database cluster, a first thread is started to perform real-time running state monitoring on the database cluster to obtain a first monitoring result; Every preset time period, a second thread is started to perform service usage side alive monitoring on the database cluster to obtain a second monitoring result; When the first monitoring result and / or the second monitoring result is detected as abnormal, a target exception scenario is determined; According to the target exception scenario, a target exception processing logic is obtained by querying a preconfigured logic algorithm library, wherein the logic algorithm library is stored in a blockchain node; When the target exception processing logic corresponds to a database internal self-healing type, a first exception processing is performed on the database cluster based on the target exception processing logic to obtain a first processing result; When the target exception processing logic corresponds to a database cluster self-healing type, a second exception processing is performed on the database cluster based on the target exception processing logic to obtain a second processing result; The first processing result and / or the second processing result is sent to a specified terminal; The real-time running state monitoring on the database cluster to obtain the first monitoring result comprises: A database in a service is obtained from the database cluster as a target database, and a target database set is constructed based on the target database; The running state of each target database in the target database set is collected in real time; A preconfigured database index is obtained, and a risk threshold of each database index is obtained; The real-time value of each database index corresponding to each target database is determined according to the running state of each target database; When it is detected that the real-time value of a database index is greater than the risk threshold of the detected database index, the detected database index is determined as an abnormal index, and the target database corresponding to the abnormal index is determined as a first abnormal database, and the first monitoring result is generated according to the first abnormal database and the abnormal index, wherein the first monitoring result is abnormal; or When it is detected that the real-time value of a database index is not greater than the risk threshold of the detected database index, it is determined that the first monitoring result is normal; The database index includes, but is not limited to, a set of one or more of the following indexes: CPU usage, memory occupancy, active session quantity, redo quantity, undo quantity; The service usage side alive monitoring on the database cluster to obtain the second monitoring result comprises: A set of tasks to be monitored is obtained, and the operation of each task to be monitored on the database cluster is simulated; When it is detected that a task to be monitored returns an exception, the detected task to be monitored is determined as an abnormal task, and a database executing the abnormal task is determined as a second abnormal database, and the second monitoring result is generated according to the second abnormal database and the abnormal task, wherein the second monitoring result is abnormal; or When it is detected that no task to be monitored returns an exception, it is determined that the second monitoring result is normal; The task set to be monitored includes a charge top-up task and a financial product purchase task.

2. The database cluster exception handling method of claim 1, wherein, Before querying the pre-configured logic algorithm library according to the target abnormal scenario, the method further comprises: obtaining historical abnormal data of the database cluster; extracting abnormal scenarios and corresponding abnormal processing logics from the historical abnormal data, and determining a mapping relationship between the abnormal scenarios and the corresponding abnormal processing logics; establishing at least one fault model based on the abnormal scenarios and the corresponding abnormal processing logics and the mapping relationship; receiving uploaded supplementary mapping relationships, and establishing at least one supplementary fault model according to the supplementary mapping relationships; writing the at least one fault model and the at least one supplementary fault model into the logic algorithm library.

3. The database cluster exception handling method of claim 1, wherein, The first abnormal processing based on the target abnormal processing logic on the database cluster includes: obtaining an abnormal database from the database cluster; performing a load reduction operation on the abnormal database until the abnormal database returns to normal, to obtain the first processing result.

4. The database cluster exception handling method of claim 1, wherein, The second abnormal processing based on the target abnormal processing logic on the database cluster includes: obtaining an abnormal database from the database cluster, and obtaining a standby database corresponding to the abnormal database from the database cluster; determining the standby database as a master database, and replacing the abnormal database to provide services.

5. The database cluster exception handling method of claim 4, wherein, After determining the standby database as the master database and replacing the abnormal database to provide services, the method further comprises: configuring a standby database for the master database; synchronizing data in the master database to the standby database.

6. A database cluster abnormality processing apparatus characterized by comprising: The database cluster abnormal processing apparatus comprises: a monitoring unit configured to start a first thread to perform real-time running state monitoring on the database cluster in response to an abnormal processing instruction of the database cluster, to obtain a first monitoring result; the monitoring unit is further configured to start a second thread to perform service usage side alive monitoring on the database cluster every preset time period, to obtain a second monitoring result; a determination unit configured to determine a target abnormal scenario when detecting that the first monitoring result and / or the second monitoring result is abnormal; a query unit configured to query a pre-configured logic algorithm library according to the target abnormal scenario, to obtain a target abnormal processing logic; wherein the logic algorithm library is stored in a block chain node; a processing unit configured to perform first abnormal processing on the database cluster based on the target abnormal processing logic when the target abnormal processing logic corresponds to a database internal self-healing type, to obtain a first processing result; the processing unit is further configured to perform second abnormal processing on the database cluster based on the target abnormal processing logic when the target abnormal processing logic corresponds to a database cluster self-healing type, to obtain a second processing result; a sending unit configured to send the first processing result and / or the second processing result to a designated terminal; the real-time running state monitoring on the database cluster to obtain the first monitoring result includes: obtaining a database in service from the database cluster as a target database, and constructing a target database set based on the target database; collecting a running state of each target database in the target database set in real time; obtaining a pre-configured database index, and obtaining a risk threshold of each database index; determining a real-time value of each database index corresponding to each target database according to the running state of each target database; when it is detected that the real-time value of a database index is greater than the risk threshold of the detected database index, determining the detected database index as an abnormal index, and determining a target database corresponding to the abnormal index as a first abnormal database, and generating the first monitoring result according to the first abnormal database and the abnormal index, wherein the first monitoring result is abnormal; or when it is not detected that the real-time value of a database index is greater than the risk threshold of the detected database index, determining that the first monitoring result is normal; wherein the database index includes, but is not limited to, a set of one or more of the following indexes: CPU usage, memory occupancy, active session quantity, redo quantity, undo quantity; the service usage side live monitoring of the database cluster to obtain a second monitoring result includes: obtaining a set of tasks to be monitored, and simulating an operation of each task to be monitored in the set of tasks to be monitored on the database cluster; when it is detected that an abnormal task is returned, determining the detected task to be monitored as an abnormal task, and determining a database executing the abnormal task as a second abnormal database, and generating the second monitoring result according to the second abnormal database and the abnormal task, wherein the second monitoring result is abnormal; or when it is not detected that an abnormal task is returned, determining that the second monitoring result is normal; wherein the set of tasks to be monitored includes a top-up task and a financial product purchase task.

7. A computer device, characterized by The computer device includes: a memory storing at least one instruction; and a processor executing the instruction stored in the memory to implement the database cluster abnormal processing method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer readable storage medium stores at least one instruction, and the at least one instruction is executed by the processor in the computer device to implement the database cluster abnormal processing method according to any one of claims 1 to 5.

Images