Methods, devices, and readable storage media for fault diagnosis and mitigation of multi-cloud databases

Abstract

This application proposes a method, apparatus, and readable storage medium for fault diagnosis and mitigation of multi-cloud databases. The method includes: acquiring alarm events from the multi-cloud database and extracting the public cloud vendor identifier, instance identifier, database type, and fault type; matching the Model Context Protocol (MTP) service endpoint to obtain the status data of the target instance; performing format conversion and normalization on the status data to obtain a standardized fault dataset; inputting the standardized fault dataset into a preset expert rule base for feature matching to obtain preliminary root cause judgment results; calling the operation and maintenance execution tool through the MTP service endpoint to perform mitigation operations; acquiring the post-execution status data of the target instance, comparing the post-execution status data with the fault time data and preset benchmark data in the standardized fault dataset, and triggering secondary diagnosis or generating a closed-loop report based on the comparison results. This application achieves efficient database fault handling through the Model Context Protocol.

Description

Technical Field

[0001] This invention relates to the field of intelligent database operation and maintenance technology, and more specifically, to a method, apparatus, and readable storage medium for fault diagnosis and damage mitigation of multi-cloud databases. Background Technology

[0002] In related technologies, common multi-cloud database fault operation and maintenance solutions often employ large models to directly connect to the database interfaces of various cloud vendors to handle faults. However, this technology suffers from inconsistent interface specifications among public cloud vendors, high adaptation costs, a lack of standardized mechanisms for fault data collection, and the risk of credential leakage and unauthorized access when directly calling large models. This leads to cumbersome cross-cloud operation and maintenance adaptation, low fault collection efficiency, significant security risks in AI-based operation and maintenance, and uncontrollable automated operations. Consequently, it is not conducive to achieving efficient diagnosis and safe loss mitigation of database faults in a multi-cloud environment, and it cannot form a closed-loop processing system. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art or related art.

[0004] Therefore, the first aspect of the present invention proposes a method for fault diagnosis and loss mitigation of multi-cloud databases.

[0005] A second aspect of the present invention provides an apparatus for fault diagnosis and loss mitigation of multi-cloud databases.

[0006] A third aspect of the present invention provides another device for fault diagnosis and loss prevention in multi-cloud databases.

[0007] The fourth aspect of this application proposes a readable storage medium.

[0008] In view of this, the first aspect of the present invention provides a method for fault diagnosis and mitigation of multi-cloud databases, comprising: acquiring alarm events of multi-cloud databases; extracting the public cloud vendor identifier, instance identifier, database type, and fault type of the target instance from the alarm events; matching the corresponding Model Context Protocol (MTP) service endpoint in pre-built service registration information according to the public cloud vendor identifier and database type, and calling the status query tool and / or diagnostic analysis tool corresponding to the target instance through the MTP service endpoint to obtain the status data of the target instance at the time of the fault; performing format conversion and normalization processing on the status data to obtain a standardized fault dataset; and inputting the standardized fault dataset into a preset expert rule base for feature matching to obtain a preliminary root cause judgment. The system analyzes the results and inputs the standardized fault dataset and preliminary root cause judgment results into a preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data. The graded loss prevention plan data is then sent to the interactive terminal. Based on the risk level corresponding to the graded loss prevention plan data, a valid confirmation threshold is determined. When the received confirmation instruction meets the valid confirmation threshold, the operation and maintenance execution tool is invoked through the model context protocol service endpoint to execute the loss prevention operation corresponding to the graded loss prevention plan data. After the loss prevention operation is executed, the post-execution status data of the target instance is obtained. This post-execution status data is compared with the fault time data in the standardized fault dataset and preset benchmark data. Based on the comparison results, secondary diagnosis is triggered or a closed-loop report is generated.

[0009] In this application, a multi-cloud database refers to a hybrid operating environment that simultaneously uses multiple types of database services, such as relational databases, cached databases, and non-relational databases, provided by two or more public cloud vendors. Alarm events are prompts generated by the monitoring platform in response to abnormal database instance operation. The public cloud vendor identifier is used to distinguish different public cloud service providers, such as Cloud Service Platform A, Cloud Service Platform B, and Cloud Service Platform C. The instance identifier is used to uniquely identify the faulty database instance. The database type is used to distinguish different database categories, such as MySQL, Redis, MongoDB, and GaussDB. Fault types include high Central Processing Unit (CPU) load, memory overflow, sudden increase in connection count, slow Structured Query Language (SMQ) backlog, and lock waits. The ModelContext Protocol (MTP) service endpoint is a standardized calling interface based on the MTP, corresponding to a single cloud vendor and a single database type. The status query tool is used to collect basic data such as instance operating status, resource utilization, and topology information. Diagnostic analysis tools are used to analyze performance issues such as slow Structured Query Language (SMQL), lock waiting, transaction blocking, and abnormal connection counts. Status data is a collection of database operating metrics, log information, and architectural information at the time of a failure. Standardized fault datasets are standardized data obtained by uniformly formatting heterogeneous data from different vendors and data types. The expert rule base is a set of rapid judgment rules for different fault types, formed based on database operation and maintenance experience. The Large Language Model is an AI model compatible with the Model Context Protocol, capable of data analysis and root cause reasoning. Fault root cause analysis results are conclusions drawn after accurately locating the cause of the fault. Tiered loss prevention plan data consists of loss prevention operation plans categorized according to operational risk levels, including execution steps and rollback schemes. Interactive terminals are web pages, WeChat Work, YouKong, or mobile devices that provide operation and maintenance personnel with plan display and command input. Risk levels are classified as low, medium, and high risk based on the degree of operational impact. Valid confirmation thresholds are the confirmation conditions required to allow the execution of loss prevention operations. A confirmation command is an execution permission command issued by authorized operations and maintenance personnel. Operations and maintenance execution tools are standardized tools used to perform operations such as terminating sessions, optimizing indexes, restarting instances, and modifying configurations. Damage control operations are operations used to eliminate faults and restore normal database operation. Post-execution status data is instance runtime data re-collected after the damage control operation is completed. Fault-time data is abnormal data collected when the fault occurred.The preset baseline data is the standard state data when the database is running normally. Secondary diagnosis is a diagnostic process restarted when the initial loss mitigation fails to meet expectations. The closed-loop report is an archived file recording the entire fault handling process. This application achieves the technical effects of rapid fault location, safe execution, and efficient recovery for multi-cloud databases by sequentially executing alarm information extraction, Model Context Protocol (MTP) service endpoint matching, state data retrieval, data normalization processing, joint diagnosis using expert rules and a Large Language Model (MLM), hierarchical confirmation execution, execution result comparison, and closed-loop processing. It shields the differences in interface specifications, parameter formats, and authentication methods between multiple cloud vendors through a unified MTP interface, eliminating the cumbersome issues of cross-cloud adaptation. Standardized data collection ensures complete and usable fault information, avoiding diagnostic biases caused by missing key data. A human-machine collaboration mechanism avoids risks such as accidental data deletion and incorrect master-slave switching caused by uncontrolled automated operations. The closed-loop process enables the accumulation and reuse of fault handling experience. This achieves the technical effects of rapid fault location, safe execution, and efficient recovery for multi-cloud databases, while reducing cross-cloud adaptation costs, shortening the mean time to repair (MTBT), improving diagnostic accuracy, and avoiding high-risk misoperations.

[0010] In some technical solutions of this application, the Model Context Protocol (MGP) service endpoint is built based on a three-layer encapsulation architecture, which includes: a vendor interface adaptation layer, used to perform differentiated adaptation to the database management interfaces of multiple public cloud vendors, and to encrypt and isolate the interface access credentials and database access credentials of each public cloud vendor; a capability abstraction layer, used to abstract database operation and maintenance operations into standardized atomic capability commands that are independent of public cloud vendors, and to perform legality verification and risk level determination of the execution parameters of the standardized atomic capability commands; and a standard protocol layer, which serves as the external interaction entry point, used to receive tool call requests that conform to the MGP specification, complete protocol parsing and caller authentication, and return a response that conforms to the MGP specification to the caller.

[0011] In the above technical solution, the three-layer encapsulation architecture is the core architecture for achieving unified and secure multi-cloud interface calls. The vendor interface adaptation layer is responsible for connecting to the native application programming interfaces (APIs) of various cloud vendors and encrypting and storing keys. The capability abstraction layer is responsible for converting vendor-differentiated operations into general atomic instructions. The standard protocol layer is responsible for providing a unified and standardized call entry point to the outside world. This application adopts a three-layer encapsulation architecture of vendor interface adaptation layer, capability abstraction layer, and standard protocol layer. By isolating sensitive credentials at the bottom layer, it prevents upper-layer modules from accessing keys, thus eliminating the risk of credential leakage from the architecture. By shielding vendor differences at the middle layer, it converts differentiated operation and maintenance operations into unified instructions. By providing standard interfaces at the top layer, it eliminates the need for upper-layer systems to be concerned with the underlying implementation. This achieves the effect of encapsulating multi-cloud database operation and maintenance interfaces once and ensuring full cloud compatibility. At the same time, it improves system security and compatibility. When adding new cloud vendors or database types, only the adaptation layer needs to be extended to complete the access, shortening the adaptation cycle from weeks to hours.

[0012] In some technical solutions of this application, the status query tool and / or diagnostic analysis tool corresponding to the target instance are called through the Model Context Protocol (MTP) server endpoint to obtain the status data of the target instance at the time of the fault. This includes: matching the corresponding collection rule template from a preset collection rule template library according to the fault type, wherein the collection rule template defines the collection dimension and collection priority corresponding to the fault type; based on the collection rule template, calling the corresponding status query tool and / or diagnostic analysis tool according to the collection priority through the MTP server endpoint to collect the status data of the target instance; and performing integrity verification on the collected status data. If it is determined that there is missing data, supplementary collection is triggered through the MTP server endpoint.

[0013] In the above technical solution, the data acquisition rule template library is a set of pre-configured data acquisition rules according to different fault types. The acquisition dimension refers to the data category to be acquired, the acquisition priority refers to the order in which data is acquired, the integrity check is used to determine whether the core data is complete, and the supplementary acquisition is used to complete missing data. This application achieves faster, more complete, and more accurate fault data acquisition by matching acquisition rule templates according to fault type, acquiring data according to priority, and performing integrity checks and supplementary acquisition. By accurately acquiring core data that is highly relevant to the fault, it reduces invalid acquisition and redundant processing, avoids the time-consuming and resource-wasting nature of indiscriminate full acquisition, and ensures that key fault information is not missing through integrity checks, providing reliable support for subsequent diagnosis. This results in faster, more complete, and more accurate fault data acquisition, reducing data acquisition time from tens of minutes of manual operation to less than thirty seconds.

[0014] In this technical solution, when the fault type is high load on the Central Processing Unit, the system prioritizes collecting details of slow Structured Query Language (SML), long transaction information, and lock wait information; when the fault type is a sudden increase in the number of connections, the system prioritizes collecting connection source, connection status, and active session information; when data verification finds that the SML records are incomplete, the system automatically starts the supplementary collection process to ensure that the fault scene is complete and usable.

[0015] In some technical solutions of this application, a standardized fault dataset is input into a preset expert rule base for feature matching to obtain preliminary root cause judgment results. The standardized fault dataset and the preliminary root cause judgment results are then input into a preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data. This includes: inputting the standardized fault dataset into the expert rule base for feature matching to obtain preliminary root cause judgment results; inputting the standardized fault dataset, the preliminary root cause judgment results, and a preset operation and maintenance knowledge base corresponding to the database type of the target instance into the large language model; validating the preliminary root cause judgment results by the large language model; if the validation results show that the preliminary root cause judgment results do not cover all abnormal features in the standardized fault dataset, supplementary status data is obtained by calling a supplementary data acquisition tool through the model context protocol service endpoint, and fault root cause analysis results are generated based on the supplementary status data and the standardized fault dataset; matching a preset loss prevention strategy template based on the fault root cause analysis results, and determining graded loss prevention plan data according to the pre-configured risk level in the loss prevention strategy template.

[0016] In the above technical solution, the operation and maintenance knowledge base is a collection of knowledge storing operation and maintenance experience and fault handling solutions for various types of databases. The preliminary root cause judgment result verification is a process in which the Large Language Model reviews and verifies the output results of expert rules. Anomaly features are key indicators in the data that reflect the cause of the fault. Supplementary data acquisition tools are used to obtain deeper-dimensional fault information. The loss-stopping strategy template is a loss-stopping plan template preset according to the risk level. This application first uses an expert rule base to quickly screen and obtain preliminary root causes, giving full play to the advantage of the fast speed of rule diagnosis. Then, the Large Language Model is used for verification, supplementary data collection, and deep reasoning to make up for the shortcomings of rules in covering long-tail faults. Combining the efficiency of the rule base and the generalization ability of the Large Language Model, the model autonomously calls tools to supplement data, making the diagnostic basis more sufficient. This achieves the effect of more accurate fault root cause location, more comprehensive coverage of scenarios, and more executable contingency plans. It can not only ensure the rapid location of common faults, but also handle complex long-tail faults, with an overall diagnostic accuracy rate of over 95%.

[0017] In this technical solution, when the MySQL (MyStructured Query Language) instance experiences high central processing unit (CPU) load, expert rules initially determine that it is caused by slow Structured Query Language (SQL). Further verification by the Large Language Model reveals an abnormal increase in the number of connections. By supplementing the data collection tools to obtain idle connection data, the root cause is ultimately determined to be a combination of slow Structured Query Language (SQL) and idle long connections. Based on this, two levels of stop-loss plans, low-risk and medium-risk, are generated.

[0018] In some technical solutions of this application, risk levels are pre-classified into low-risk, medium-risk, and high-risk levels; the effective confirmation threshold is determined based on the risk level corresponding to the tiered stop-loss plan data, including: when the risk level corresponding to the tiered stop-loss plan data is low-risk, the effective confirmation threshold is determined to be the receipt of one confirmation instruction; when the risk level corresponding to the tiered stop-loss plan data is medium-risk, the effective confirmation threshold is determined to be the receipt of one confirmation instruction associated with a first permission identifier, where the first permission identifier represents the user identity with advanced database management privileges; when the risk level corresponding to the tiered stop-loss plan data is high-risk, the effective confirmation threshold is determined to be the receipt of at least two confirmation instructions, and at least one of the at least two confirmation instructions is associated with the first permission identifier.

[0019] In the above technical solutions, low-risk operations have minimal impact on business operations, medium-risk operations have some impact, and high-risk operations may have a significant impact on data or business operations. The first-level permission identifier is used to mark senior operations and maintenance personnel with advanced management privileges. This application sets differentiated confirmation thresholds according to low-risk, medium-risk, and high-risk levels. It improves execution efficiency by simplifying low-risk operation processes and reducing unnecessary approval steps. By strengthening the control of permissions for medium- and high-risk operations, requiring senior personnel to confirm or multiple people to review, it effectively avoids secondary failures caused by misjudgment or misoperation, achieving a balance between operational efficiency and operational safety, completely eliminating the security risks caused by uncontrolled automation, and reducing the mis-execution rate of high-risk operations to zero.

[0020] In this technical solution, slow Structured Query Language (SCL) detection and removal is a low-risk operation that can be executed with single-person confirmation; SCL rate limiting and index management are medium-risk operations that require confirmation from senior operations personnel; instance restart, data recovery, and instance expansion are high-risk operations that must be reviewed by at least two people, including senior operations personnel, before they can be executed.

[0021] In some technical solutions of this application, the tool invocation process initiated through the Model Context Protocol (MCP) service endpoint is audited and recorded. The audit record includes the invocation time, the type of tool invoked, the invocation parameters, and the execution result. After generating a closed-loop report, the closed-loop report is stored in a preset operation and maintenance knowledge base. The identification information of the successfully executed loss-stopping operation and the trigger record information of the secondary diagnosis are extracted from the closed-loop report. Based on the extracted identification information of the loss-stopping operation and the trigger record information of the secondary diagnosis, the rule configuration contained in the preset expert rule base and the preset prompt template corresponding to the alarm type are updated.

[0022] In the aforementioned technical solution, audit logs are tamper-proof log information that leaves a complete trace of tool calls; the operations and maintenance knowledge base is used to archive fault handling experience; the identification information for loss-stopping operations is used to mark effective operations that have been executed; the trigger record information for secondary diagnosis is used to record scenarios where diagnosis is insufficient; the rule configuration is the judgment logic of the expert rule base; and the preset prompt template is a reference template for diagnosis by the Large Language Model. This application, by auditing and recording the entire process of tool calls, makes each call traceable and verifiable, meeting the enterprise's compliance and security control requirements. By updating the expert rule base and prompt templates based on closed-loop reports, historical fault handling experience is transformed into reusable capabilities for the system. Through continuous optimization of diagnostic logic and loss-stopping strategies, the system continuously improves diagnostic accuracy and processing efficiency during continuous operation, achieving the effect of continuous self-improvement of system capabilities and increasingly accurate and efficient fault handling.

[0023] In this technical solution, the system compiles weekly statistics on the processing results of various alarms, elevates loss-stopping solutions that have been successful multiple times to priority recommended solutions, and adds check items that frequently trigger secondary diagnostics to the priority check process, thereby further improving the speed of handling similar faults in the future.

[0024] In some technical solutions of this application, obtaining the status data of the target instance at the time of failure includes at least one of the following data acquisition operations: obtaining the basic operating data of the target instance at the time of failure, including CPU utilization, memory utilization, disk utilization, and number of connections; obtaining the performance diagnostic data of the target instance at the time of failure, including details and execution plans of slow structured query language statements, lock wait information, and transaction blocking information; obtaining the abnormal log data of the target instance at the time of failure, including database error logs and alarm logs; and obtaining the topology data of the target instance at the time of failure, including master-slave synchronization status and cluster sharding status.

[0025] In the aforementioned technical solution, basic operational data reflects the overall resource consumption of the database instance, performance diagnostic data reflects performance bottlenecks and blocking issues, anomaly log data reflects system errors and abnormal events, and topology data reflects the cluster structure and synchronization health status. This application collects basic operational data, performance diagnostic data, anomaly log data, and topology data simultaneously or separately. By comprehensively acquiring fault scene information from four dimensions—resource load, performance blocking, system logs, and architecture status—it avoids judgment biases caused by single-dimensional data, providing complete, multi-dimensional data support for root cause analysis. This makes the diagnostic reasoning process more rigorous, the conclusions more reliable, and achieves the effects of more sufficient diagnostic basis, more accurate root cause location, and more reasonable solution formulation.

[0026] In this technical solution, when a master-slave synchronization anomaly occurs in the database, the system simultaneously collects topology data, basic operational data, and transaction blocking data, making a comprehensive judgment from three levels: architecture status, resource load, and business blocking, to avoid misjudgment caused by a single data point.

[0027] A second aspect of the present invention provides an apparatus for fault diagnosis and mitigation of multi-cloud databases, comprising: an acquisition module, a determination module, a standardization module, a matching module, an execution module, and a processing module. The acquisition module is used to acquire alarm events from the multi-cloud database, and extract the public cloud vendor identifier, instance identifier, database type, and fault type of the target instance from the alarm events. The determination module is used to match the corresponding Model Context Protocol (MTP) service endpoint in pre-built service registration information based on the public cloud vendor identifier and database type, and to call the status query tool and / or diagnostic analysis tool corresponding to the target instance through the MTP service endpoint to obtain the status data of the target instance at the time of the fault. The standardization module is used to perform format conversion and normalization processing on the status data to obtain a standardized fault dataset. The matching module is used to input the standardized fault dataset into a preset expert rule base for feature matching to obtain a preliminary root cause judgment result, and to process the standardized fault data. The fault dataset and preliminary root cause judgment results are input into a preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data. The execution module is used to send the graded loss prevention plan data to the interactive terminal, determine the effective confirmation threshold according to the risk level corresponding to the graded loss prevention plan data, and when the received confirmation instruction meets the effective confirmation threshold, call the operation and maintenance execution tool through the model context protocol service endpoint to execute the loss prevention operation corresponding to the graded loss prevention plan data. The processing module is used to obtain the post-execution status data of the target instance after the loss prevention operation is executed, compare the post-execution status data with the fault time data in the standardized fault dataset and the preset benchmark data, and trigger secondary diagnosis or generate a closed-loop report based on the comparison results.

[0028] This application achieves multi-cloud database fault alarm parsing, standardized model context protocol invocation, fault data normalization processing, joint diagnosis of expert rules and large language models, hierarchical permission confirmation and execution, and closed-loop verification of loss mitigation effect through the coordinated operation of acquisition, determination, standardization, matching, execution, and processing modules. It can effectively reduce the interface adaptation cost in multi-cloud environments, improve the efficiency of fault data collection and the accuracy of root cause diagnosis, and avoid automated misoperation through permission control and closed-loop execution, thus significantly improving the security, efficiency and stability of multi-cloud database fault handling.

[0029] A third aspect of the present invention provides an apparatus for multi-cloud database fault diagnosis and loss mitigation, comprising: a processor and a memory, wherein the memory stores a program or instructions, and the processor, when executing the program or instructions in the memory, implements the steps of the multi-cloud database fault diagnosis and loss mitigation method as described in any of the above-described technical solutions. Therefore, the apparatus for multi-cloud database fault diagnosis and loss mitigation possesses all the beneficial effects of the multi-cloud database fault diagnosis and loss mitigation method as described in any of the above-described technical solutions.

[0030] A fourth aspect of the present invention provides a readable storage medium storing a program or instructions, which, when executed by a processor, implement the steps of the multi-cloud database fault diagnosis and mitigation method as described in any of the above-described technical solutions. Therefore, the readable storage medium possesses all the beneficial effects of the multi-cloud database fault diagnosis and mitigation method as described in any of the above-described technical solutions.

[0031] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0032] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0033] Figure 1 This is one of the flowcharts illustrating a method for fault diagnosis and loss mitigation in a multi-cloud database according to an embodiment of the present invention;

[0034] Figure 2 This is a second flowchart illustrating a method for fault diagnosis and loss mitigation in a multi-cloud database according to an embodiment of the present invention.

[0035] Figure 3 This is a layered architecture diagram of a multi-cloud database fault intelligent diagnosis and loss mitigation system based on Model Context Protocol (MCP) according to an embodiment of the present invention;

[0036] Figure 4 This is one of the schematic block diagrams of a device for multi-cloud database fault diagnosis and loss prevention according to an embodiment of the present invention;

[0037] Figure 5 This is a second schematic block diagram of a device for fault diagnosis and loss mitigation of multi-cloud databases according to an embodiment of the present invention. Detailed Implementation

[0038] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0039] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0040] The following reference Figures 1 to 5This invention describes a method, apparatus, and readable storage medium for fault diagnosis and mitigation of multi-cloud databases according to some embodiments of the present invention.

[0041] like Figure 1 As shown, embodiments of this application provide a method for fault diagnosis and mitigation in multi-cloud databases, comprising the following steps:

[0042] Step 102: Obtain alarm events for the multi-cloud database, and extract the public cloud vendor identifier, instance identifier, database type, and fault type of the target instance from the alarm events;

[0043] Step 104: Based on the public cloud vendor identifier and database type, match the corresponding model context protocol service endpoint in the pre-built service registration information, and call the status query tool and / or diagnostic analysis tool corresponding to the target instance through the model context protocol service endpoint to obtain the status data of the target instance at the time of the failure.

[0044] Step 106: Perform format conversion and normalization on the status data to obtain a standardized fault dataset;

[0045] Step 108: Input the standardized fault dataset into the preset expert rule base for feature matching to obtain preliminary root cause judgment results. Input the standardized fault dataset and preliminary root cause judgment results into the preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data.

[0046] Step 110: Send the tiered stop-loss plan data to the interactive terminal, determine the effective confirmation threshold based on the risk level corresponding to the tiered stop-loss plan data, and when the received confirmation instruction meets the effective confirmation threshold, call the operation and maintenance execution tool through the model context protocol service endpoint to execute the stop-loss operation corresponding to the tiered stop-loss plan data.

[0047] Step 112: After the stop-loss operation is executed, obtain the post-execution status data of the target instance, compare the post-execution status data with the fault time data and preset benchmark data in the standardized fault dataset, and trigger secondary diagnosis or generate a closed-loop report based on the comparison results.

[0048] In this application, a multi-cloud database refers to a hybrid operating environment that simultaneously uses multiple types of database services, such as relational databases, cached databases, and non-relational databases, provided by two or more public cloud vendors. Alarm events are prompts generated by the monitoring platform in response to abnormal database instance operation. The public cloud vendor identifier is used to distinguish different public cloud service providers, such as Cloud Service Platform A, Cloud Service Platform B, and Cloud Service Platform C. The instance identifier is used to uniquely identify the faulty database instance. The database type is used to distinguish different database categories, such as MySQL, Redis, MongoDB, and GaussDB. Fault types include high Central Processing Unit (CPU) load, memory overflow, sudden increase in connection count, slow Structured Query Language (SMQ) backlog, and lock waits. The ModelContext Protocol (MTP) service endpoint is a standardized calling interface based on the MTP, corresponding to a single cloud vendor and a single database type. The status query tool is used to collect basic data such as instance operating status, resource utilization, and topology information. Diagnostic analysis tools are used to analyze performance issues such as slow Structured Query Language (SMQL), lock waiting, transaction blocking, and abnormal connection counts. Status data is a collection of database operating metrics, log information, and architectural information at the time of a failure. Standardized fault datasets are standardized data obtained by uniformly formatting heterogeneous data from different vendors and data types. The expert rule base is a set of rapid judgment rules for different fault types, formed based on database operation and maintenance experience. The Large Language Model is an AI model compatible with the Model Context Protocol, capable of data analysis and root cause reasoning. Fault root cause analysis results are conclusions drawn after accurately locating the cause of the fault. Tiered loss prevention plan data consists of loss prevention operation plans categorized according to operational risk levels, including execution steps and rollback schemes. Interactive terminals are web pages, WeChat Work, YouKong, or mobile devices that provide operation and maintenance personnel with plan display and command input. Risk levels are classified as low, medium, and high risk based on the degree of operational impact. Valid confirmation thresholds are the confirmation conditions required to allow the execution of loss prevention operations. A confirmation command is an execution permission command issued by authorized operations and maintenance personnel. Operations and maintenance execution tools are standardized tools used to perform operations such as terminating sessions, optimizing indexes, restarting instances, and modifying configurations. Damage control operations are operations used to eliminate faults and restore normal database operation. Post-execution status data is instance runtime data re-collected after the damage control operation is completed. Fault-time data is abnormal data collected when the fault occurred.The preset baseline data is the standard state data when the database is running normally. Secondary diagnostics is a diagnostic process restarted when the initial loss mitigation fails to meet expectations. The closed-loop report is an archived file recording the entire fault handling process. This application achieves rapid fault location, secure execution, and efficient recovery for multi-cloud databases by sequentially executing alarm information extraction, Model Context Protocol (MTP) service endpoint matching, status data retrieval, data normalization processing, joint diagnosis using expert rules and a large language model, hierarchical confirmation execution, execution result comparison, and closed-loop processing. It eliminates the cumbersome cross-cloud adaptation issues by using a unified MTP interface to shield the differences in interface specifications, parameter formats, and authentication methods between multiple cloud vendors. Standardized data collection ensures complete and usable fault information, preventing diagnostic biases caused by missing critical data. A human-machine collaboration mechanism avoids risks such as accidental data deletion and incorrect master-slave switching caused by uncontrolled automated operations. The closed-loop process allows for the accumulation and reuse of fault handling experience. This results in reduced cross-cloud adaptation costs, shortened mean time to repair (MTTR), improved diagnostic accuracy, and prevention of high-risk misoperations.

[0049] Specifically, extracting the public cloud vendor identifier, instance identifier, database type, and fault type of the target instance from the alarm event refers to extracting the public cloud vendor identifier, instance identifier, database type, and fault type of the target instance from the alarm event. These four pieces of information are attributes of the target database instance itself that experienced the fault. The public cloud vendor identifier is used to determine the cloud service provider to which the target instance belongs; the instance identifier is used to uniquely identify the target instance; the database type is used to determine the database category of the target instance; and the fault type is used to determine the specific type of anomaly that occurred to the target instance.

[0050] In some embodiments of this application, the Model Context Protocol (MGP) service endpoint is built on a three-layer encapsulation architecture, which includes: a vendor interface adaptation layer, used to perform differentiated adaptation to the database management interfaces of multiple public cloud vendors, and to encrypt and isolate the interface access credentials and database access credentials of each public cloud vendor; a capability abstraction layer, used to abstract database operation and maintenance operations into standardized atomic capability commands that are independent of public cloud vendors, and to perform legality verification and risk level determination of the execution parameters of the standardized atomic capability commands; and a standard protocol layer, which serves as the external interaction entry point, used to receive tool call requests that conform to the MGP specification, complete protocol parsing and caller authentication, and return a response that conforms to the MGP specification to the caller.

[0051] In the above embodiments, the three-layer encapsulation architecture is the core architecture for achieving unified and secure multi-cloud interface calls. The vendor interface adaptation layer is responsible for connecting to the native application programming interfaces (APIs) of various cloud vendors and encrypting and storing keys. The capability abstraction layer is responsible for converting vendor-differentiated operations into general atomic instructions. The standard protocol layer is responsible for providing a unified and standardized call entry point to the outside world. This application, by adopting a three-layer encapsulation architecture of vendor interface adaptation layer, capability abstraction layer, and standard protocol layer, isolates sensitive credentials at the bottom layer, preventing upper-layer modules from accessing keys and eliminating the risk of credential leakage from the architecture. By shielding vendor differences at the middle layer, it converts differentiated operation and maintenance operations into unified instructions. By providing standard interfaces at the top layer, it eliminates the need for upper-layer systems to concern themselves with the underlying implementation. This achieves the effect of encapsulating multi-cloud database operation and maintenance interfaces once and ensuring full cloud compatibility. At the same time, it improves system security and compatibility. When adding new cloud vendors or database types, only the adaptation layer needs to be extended to complete the access, shortening the adaptation cycle from weekly to hourly.

[0052] In some embodiments of this application, the status data of the target instance at the time of the fault is obtained by calling the status query tool and / or diagnostic analysis tool corresponding to the target instance through the Model Context Protocol (MTP) service endpoint. This includes: matching the corresponding collection rule template from a preset collection rule template library according to the fault type, wherein the collection rule template defines the collection dimension and collection priority corresponding to the fault type; based on the collection rule template, calling the corresponding status query tool and / or diagnostic analysis tool according to the collection priority through the MTP service endpoint to collect the status data of the target instance; and performing integrity verification on the collected status data, and triggering supplementary collection through the MTP service endpoint when it is determined that there is missing data.

[0053] In the above embodiments, the data acquisition rule template library is a set of pre-configured data acquisition rules according to different fault types. The acquisition dimension refers to the data category to be acquired, the acquisition priority refers to the order in which data is acquired, the integrity check is used to determine whether the core data is complete, and the supplementary acquisition is used to complete missing data. This application achieves faster, more complete, and more accurate fault data acquisition by matching acquisition rule templates according to fault type, acquiring data according to priority, and performing integrity checks and supplementary acquisition. By accurately acquiring core data that is highly related to the fault, it reduces invalid acquisition and redundant processing, avoids the time-consuming and resource-wasting nature of full-volume indiscriminate acquisition, and ensures that key fault information is not missing through integrity checks, providing reliable support for subsequent diagnosis. This results in faster, more complete, and more accurate fault data acquisition, reducing data acquisition time from tens of minutes of manual operation to less than thirty seconds.

[0054] In this embodiment, when the fault type is high load on the Central Processing Unit, the system prioritizes collecting details of slow Structured Query Language (SML), long transaction information, and lock wait information; when the fault type is a sudden increase in the number of connections, the system prioritizes collecting connection source, connection status, and active session information; when data verification finds that the SML records are incomplete, the system automatically starts the supplementary collection process to ensure that the fault scene is complete and usable.

[0055] In some embodiments of this application, a standardized fault dataset is input into a preset expert rule base for feature matching to obtain preliminary root cause judgment results. The standardized fault dataset and the preliminary root cause judgment results are then input into a preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data. This includes: inputting the standardized fault dataset into the expert rule base for feature matching to obtain preliminary root cause judgment results; inputting the standardized fault dataset, the preliminary root cause judgment results, and a preset operation and maintenance knowledge base corresponding to the database type of the target instance into the large language model; validating the preliminary root cause judgment results by the large language model; if the validation results show that the preliminary root cause judgment results do not cover all abnormal features in the standardized fault dataset, supplementary status data is obtained by calling a supplementary data acquisition tool through the model context protocol service endpoint, and fault root cause analysis results are generated based on the supplementary status data and the standardized fault dataset; matching a preset loss prevention strategy template based on the fault root cause analysis results, and determining graded loss prevention plan data according to the pre-configured risk level in the loss prevention strategy template.

[0056] In the above embodiments, the operation and maintenance knowledge base is a knowledge collection storing operation and maintenance experience and fault handling solutions for various types of databases. The preliminary root cause judgment result verification is a process in which the Large Language Model reviews and verifies the output results of expert rules. Anomaly features are key indicators in the data that reflect the cause of the fault. Supplementary data acquisition tools are used to obtain deeper-dimensional fault information. The loss-stopping strategy template is a loss-stopping plan template preset according to the risk level. This application first uses an expert rule base to quickly screen and obtain preliminary root causes, giving full play to the advantage of fast rule diagnosis. Then, the Large Language Model is used for verification, supplementary data collection, and deep reasoning to make up for the shortcomings of rules in covering long-tail faults. Combining the efficiency of the rule base and the generalization ability of the Large Language Model, the model autonomously calls tools to supplement data, making the diagnostic basis more sufficient. This achieves the effect of more accurate fault root cause location, more comprehensive coverage of scenarios, and more executable contingency plans. It can not only ensure the rapid location of common faults, but also handle complex long-tail faults, with an overall diagnostic accuracy rate of over 95%.

[0057] In this embodiment, when the MySQL (MyStructured Query Language) instance experiences high central processing unit (CPU) load, expert rules initially determine that it is caused by slow Structured Query Language (SQL). Further verification by the Large Language Model reveals an abnormal increase in the number of connections. By supplementing the collection tools to obtain idle connection data, the root cause is finally determined to be caused by both slow Structured Query Language (SQL) and idle long connections. Based on this, two levels of loss mitigation plans, low-risk and medium-risk, are generated.

[0058] In some embodiments of this application, risk levels are pre-classified into low-risk, medium-risk, and high-risk levels. Determining an effective confirmation threshold based on the risk level corresponding to the tiered stop-loss plan data includes: when the risk level corresponding to the tiered stop-loss plan data is low-risk, the effective confirmation threshold is determined to be receiving one confirmation instruction; when the risk level corresponding to the tiered stop-loss plan data is medium-risk, the effective confirmation threshold is determined to be receiving one confirmation instruction associated with a first permission identifier, where the first permission identifier represents a user identity with advanced database management privileges; when the risk level corresponding to the tiered stop-loss plan data is high-risk, the effective confirmation threshold is determined to be receiving at least two confirmation instructions, and at least one of the at least two confirmation instructions includes a confirmation instruction associated with the first permission identifier.

[0059] In the above embodiments, low-risk operations have minimal impact on business operations, medium-risk operations have some impact on business operations, and high-risk operations may have a significant impact on data or business operations. The first permission identifier is used to mark senior operations and maintenance personnel with advanced management privileges. This application sets differentiated confirmation thresholds according to low-risk, medium-risk, and high-risk levels. It improves execution efficiency by simplifying low-risk operation processes and reducing unnecessary approval steps. By strengthening the control of permissions for medium- and high-risk operations, requiring senior personnel to confirm or multiple people to review, it effectively avoids secondary failures caused by misjudgment or misoperation, achieving a balance between operations and maintenance efficiency and operational safety. It completely eliminates the security risks caused by uncontrolled automation and reduces the misexecution rate of high-risk operations to zero.

[0060] In this embodiment, slow Structured Query Language (SCL) detection and removal is a low-risk operation that can be executed with single-person confirmation; SCL rate limiting and index management are medium-risk operations that require confirmation from senior operations and maintenance personnel; instance restart, data recovery, and instance expansion are high-risk operations that must be reviewed by at least two people, including senior operations and maintenance personnel, before they can be executed.

[0061] In some embodiments of this application, the tool invocation process initiated through the Model Context Protocol (MCP) service endpoint is audited and recorded. The audit record includes the invocation time, the type of tool invoked, the invocation parameters, and the execution result. After generating a closed-loop report, the closed-loop report is stored in a preset operation and maintenance knowledge base. The identification information of the successfully executed loss-stopping operation and the trigger record information of the secondary diagnosis are extracted from the closed-loop report. Based on the extracted identification information of the loss-stopping operation and the trigger record information of the secondary diagnosis, the rule configurations contained in the preset expert rule base and the preset prompt templates corresponding to the alarm types are updated.

[0062] In the above embodiments, the audit log is an immutable log information that leaves a complete trace of tool calls; the operation and maintenance knowledge base is used to archive fault handling experience; the identification information of loss-stopping operations is used to mark effective operations that have been executed; the trigger record information of secondary diagnosis is used to record scenarios where diagnosis is insufficient; the rule configuration is the judgment logic of the expert rule base; and the preset prompt template is a reference template for diagnosis by the Large Language Model. This application, by auditing and recording the entire process of tool calls, makes each call traceable and verifiable, meeting the enterprise's compliance and security control requirements. By updating the expert rule base and prompt templates based on closed-loop reports, historical fault handling experience is transformed into reusable capabilities of the system. By continuously optimizing the diagnostic logic and loss-stopping strategies, the system continuously improves diagnostic accuracy and processing efficiency during continuous operation, achieving the effect of continuous self-improvement of system capabilities and increasingly accurate and efficient fault handling.

[0063] In this embodiment, the system compiles weekly statistics on the processing results of various alarms, elevates loss mitigation solutions that have been successfully implemented multiple times to priority recommended solutions, and adds check items that frequently trigger secondary diagnostics to the priority check process, thereby further improving the speed of handling similar faults in the future.

[0064] In some embodiments of this application, obtaining the target instance's status data at the time of failure includes at least one of the following data acquisition operations: obtaining the target instance's basic operational data at the time of failure, including CPU utilization, memory utilization, disk utilization, and number of connections; obtaining the target instance's performance diagnostic data at the time of failure, including details and execution plans of slow structured query language statements, lock wait information, and transaction blocking information; obtaining the target instance's abnormal log data at the time of failure, including database error logs and alarm logs; and obtaining the target instance's topology data at the time of failure, including master-slave synchronization status and cluster sharding status.

[0065] In the above embodiments, basic operational data reflects the overall resource consumption of the database instance, performance diagnostic data reflects performance bottlenecks and blocking issues, anomaly log data reflects system errors and abnormal events, and topology data reflects the cluster structure and synchronization health status. This application collects basic operational data, performance diagnostic data, anomaly log data, and topology data simultaneously or separately. By comprehensively acquiring fault scene information from four dimensions—resource load, performance blocking, system logs, and architecture status—it avoids judgment biases caused by single-dimensional data, providing complete, multi-dimensional data support for root cause analysis. This makes the diagnostic reasoning process more rigorous, the conclusions more reliable, and achieves the effects of more sufficient diagnostic basis, more accurate root cause location, and more reasonable solution formulation.

[0066] In this embodiment, when a master-slave synchronization anomaly occurs in the database, the system simultaneously collects topology data, basic operational data, and transaction blocking data, making a comprehensive judgment from three levels: architecture status, resource load, and business blocking, to avoid misjudgment caused by a single data point.

[0067] like Figure 2 As shown, the method for multi-cloud database fault diagnosis and loss mitigation in this application also includes:

[0068] Step 202: MCP interface encapsulation, multi-cloud OpenAPI standardization;

[0069] Step 204: Alarm monitoring and parsing, extracting instance metadata;

[0070] Step 206: Standardize data collection by calling the MCP toolset;

[0071] Step 208: Intelligent root cause analysis to generate a stop-loss plan;

[0072] Step 210: Human-machine confirmation execution is automated after DBA confirmation;

[0073] Step 212: Close the loop for effect verification, archive, and iterative optimization;

[0074] Step 214: Determine the effect verification result. If the result is yes, proceed to step 216; if the result is no, proceed to copy 206.

[0075] Step 216: The knowledge base is continuously iterated.

[0076] In conclusion, Figure 2 This document fully demonstrates the closed-loop logic of multi-cloud database fault diagnosis and mitigation. The process starts from the "Start" node, first executing step 202. Based on the Model Context Protocol (MCP), it uniformly encapsulates the Open APIs (APIs) of databases from different public cloud vendors, achieving standardized adaptation of multi-cloud interfaces. This shields the differences in interface specifications, parameter formats, and authentication methods among vendors, solving the core technical problem of interface fragmentation in multi-cloud environments from an architectural perspective, laying the foundation for unified calls throughout the subsequent process. Then, step 204 is executed, where the system listens for and parses fault alarm events, extracting core instance metadata such as the public cloud vendor identifier, instance identifier, database type, and fault type of the target fault instance. This completes the precise location of the fault object, ensuring that subsequent operations are executed accurately on the target instance.

[0077] Next, in step 206, the system, based on the extracted instance metadata, calls the corresponding MCP toolset, such as status query tools and diagnostic analysis tools, through the encapsulated MCP interface to complete the standardized collection of the target instance's status data at the time of failure. Simultaneously, it can match collection rule templates according to the fault type, collect core data according to priority, and perform integrity verification and supplementary collection to ensure uniform data format, completeness, and usability, avoiding invalid data collection and significantly improving collection efficiency. After collection, in step 208, the system inputs the standardized fault dataset into a preset expert rule base for feature matching to obtain preliminary root cause judgment results. Then, the dataset, preliminary root cause judgment results, and the corresponding database type of operation and maintenance knowledge base are input into a preset large language model. The model verifies the preliminary root cause and autonomously calls supplementary tools to complete the data, completing deep reasoning and generating accurate fault root cause analysis results and tiered loss mitigation plan data. Combining the efficiency of expert rules with the generalization of the large language model improves the accuracy of root cause diagnosis and covers long-tail fault scenarios.

[0078] Next, in step 210, the system sends the tiered loss prevention plan data to the interactive terminal. Based on the risk level (low, medium, high) of the plan, differentiated effective confirmation thresholds are determined. Low-risk operations require only single-person confirmation, medium-risk operations require confirmation from a senior DBA (Database Administrator), and high-risk operations require confirmation from at least two people, including a senior DBA. After the confirmation command meets the threshold, the system calls the operation and maintenance execution tool through the MCP server endpoint to automatically execute the corresponding loss prevention operation, achieving a balance between operation and maintenance efficiency and operational safety, and completely avoiding uncontrolled automated erroneous operations. After execution, step 212 is executed. The system collects the post-execution status data of the target instance, compares it with the data at the time of the failure and preset benchmark data to verify the effect, and simultaneously audits and archives the entire process of tool calls, providing data support for subsequent iterations and optimizations.

[0079] Then, step 214 is executed to verify the effect. If the result is "no" (i.e., the stop loss did not meet expectations), the process jumps to step 206 to re-initiate standardized data collection and subsequent diagnostic processes, triggering a second diagnosis. If the result is "yes" (i.e., the stop loss was successful), the process proceeds to step 216 for continuous iteration of the knowledge base. The closed-loop report of this fault, the identification information of the successfully executed stop loss operation, and the secondary diagnosis trigger record information are stored in the operation and maintenance knowledge base. Based on this, the rule configuration of the expert rule base and the preset prompt template of the large language model are updated to realize the accumulation of operation and maintenance experience and the continuous optimization of system capabilities. Finally, the process is closed with the "end" node, forming a full lifecycle fault handling system from alarm triggering, diagnosis, execution, verification to iteration. This effectively reduces the interface adaptation cost in a multi-cloud environment, shortens the average fault recovery time, and improves the security, efficiency, and stability of fault handling.

[0080] This embodiment provides a method for fault diagnosis and mitigation of multi-cloud databases, applicable to enterprise operation and maintenance scenarios where multiple public cloud vendors' databases are deployed simultaneously. The specific execution process is as follows:

[0081] 1. MCP Interface Standardization and Encapsulation: The system pre-constructs a three-layer encapsulation architecture based on the Model Context Protocol (MCP). Through the vendor interface adaptation layer, it performs differentiated adaptation for the database management interfaces of various cloud vendors, and stores the interface access credentials and database access credentials in encrypted isolation. Through the capability abstraction layer, it abstracts database operation and maintenance operations into standardized atomic capability commands that are independent of cloud vendors, and performs parameter legality verification and risk level determination. Through the standard protocol layer, it provides a unified MCP call entry point to the outside world, completes protocol parsing and identity authentication, realizes the standardized encapsulation of multi-cloud OpenAPI, and completes step 202.

[0082] 2. Alarm Listening and Metadata Extraction: When a MySQL instance in a multi-cloud environment triggers a high CPU load alarm, the system listens for and parses the alarm event, extracting the public cloud vendor identifier (Cloud Service Platform A), instance identifier (rm-xxxxxx), database type (MySQL), and fault type (high CPU load) of the target instance, thus completing step 204.

[0083] 3. Standardized Data Collection: Based on the extracted metadata, the system matches the corresponding MCP service endpoint, matches the collection template corresponding to high CPU load from the collection rule template library according to the fault type, and calls the slow SQL analysis tool, lock wait analysis tool, and status query tool according to priority to collect the target instance's basic operating data (CPU utilization, memory utilization, number of connections), performance diagnostic data (slow SQL details, execution plan, lock wait information), abnormal log data (error log), and topology data (master-slave synchronization status). The system also performs integrity verification on the collected data. If any data is missing, supplementary collection is triggered, completing step 206.

[0084] 4. Intelligent Root Cause Analysis and Contingency Plan Generation: The system performs format conversion and normalization on the collected status data to obtain a standardized fault dataset. The dataset is then input into the expert rule base for feature matching, and the root cause is initially determined to be slow SQL accumulation. The dataset, the preliminary root cause, and the MySQL operation and maintenance knowledge base are then input into the large language model. Model verification reveals that the abnormal increase in connection count is not covered. The system uses MCP to call the supplementary data acquisition tool to collect idle connection data. Finally, it is determined that the root cause is caused by both slow SQL and idle long connections. Based on the root cause matching stop-loss strategy template, a two-level stop-loss plan is generated: low-risk (terminating idle long connections) and medium-risk (optimizing slow SQL indexes). Step 208 is completed.

[0085] 5. Human-Machine Confirmation and Automated Execution: The system sends the tiered loss prevention plan to the DBA operation and maintenance interaction terminal. Low-risk operations require confirmation from only one ordinary DBA, while medium-risk operations require confirmation from one senior DBA. After the confirmation command meets the valid confirmation threshold, the system calls the operation and maintenance execution tool through the MCP service endpoint to sequentially execute the loss prevention operations of terminating idle long connections and optimizing slow SQL indexes, thus completing step 210.

[0086] 6. Effect Verification and Closed-Loop Archiving: After the stop-loss operation is completed, the system re-collects the post-execution status data of the target instance, compares it with the data at the time of the failure and the preset benchmark data (CPU utilization ≤70%, number of connections ≤500), calculates the difference value, and at the same time audits and records the entire process of tool calls, recording the call time, tool type, parameters and execution results, and completes step 212.

[0087] 7. Effect verification result judgment: The system determines that after execution, the CPU utilization and number of connections have returned to the baseline range, and the difference value is less than the preset recovery threshold. The loss stop is successful, and step 214 is completed.

[0088] 8. Continuous iteration of the knowledge base: The system generates a fault closed-loop report, stores the report in the operation and maintenance knowledge base, extracts the stop-loss operation identifier and secondary diagnosis trigger record of this successful execution, updates the diagnostic rules for high CPU load in the expert rule base, optimizes the diagnostic prompt template of the large language model, sets the termination of idle long connections as the priority stop-loss strategy for high CPU load, completes step 216, and the process ends.

[0089] like Figure 3 As shown, Figure 3 This is a layered architecture diagram of a multi-cloud database fault intelligent diagnosis and loss mitigation system based on the Model Context Protocol (MCP). From bottom to top, the system consists of a multi-cloud database resource layer, an MCP interface encapsulation layer, a data acquisition layer, an alarm monitoring layer, an intelligent diagnostic analysis layer, and a human-computer interaction layer. The multi-cloud database resource layer supports multiple cloud database service platforms. The MCP interface encapsulation layer deploys an MCP interface encapsulation module to achieve multi-cloud adaptation, standardized encapsulation, access control, and end-to-end auditing. The data acquisition layer deploys a standardized data acquisition module that can automatically call MCP tools to collect data based on alarms. The alarm monitoring layer deploys an alarm monitoring and parsing module that can connect to Prometheus / Zabbix / cloud vendor monitoring systems. The intelligent diagnostic analysis layer integrates a DBA expert rule base and an MCP-compatible big oracle model inference unit to achieve dual-track intelligent fault diagnosis and loss mitigation plan generation. The top-level human-computer interaction layer provides three interaction entry points: a web console, a service app, and WeChat Work, allowing operations and maintenance personnel to view diagnostic results, confirm loss mitigation operations, and manage the system.

[0090] like Figure 4As shown, an embodiment of this application provides a device 300 for multi-cloud database fault diagnosis and mitigation, including: an acquisition module 310, a determination module 320, a standardization module 330, a matching module 340, an execution module 350, and a processing module 360. The acquisition module 310 is used to acquire alarm events of the multi-cloud database, and extract the public cloud vendor identifier, instance identifier, database type, and fault type of the target instance from the alarm events; the determination module 320 is used to match the corresponding Model Context Protocol (MCP) service endpoint in pre-built service registration information according to the public cloud vendor identifier and database type, and call the status query tool and / or diagnostic analysis tool corresponding to the target instance through the MCP service endpoint to obtain the status data of the target instance at the time of the fault; the standardization module 330 is used to perform format conversion and normalization processing on the status data to obtain a standardized fault dataset; the matching module 340 is used to input the standardized fault dataset into a preset expert rule base for feature matching to obtain a preliminary root cause judgment result, and then... The standardized fault dataset and preliminary root cause judgment results are input into a preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data. The execution module 350 is used to send the graded loss prevention plan data to the interactive terminal, determine the effective confirmation threshold according to the risk level corresponding to the graded loss prevention plan data, and when the received confirmation instruction meets the effective confirmation threshold, call the operation and maintenance execution tool through the model context protocol service endpoint to execute the loss prevention operation corresponding to the graded loss prevention plan data. The processing module 360 ​​is used to obtain the post-execution status data of the target instance after the loss prevention operation is executed, compare the post-execution status data with the fault time data in the standardized fault dataset and the preset benchmark data, and trigger secondary diagnosis or generate a closed-loop report based on the comparison results.

[0091] This application, through the coordinated operation of the acquisition module 310, determination module 320, standardization module 330, matching module 340, execution module 350, and processing module 360, achieves multi-cloud database fault alarm parsing, standardized calling of model context protocol, normalization processing of fault data, joint diagnosis of expert rules and large language model, hierarchical permission confirmation and execution, and closed-loop verification of loss mitigation effect. It can effectively reduce the interface adaptation cost in multi-cloud environments, improve the efficiency of fault data collection and the accuracy of root cause diagnosis, and avoid automated misoperation through permission control and closed-loop execution, thus significantly improving the security, efficiency, and stability of multi-cloud database fault handling.

[0092] like Figure 5As shown, an embodiment of this application provides a multi-cloud database fault diagnosis and mitigation apparatus 400, including a processor 402 and a memory 404. The memory 404 stores a program or instructions. When the processor 402 executes the program or instructions in the memory 404, it implements the steps of the multi-cloud database fault diagnosis and mitigation method as described in any of the above embodiments. Therefore, the multi-cloud database fault diagnosis and mitigation apparatus 400 possesses all the beneficial effects of the multi-cloud database fault diagnosis and mitigation method as described in any of the above embodiments.

[0093] Embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the multi-cloud database fault diagnosis and mitigation method as described in any of the above embodiments. Therefore, the readable storage medium possesses all the beneficial effects of the multi-cloud database fault diagnosis and mitigation method as described in any of the above embodiments.

[0094] Specifically, in the scheme of this application, the rule configuration structure is as follows: alarm name maps to the corresponding diagnostic processing function chain.

[0095] typeRuleConfigmap[string][]HandleFunc;

[0096] / / Configure the diagnostic strategy for MySQL database alerts var MySQLRules=RuleConfig{

[0097] common.ALERT_NAME_CPU:[]HandleFunc{AlarmSummary,Grafana,QueryCost,LongTransaction,TableLocked,StaticSlowQueries,AssetInfo},

[0098] common.ALERT_NAME_MEM:[]HandleFunc{AlarmSummary,Grafana,QueryCost,LongTransaction,TableLocked,StaticSlowQueries,AssetInfo},

[0099] common.ALERT_NAME_DISK:[]HandleFunc{AlarmSummary,Grafana,TableDisk,AssetInfo},

[0100] common.ALERT_NAME_SLOW:[]HandleFunc{AlarmSummary,Grafana,QueryCost,LongTransaction,TableLocked,StaticSlowQueries,LargeTransaction,AssetInfo},

[0101] common.ALERT_NAME_CONN:[]HandleFunc{AlarmSummary,Grafana,QueryCost,Connections,TableLocked,AssetInfo},

[0102] / / Rules for other alarm types are omitted;

[0103] }

[0104] / / Configure the diagnostic strategy for alerts corresponding to the MongoDB database;

[0105] varMongoDBRules=RuleConfig{

[0106] common.ALERT_NAME_CPU:[]HandleFunc{AlarmSummary,Grafana,CurrentOp,AssetInfo},

[0107] common.ALERT_NAME_MEM:[]HandleFunc{AlarmSummary,Grafana,CurrentOp,MetaSchema,AssetInfo},

[0108] / / Rules for other alarm types are omitted;

[0109] }

[0110] / / Rules for other database types are omitted;

[0111] The above content is the core configuration structure code of the expert rule base, defining the type RuleConfig as a mapping from alarm names to processing function chains. For different alarm types such as high CPU load, memory overflow, high disk I / O (Input / Output), slow SQL backlog, and sudden increase in connection count, the MySQL database is configured with an ordered call chain consisting of processing functions such as AlarmSummary, Grafana, QueryCost, LongTransaction, and TableLocked. The MongoDB database is configured with dedicated function chains such as CurrentOp and MetaSchema based on its operational characteristics. Each processing function corresponds to a standardized MCP collection or diagnostic tool. When the corresponding alarm is triggered, the system automatically calls the corresponding tool in the chain order to complete data collection and preliminary analysis, thereby outputting preliminary root cause judgment results within 20 to 30 seconds. This provides a fast and reliable foundation for subsequent deep inference using large language models, demonstrating the efficient linkage between expert rules and large model dual-track diagnostic mechanisms and the native integration of standardized tools in this invention.

[0112] This embodiment takes an enterprise that simultaneously uses three types of multi-cloud databases—A cloud service platform PolarDB, B cloud service platform TynosDB, and C cloud service platform GaussDB—as an example to illustrate the complete implementation process of the multi-cloud database fault diagnosis and loss mitigation method provided in this application.

[0113] In the initial stage of system deployment, a standardized encapsulation system for multi-cloud operation and maintenance capabilities based on the Model Context Protocol (MCP) is first constructed. System administrators use the MCP interface to encapsulate modules and adapt and encapsulate the database management application programming interfaces of three public cloud service platforms: A Cloud Service Platform, B Cloud Service Platform, and C Cloud Service Platform. The encapsulation process employs a three-layer architecture: In the vendor interface adaptation layer, adaptation logic is written for the DAS interface of PolarDB on cloud service platform A, the CynosDB interface of TynosDB on cloud service platform B, and the native management interface of GaussDB on cloud service platform C. The interface access credentials and database access credentials of each vendor are encrypted using the AES-256 algorithm and stored locally in this layer. In the capability abstraction layer, database operation and maintenance operations such as instance status query, slow structured query language analysis, lock wait analysis, session termination, index optimization, and instance restart are abstracted into standardized atomic capability commands independent of cloud vendors. Parameter validity verification rules and risk level judgment rules are configured for each atomic capability command. In the standard protocol layer, the above standardized atomic capabilities are registered as tools conforming to the model context protocol specification. Standardized JSONSchema input and output parameter specifications are defined, and the initialization configuration of protocol parsing, caller authentication, and end-to-end audit logs is completed. After encapsulation, each combination of cloud vendor and database category generates an independent model context protocol service endpoint, and the address information of each service endpoint is registered with the service registry center to form service registration information.

[0114] Taking the Structured Query Language (SCL) rate limiting capability as an example, the specific implementation of the above encapsulation process is illustrated. At the vendor interface adaptation layer, the differences between vendors are encapsulated through a unified entry function, SQLFilterProvider: when the passed vendor identifier is Cloud Platform A, the keyword array is concatenated with a tilde and then the DAS rate limiting interface of Cloud Platform A is called; when the vendor identifier is Cloud Platform C, the same tilde concatenation rule is used and the GaussDB rate limiting interface of Cloud Platform C is called; when the vendor identifier is Cloud Platform B, the keyword array is concatenated with a comma and then the CynosDB rate limiting interface of Cloud Platform B is called. The differences in keyword separators between different vendors are encapsulated in the corresponding branch logic, and the upper-layer modules do not need to be aware of them. At the capability abstraction layer, the above rate limiting capability is abstracted into two standardized atomic capabilities, ShowSQLFilter and AddSQLFilter, defining unified input and output parameter specifications across all vendors, and configuring risk classification rules to mark the SCL rate limiting operation as medium-risk, forcibly triggering parameter validation and full-link audit marking. At the standard protocol layer, the above two atomic capabilities are registered as tools conforming to the model context protocol standard, exposing a unified calling interface to the outside world. After encapsulation, the structured query language rate limiting capability can be encapsulated once and reused across the entire cloud. When adding a new cloud vendor, only the corresponding branch needs to be added to the adaptation layer, shortening the adaptation cycle from weekly to hourly. At the same time, the interface access credentials of each cloud vendor are only stored in the vendor interface adaptation layer. The standard protocol layer and capability abstraction layer cannot access sensitive credentials at all, thus eliminating the risk of credential leakage from the architecture.

[0115] The alarm listening layer deployed on the cloud service node receives an alarm event from the Prometheus monitoring system via Webhook. The alarm content is: "The CPU utilization of PolarDB instance mysql-instance-01 on Cloud Service Platform A has consistently exceeded 90% for 5 minutes." The alarm listening layer performs deduplication and classification processing on this alarm event according to preset alarm filtering rules. After confirming that the alarm meets the preset trigger conditions, it automatically parses the alarm event and extracts the target instance's metadata, including: public cloud vendor identifier "Cloud Service Platform A", instance identifier "mysql-instance-01", database type "MySQL", and fault type "high CPU load". This target instance is the database instance that triggered this fault alarm event and is uniquely identified in the multi-cloud database by the public cloud vendor identifier "Cloud Service Platform A" and the instance identifier "mysql-instance-01".

[0116] After receiving the aforementioned metadata, the data acquisition layer first matches the corresponding Model Context Protocol (MCP) service endpoint address in the service registration information based on the public cloud vendor identifier "A Cloud Service Platform" and the database type "MySQL," and establishes a secure connection with that service endpoint. Simultaneously, based on the fault type "High CPU Load," the data acquisition layer matches the corresponding acquisition rule template from a pre-defined acquisition rule template library. This acquisition rule template defines the core acquisition dimensions and priorities for high CPU load faults: the first priority is slow structured query language analysis, which calls the QueryCost tool to collect details, execution plans, and execution time percentages of slow structured query language statements that take more than 5 seconds to execute during the fault period; the second priority is long transaction analysis, which calls the LongTransaction tool to collect information on long transactions with a duration exceeding 30 seconds among currently active transactions; and the third priority is lock wait analysis, which calls the TableLocked tool to collect information on existing table locks and row lock waits. Following the above priority order, the data acquisition layer sequentially calls the corresponding diagnostic analysis tools through the MCP service endpoint to complete the status data acquisition of the target instance at the time of the fault. After data collection, the system automatically performs integrity checks on the collected status data: checking whether the slow structured query language data covers the 5-minute time windows before and after the fault occurred, whether the long transaction data contains the complete list of active transactions, and whether the lock wait data contains complete blocking link information. The check revealed a 1-minute data gap in the slow structured query language records. The data collection layer immediately triggered a supplementary collection process, re-invoking the QueryCost tool through the model context protocol service endpoint to complete the missing time period. Finally, the data collection layer performs format conversion and normalization on the raw status data obtained from the PolarDB interface of the A cloud service platform, converting the vendor-specific response data into a unified structured format to generate a standardized fault dataset. The entire collection process took approximately 25 seconds, significantly shorter than the 10+ minutes required for traditional manual data collection via the cloud vendor's console.

[0117] After receiving the standardized fault dataset, the intelligent diagnostic analysis layer initiates a dual-track diagnostic process. First, the system inputs the standardized fault dataset into a pre-defined expert rule base for feature matching. The expert rule base uses a mapping configuration mode of "alarm type - processing function chain." For high CPU load alarms in MySQL databases, the pre-defined processing function chain is: AlarmSummary (alarm aggregation), Grafana (trend collection), QueryCost (slow structured query language analysis), LongTransaction (long transaction analysis), TableLocked (lock wait analysis), StaticSlowQueries (slow structured query language statistics), and AssetInfo (instance specification query). The system sequentially calls the corresponding MCP standardization tools to complete data collection and preliminary analysis, then outputs preliminary root cause judgment results: "During the fault period, a total of 12 slow structured query language statements with execution times exceeding 5 seconds were found. Among them, a certain order query statement was executed more than 2300 times, with an average execution time of 8.7 seconds, consuming 76% of CPU resources. The preliminary judgment is that the high CPU load was caused by the slow structured query language." The entire expert rule diagnosis process took approximately 28 seconds.

[0118] Subsequently, the system inputs the standardized fault dataset, preliminary root cause analysis results, and the pre-set operation and maintenance knowledge base corresponding to the MySQL database into the large language model compatible with the model context protocol. The large language model first verifies the preliminary root cause analysis results, confirming that the slow structured query language is the core root cause. However, it also discovers an anomaly in the standardized fault dataset—a 280% increase in connection count compared to the daily baseline—that is not covered by expert rules. The large language model determines that this anomaly may affect the completeness of the root cause analysis and then autonomously calls the Connections connection analysis tool via the model context protocol server endpoint to supplement the collection of active session details for the target instance's database. The supplementary collection results show that approximately 150 idle long-lived connections from the business application server are currently in a dormant state and have not been released for an extended period. The large language model performs deep reasoning analysis based on supplementary state data and standardized fault datasets, ultimately generating the following root cause analysis results: "The high CPU load was caused by a combination of slow structured query language and idle long-lived connection accumulation. Slow structured query language consumed approximately 76% of CPU resources, while idle long-lived connection accumulation occupied approximately 12% of CPU scheduling resources. The combined effect caused CPU utilization to consistently exceed the threshold." The entire deep reasoning process of the large model took approximately 1 minute and 40 seconds.

[0119] Based on the above root cause analysis results, the large language model matches a preset stop-loss strategy template and generates tiered stop-loss contingency plan data according to the pre-configured risk levels in the stop-loss strategy template. This tiered stop-loss contingency plan data includes two stop-loss operation schemes: the low-risk scheme is "terminating idle long-lived connections and optimizing the business connection pool configuration," with specific execution steps including querying the list of idle connections, batch terminating idle sessions, and adjusting the maximum idle time parameter of the business-side connection pool; the rollback scheme is to restore the original connection pool configuration. The medium-risk scheme is "deploying a slow structured query language index optimization scheme," with specific execution steps including analyzing the execution plan of the slow structured query language, creating a targeted composite index, verifying the index's effectiveness, and the rollback scheme is to delete the newly added index.

[0120] The intelligent diagnostic analysis layer generates tiered loss mitigation plan data and sends it to a pre-defined interactive terminal via a message push module, namely the enterprise WeChat maintenance group of the database administrator corresponding to the target instance. The push content is a card-style plan, including a summary of the root cause analysis results, operation details and impact scope of the low-risk plan "Terminate Idle Long Connections", operation details and risk warnings of the medium-risk plan "Optimize Slow Structured Query Language Index", and a confirmation button for each plan.

[0121] The system first processes the low-risk scenario of "terminating idle long connections." Based on the preset risk level classification rules, this operation is classified as low-risk, and the effective confirmation threshold is determined by receiving a confirmation command. After a regular database administrator in the operations and maintenance group clicks the "confirm" button for this scenario, the system receives a confirmation command. After determining that this confirmation command has reached the effective confirmation threshold, the system calls the operations and maintenance execution tool KillIdleConnections through the model context protocol service endpoint to perform the idle connection termination operation on the target instance. During the operation, the system synchronizes the execution progress to the enterprise WeChat operations and maintenance group in real time. After the operation is completed, the system pushes the execution result: "148 idle connections terminated; current connection count restored to normal range."

[0122] Subsequently, the system handles the medium-risk solution, "Slow Structured Query Language Index Optimization." According to the risk level classification rules, this operation corresponds to a medium-risk level. The effective confirmation threshold is determined by receiving a confirmation command associated with a first-level permission identifier, where the first-level permission identifier represents a user with advanced database management privileges. After a senior database administrator in the operations and maintenance group clicks the "Confirm" button for this solution, the system verifies the user's permissions associated with the confirmation command. If the user is confirmed to have the first-level permission identifier, the system determines that the confirmation command has reached the effective confirmation threshold and calls the operations and maintenance execution tool CreateIndex via the Model Context Protocol service endpoint to automatically create a composite index according to the index optimization script in the solution. If a high-risk loss mitigation solution (such as instance restart or data recovery) is executed, the effective confirmation threshold is determined by receiving at least two confirmation commands, and at least one of these two commands must be associated with a first-level permission identifier. This means that at least two database administrators must jointly confirm, and at least one of them must be a senior database administrator, before the system can call the corresponding operations and maintenance execution tool to execute the operation.

[0123] Throughout the entire tool invocation process, the system audits and records every tool invocation initiated through the Model Context Protocol service endpoint. The audit logs include the invocation time (accurate to milliseconds), the type of tool invoked (such as KillIdleConnections, CreateIndex), the invocation parameters (target instance identifier, input parameter values), and the execution result (success or failure, returned data digest). The audit logs are stored with a write protection mechanism and can only be queried by administrators with audit privileges, ensuring that the entire operation is traceable and verifiable.

[0124] After the stop-loss operation was completed, the system again invoked the status query tool through the Model Context Protocol (MTP) service endpoint to re-collect post-execution status data for the target instance "mysql-instance-01," including CPU utilization, memory utilization, connection count, and slow Structured Query Language (SCL) execution statistics. The system compared the post-execution status data with the status data recorded in the standardized fault dataset at the time of the fault and with the preset baseline data. The preset baseline data was the average status data of the instance under normal operating conditions for the same period within the 7 days prior to the fault. The comparison results showed that the CPU utilization had decreased from 94% at the time of the fault to 38%, a deviation of 4 percentage points compared to the preset baseline data of 42%, which was less than the preset recovery threshold of 10 percentage points; the connection count had decreased from 352 at the time of the fault to 178, a deviation of 13 compared to the preset baseline data of 165, which was less than the preset recovery threshold of 50. Since the deviations of each performance indicator were less than the corresponding preset recovery thresholds, the system determined that the stop-loss was successful and the business had resumed normal operation.

[0125] The system integrates all data from the entire fault handling process to generate a closed-loop report, which includes: original alarm event information, extracted target instance metadata, collected standardized fault dataset, preliminary root cause judgment results output by the expert rule base, fault root cause analysis results generated by the large language model, generated tiered loss mitigation plan data, details of received confirmation instructions (confirmer identity, role type, confirmation time), MCP tool call audit records, post-execution status data, and comparison results with baseline data. This closed-loop report is stored in a preset operation and maintenance knowledge base and indexed with tags based on alarm type "CPU high load" and database type "MySQL".

[0126] The system further extracts the identification information of successfully executed stop-loss operations from the closed-loop report, including the identifiers for the "Terminate Idle Long Connections" scheme and the "Create Composite Index" scheme. It also extracts the trigger record information for secondary diagnostics, specifically the diagnostic instruction "Large Language Model calls Connection Count Analysis Tool to Supplement Idle Connection Data Collection." Based on the extracted stop-loss operation identification information, the system calculates the number of times each stop-loss operation is executed and its success rate within a preset period. Stop-loss strategies corresponding to stop-loss operations with an execution count not lower than a preset threshold and an execution success rate not lower than a preset success rate threshold are written into the priority execution module of the diagnostic strategy used by the large language model. Based on the extracted secondary diagnostic trigger record information, the system calculates the diagnostic instruction with the highest trigger frequency for each alarm type and writes "Connection Count Anomaly Analysis" as a priority check item for the "CPU High Load" alarm type into the diagnostic strategy used by the large language model. The updated diagnostic strategy is synchronized to the large language model diagnostic module in real time. When the same type of alarm is triggered again, the large language model will automatically prioritize connection count anomaly checks, reducing the frequency of database administrators manually triggering secondary diagnostics and continuously shortening diagnostic time.

[0127] Through the aforementioned closed-loop process, this embodiment fully demonstrates the entire process from alarm reception, standardized data collection, dual-track intelligent diagnosis, tiered confirmation execution, to effect verification and knowledge base iteration. By unifying the encapsulation of the model context protocol, the interface differences between cloud service platform A (PolarDB), cloud service platform B (TynosDB), and cloud service platform C (GaussDB) are masked, enabling the reuse of a single-encapsulated tool in multi-cloud environments. The adaptive collection mechanism reduces data collection time from tens of minutes of manual operation to less than 30 seconds. Through joint diagnosis using expert rules and a large model, common faults are quickly screened and located within 28 seconds, and deep inference using the large model covers the long-tail fault characteristic of idle long connections, achieving an overall diagnostic accuracy of over 95%. Tiered confirmation thresholds and end-to-end auditing ensure automated loss mitigation while maintaining operational safety and controllability. Closed-loop report archiving and knowledge base iteration distill the experience gained from this fault handling into reusable rule configurations and diagnostic strategies, enabling the system to continuously self-optimize.

[0128] In the claims, description, and accompanying drawings of this invention, the term "plural" refers to two or more. Unless otherwise explicitly defined, the terms "upper," "lower," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and simplifying the descriptive process, and are not intended to indicate or imply that the device or element referred to must have the described specific orientation, or be constructed and operated in a specific orientation. Therefore, these descriptions should not be construed as limiting the invention. The terms "connected," "installed," "fixed," etc., should be interpreted broadly. For example, "connected" can be a fixed connection between multiple objects, a detachable connection between multiple objects, or an integral connection; it can be a direct connection between multiple objects or an indirect connection between multiple objects through an intermediate medium. For those skilled in the art, the specific meaning of the above terms in this invention can be understood based on the specific circumstances described above.

[0129] In the claims, description, and accompanying drawings of this invention, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the invention. In the claims, description, and accompanying drawings of this invention, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0130] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for fault diagnosis and loss mitigation in multi-cloud databases, characterized in that, include: Obtain alarm events for multi-cloud databases, and extract the public cloud vendor identifier, instance identifier, database type, and fault type of the target instance from the alarm events; Based on the public cloud vendor identifier and the database type, the corresponding model context protocol service endpoint is matched in the pre-built service registration information, and the status query tool and / or diagnostic analysis tool corresponding to the target instance is called through the model context protocol service endpoint to obtain the status data of the target instance at the time of failure. The state data is then format-converted and normalized to obtain a standardized fault dataset. The standardized fault dataset is input into a preset expert rule base for feature matching to obtain preliminary root cause judgment results. The standardized fault dataset and the preliminary root cause judgment results are then input into a preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data. The tiered stop-loss plan data is sent to the interactive terminal. A valid confirmation threshold is determined based on the risk level corresponding to the tiered stop-loss plan data. When the received confirmation instruction meets the valid confirmation threshold, the operation and maintenance execution tool is called through the model context protocol service endpoint to execute the stop-loss operation corresponding to the tiered stop-loss plan data. After the stop-loss operation is executed, the post-execution status data of the target instance is obtained, and the post-execution status data is compared with the fault time data and preset benchmark data in the standardized fault dataset. Based on the comparison results, secondary diagnosis is triggered or a closed-loop report is generated.

2. The method according to claim 1, characterized in that, The model context protocol service endpoint is built on a three-layer encapsulation architecture, which includes: The vendor interface adaptation layer is used to adapt to the database management interfaces of multiple public cloud vendors in a differentiated manner, and to encrypt and isolate the interface access credentials and database access credentials of each public cloud vendor for storage. The capability abstraction layer is used to abstract database operation and maintenance operations into standardized atomic capability instructions that are independent of public cloud vendors, and to perform parameter validity verification and risk level determination on the standardized atomic capability instructions. The standard protocol layer serves as the entry point for external interaction. It receives tool call requests that conform to the model context protocol specification, performs protocol parsing and caller authentication, and returns a response that conforms to the model context protocol specification to the caller.

3. The method according to claim 1, characterized in that, The step of calling the status query tool and / or diagnostic analysis tool corresponding to the target instance through the model context protocol service endpoint to obtain the status data of the target instance at the time of the failure includes: Based on the fault type, a corresponding collection rule template is matched from a preset collection rule template library. The collection rule template defines the collection dimension and collection priority corresponding to the fault type. Based on the collection rule template, the corresponding status query tool and / or diagnostic analysis tool are called through the model context protocol service endpoint according to the collection priority to collect the status data of the target instance; The collected status data is verified for integrity. If data is found to be missing, supplementary data collection is triggered through the model context protocol server endpoint.

4. The method according to claim 1, characterized in that, The process involves inputting the standardized fault dataset into a preset expert rule base for feature matching to obtain preliminary root cause judgment results, and then inputting the standardized fault dataset and the preliminary root cause judgment results into a preset large language model to generate fault root cause analysis results and corresponding graded loss prevention plan data, including: The standardized fault dataset is input into the expert rule base for feature matching to obtain the preliminary root cause judgment result; The standardized fault dataset, the preliminary root cause judgment results, and the preset operation and maintenance knowledge base corresponding to the database type of the target instance are input into the large language model; The preliminary root cause judgment result is verified by the large language model. If the verification result shows that the preliminary root cause judgment result does not cover all abnormal features in the standardized fault dataset, the supplementary data acquisition tool is called through the model context protocol service endpoint to obtain supplementary status data, and the fault root cause analysis result is generated based on the supplementary status data and the standardized fault dataset. Based on the results of the root cause analysis of the failure, a preset stop-loss strategy template is matched, and the tiered stop-loss plan data is determined according to the risk level pre-configured in the stop-loss strategy template.

5. The method according to claim 1, characterized in that, The risk levels are pre-classified into low-risk, medium-risk, and high-risk levels. The step of determining the effective confirmation threshold based on the risk level corresponding to the tiered stop-loss plan data includes: When the risk level corresponding to the tiered stop-loss plan data is low-risk, the effective confirmation threshold is determined to be the receipt of a confirmation instruction. When the risk level corresponding to the tiered stop-loss plan data is medium-risk, the effective confirmation threshold is determined to be receiving a confirmation instruction associated with a first permission identifier, whereby the first permission identifier represents the identity of a user with advanced database management privileges. When the risk level corresponding to the tiered stop-loss plan data is high-risk, the effective confirmation threshold is determined to be receiving at least two confirmation instructions, and at least one of the at least two confirmation instructions is associated with the first permission identifier.

6. The method according to claim 1, characterized in that, Also includes: Audit logs are generated for tool calls initiated through the Model Context Protocol service endpoint. The audit logs include the call time, the type of tool called, the call parameters, and the execution result. After generating the closed-loop report, the method further includes: The closed-loop report is stored in a preset operation and maintenance knowledge base; Extract the identification information of the successfully executed stop-loss operation and the trigger record information of the secondary diagnosis from the closed-loop report; Based on the extracted identification information of the stop-loss operation and the trigger record information of the secondary diagnosis, the rule configurations contained in the preset expert rule base and the preset prompt templates corresponding to the alarm types are updated.

7. The method according to any one of claims 1 to 6, characterized in that, The step of obtaining the state data of the target instance at the time of the failure includes at least one of the following data acquisition operations: Obtain the basic operational data of the target instance at the time of the failure, including CPU utilization, memory utilization, disk utilization, and number of connections; Obtain the performance diagnostic data of the target instance at the time of the failure. The performance diagnostic data includes details of slow structured query language statements and execution plans, lock wait information, and transaction blocking information. Obtain the abnormal log data of the target instance at the time of the failure, the abnormal log data including database error logs and alarm logs; Obtain the topology data of the target instance at the time of failure, including the master-slave synchronization status and cluster sharding status.

8. A device for fault diagnosis and loss mitigation in multi-cloud databases, characterized in that, include: The acquisition module is used to acquire alarm events of multi-cloud databases and extract the public cloud vendor identifier, instance identifier, database type and fault type of the target instance from the alarm events; The determination module is used to match the corresponding Model Context Protocol (MTP) service endpoint in the pre-built service registration information based on the public cloud vendor identifier and the database type, and to call the status query tool and / or diagnostic analysis tool corresponding to the target instance through the MTP service endpoint to obtain the status data of the target instance at the time of the failure. The standardization module is used to perform format conversion and normalization processing on the state data to obtain a standardized fault dataset; The matching module is used to input the standardized fault dataset into a preset expert rule base for feature matching to obtain preliminary root cause judgment results, and input the standardized fault dataset and the preliminary root cause judgment results into a preset large language model to generate fault root cause analysis results and graded loss prevention plan data corresponding to the fault root cause analysis results. The execution module is used to send the tiered stop-loss plan data to the interactive terminal, determine the effective confirmation threshold according to the risk level corresponding to the tiered stop-loss plan data, and when the received confirmation instruction meets the effective confirmation threshold, call the operation and maintenance execution tool through the model context protocol service endpoint to execute the stop-loss operation corresponding to the tiered stop-loss plan data. The processing module is used to obtain the post-execution status data of the target instance after the stop-loss operation is executed, compare the post-execution status data with the fault time data and preset benchmark data in the standardized fault dataset, and trigger secondary diagnosis or generate a closed-loop report based on the comparison result.

9. A device for fault diagnosis and loss mitigation in multi-cloud databases, characterized in that, include: processor; A memory, wherein the memory stores programs or instructions, and the processor, when executing the programs or instructions in the memory, implements the steps of the method for multi-cloud database fault diagnosis and loss mitigation as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method for multi-cloud database fault diagnosis and loss mitigation as described in any one of claims 1 to 7.

Images