Multi-node database cluster parameter detection method and related device

Abstract

The embodiment of the invention provides a multi-node database cluster parameter detection method and a related device, and relates to the technical field of databases. The method comprises the following steps: constructing a multi-node parameter value mapping table so as to identify an association relationship between nodes and parameters in the multi-node parameter value mapping table through a unique key; predefining a parameter checking rule set, wherein the parameter checking rule set comprises a parameter consistency requirement and a compliance threshold value; and based on the multi-node parameter value mapping table and the parameter checking rule set, performing comparative analysis on the parameter values of the nodes in the multi-node database cluster, and outputting abnormal information. Based on the method, the detection efficiency and accuracy of multi-node database cluster parameter detection can be improved.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a method and related apparatus for detecting parameters of a multi-node database cluster. Background Technology

[0002] As enterprise applications continue to demand higher data security and high availability, database clusters based on multi-node replication mechanisms are widely used in production systems. These clusters consist of a master node and multiple slave nodes, relying on replication mechanisms to achieve real-time data synchronization and failover, thereby ensuring system continuity and reliability.

[0003] However, in a cluster architecture, the consistency of configuration across nodes is crucial for its normal operation. In actual deployment and maintenance, it is difficult to maintain the consistency of database configuration files, user expectations, and runtime parameters in the long term. Differences in maintenance by different personnel and script deployment can easily lead to omissions, errors, or inconsistent values ​​in configuration items. Dynamic modification of parameters can also disrupt consistency, thereby affecting database operation.

[0004] Existing methods for detecting parameters in multi-node database clusters primarily focus on monitoring node status and replication latency, lacking the ability to automatically check the consistency, integrity, and compliance of configuration parameters. Currently, operations and maintenance mainly rely on manual comparison of parameters node by node. This method is inefficient and inaccurate, unable to distinguish the severity of parameter differences and difficult to adapt to large-scale clusters, making it difficult for operations and maintenance personnel to detect and fix problems in a timely manner. Summary of the Invention

[0005] This application provides a method and related apparatus for detecting parameters of a multi-node database cluster, which can achieve automated detection and improve detection efficiency and accuracy when detecting the consistency and / or compliance threshold range of parameters of a multi-node database cluster.

[0006] In a first aspect, embodiments of this application provide a method for detecting parameters of a multi-node database cluster, the method comprising:

[0007] Construct a multi-node parameter value mapping table to identify the association between nodes and parameters using a unique key;

[0008] A predefined set of parameter checking rules, which includes parameter consistency requirements and compliance thresholds;

[0009] Based on the multi-node parameter value mapping table and parameter checking rule set, the parameter values ​​of each node in the multi-node database cluster are compared and analyzed, and abnormal information is output.

[0010] In one possible implementation, a multi-node parameter value mapping table is constructed, including: generating a unique key based on the combination of node identifier and parameter name, and storing the parameter value corresponding to the parameter name into the unique key;

[0011] A predefined set of parameter checking rules includes: setting consistency requirement types for parameters to be checked for consistency, including mandatory consistency, mandatory inconsistency, and optional consistency; and / or setting compliance threshold ranges for parameters to be checked for compliance, including numerical ranges, unit conversion rules, and format specifications.

[0012] In one possible implementation, based on a multi-node parameter value mapping table and a parameter checking rule set, the parameter values ​​of each node in the multi-node database cluster are compared and analyzed, including:

[0013] Extract the configuration parameter value and runtime parameter value of any parameter from the multi-node parameter value mapping table;

[0014] Compare the configuration parameter value with the running parameter value of any parameter to see if there is a difference;

[0015] If there is a difference between the configuration parameter value and the running parameter value of any parameter, record that parameter as an abnormal parameter, and record the configuration parameter value and the running parameter value of that parameter as abnormal information.

[0016] In one possible implementation, a predefined set of parameter checking rules includes:

[0017] Set compliance threshold ranges for key parameters. The compliance threshold range includes at least one of the following: numerical range, unit conversion rules, and format specifications. Key parameters are parameters in a predefined set of key parameters.

[0018] Based on a multi-node parameter value mapping table and parameter checking rule set, a comparative analysis of parameter values ​​of each node in a multi-node database cluster is performed, including:

[0019] If the value of any key parameter does not meet the compliance threshold range corresponding to that key parameter, then that key parameter is recorded as an abnormal parameter.

[0020] In one possible implementation, a multi-node parameter value mapping table is constructed, including:

[0021] Based on the database types included in the multi-node database cluster, load the corresponding parameter parsing rule base, which includes unit conversion rules and hierarchical structure parsing logic;

[0022] Based on the unit conversion rules and / or hierarchical structure parsing logic in the parameter parsing rule base, construct a multi-node parameter value mapping table.

[0023] In one possible implementation, before comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and parameter checking rule set, the method further includes:

[0024] Create and maintain a parameter change log, which records the target parameters that have changed.

[0025] Based on a multi-node parameter value mapping table and parameter checking rule set, a comparative analysis of parameter values ​​of each node in a multi-node database cluster is performed, including:

[0026] For the target parameter in the parameter change log, the parameter value of the target parameter is compared and analyzed based on the multi-node parameter value mapping table and parameter inspection rule set.

[0027] In one possible implementation, maintaining a parameter change log includes:

[0028] The parameter change log is triggered by modification events in the database transaction log or configuration file, and the change time is recorded in the parameter change log.

[0029] Comparative analysis of the target parameter values ​​is performed, including:

[0030] Based on the change time of the target parameter, filter out the target parameters corresponding to the change time within the preset time period;

[0031] The parameter values ​​of the target parameters are compared and analyzed only for the change time within the preset time period.

[0032] Secondly, embodiments of this application provide a multi-node database cluster parameter detection device, the device comprising:

[0033] The building module is used to construct a multi-node parameter value mapping table, so as to identify the association between nodes and parameters through a unique key in the multi-node parameter value mapping table;

[0034] The predefined module is used to predefine the parameter check rule set, which includes parameter consistency requirements and compliance thresholds;

[0035] The comparison module is used to compare and analyze the parameter values ​​of each node in a multi-node database cluster based on a multi-node parameter value mapping table and a parameter checking rule set, and output anomaly information.

[0036] In one possible implementation, the construction module is specifically used to: generate a unique key based on the combination of node identifier and parameter name, and store the parameter value corresponding to the parameter name into the unique key;

[0037] The predefined module is specifically used to: set the consistency requirement type for parameters that detect consistency, including mandatory consistency, mandatory inconsistency, and optional consistency; and / or to set the compliance threshold range for parameters that detect compliance, including numerical range, unit conversion rules, and format specifications.

[0038] In one possible implementation, the comparison module is specifically used for:

[0039] Extract the configuration parameter value and runtime parameter value of any parameter from the multi-node parameter value mapping table;

[0040] Compare the configuration parameter value with the running parameter value of any parameter to see if there is a difference;

[0041] If there is a difference between the configuration parameter value and the running parameter value of any parameter, record that parameter as an abnormal parameter, and record the configuration parameter value and the running parameter value of that parameter as abnormal information.

[0042] In one possible implementation, the predefined module is specifically used for:

[0043] Set compliance threshold ranges for key parameters. The compliance threshold range includes at least one of the following: numerical range, unit conversion rules, and format specifications. Key parameters are parameters in a predefined set of key parameters.

[0044] The comparison module is specifically used for:

[0045] If the value of any key parameter does not meet the compliance threshold range corresponding to that key parameter, then that key parameter is recorded as an abnormal parameter.

[0046] In one possible implementation, the building module is specifically used for:

[0047] Based on the database types included in the multi-node database cluster, load the corresponding parameter parsing rule base, which includes unit conversion rules and hierarchical structure parsing logic;

[0048] Based on the unit conversion rules and / or hierarchical structure parsing logic in the parameter parsing rule base, construct a multi-node parameter value mapping table.

[0049] In one possible implementation, the device further includes a logging module for:

[0050] Create and maintain a parameter change log, which records the target parameters that have changed.

[0051] The comparison module is specifically used for:

[0052] For the target parameter in the parameter change log, the parameter value of the target parameter is compared and analyzed based on the multi-node parameter value mapping table and parameter inspection rule set.

[0053] In one possible implementation, the logging module is specifically used for:

[0054] The parameter change log is triggered by modification events in the database transaction log or configuration file, and the change time is recorded in the parameter change log.

[0055] The comparison module is specifically used for:

[0056] Based on the change time of the target parameter, filter out the target parameters corresponding to the change time within the preset time period;

[0057] The parameter values ​​of the target parameters are compared and analyzed only for the change time within the preset time period.

[0058] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0059] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0060] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0061] The multi-node database cluster parameter detection method and related apparatus provided in this application address the problems of low efficiency and poor accuracy in parameter consistency detection in multi-node database clusters by constructing a multi-node parameter value mapping table and a rule set. The multi-node parameter value mapping table identifies the association between nodes and parameters through unique keys, enabling efficient parameter retrieval and avoiding the inefficient operation of manual line-by-line comparison. The predefined parameter check rule set allows the system to automatically identify the types of parameter differences and differentiate the severity of differences through tiered warnings based on compliance thresholds, helping to guide maintenance personnel to prioritize high-risk issues. Therefore, the method provided in this application can improve the detection efficiency and accuracy of multi-node database cluster parameter detection. Attached Figure Description

[0062] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0063] Figure 1 A flowchart illustrating the multi-node database cluster parameter detection method provided in this application embodiment. Figure 1 ;

[0064] Figure 2 A flowchart illustrating the multi-node database cluster parameter detection method provided in this application embodiment. Figure 2 ;

[0065] Figure 3 A schematic diagram of the parameter comparison process provided in the embodiments of this application;

[0066] Figure 4 A schematic diagram of a node parameter value mapping table provided in an embodiment of this application;

[0067] Figure 5 This is a schematic diagram of the structure of the multi-node database cluster parameter detection device provided in the embodiments of this application;

[0068] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0069] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0070] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0071] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0072] In the embodiments of this application, the use of terms such as "first" and "second" is to distinguish between identical or similar items that have essentially the same function and effect. For example, "first electronic device" and "second electronic device" are merely used to distinguish different electronic devices and do not limit their order of execution. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0073] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0074] In enterprise applications, with the exponential growth of data volume and the increasing demands for business continuity, multi-node database clusters have become the core architecture for ensuring data security and high availability. Such clusters typically consist of a master node (master database) and multiple slave nodes (standby databases), achieving real-time data synchronization, failover, and load balancing through master-slave replication mechanisms.

[0075] For example, in critical business systems such as finance, telecommunications, and e-commerce, database clusters need to maintain high concurrency processing capabilities for extended periods while ensuring data consistency and disaster recovery. However, in actual deployment and operation, the configuration parameters of each node in the cluster (such as database running parameters, memory allocation strategies, log configurations, etc.) must remain highly consistent; otherwise, replication delays, data synchronization failures, or even cluster crashes may occur.

[0076] For example, if the "maximum number of connections" parameter of the master node is inconsistent with the configuration of the slave nodes, it may cause resource overload on the slave nodes; if the "log file path" parameter is missing or misspelled on some nodes, it will directly result in the inability to generate logs, affecting troubleshooting. In addition, dynamic modification of parameters (such as temporary adjustment of parameter values ​​by operations and maintenance personnel) or delayed updates to configuration files will also disrupt the consistency of cluster parameters.

[0077] Therefore, how to achieve automated detection, difference comparison, and risk warning of configuration parameters in a multi-node database cluster has become a key technical challenge to ensure the stable operation of the cluster.

[0078] Specifically, in existing technologies, database cluster configuration management mainly relies on two methods: one is node status monitoring based on cluster management tools, and the other is manual comparison of configuration files node by node. For example, some cluster management tools can monitor the running status of nodes (such as processor load and replication latency) or perform basic health checks, but they usually only monitor specific indicators (such as replication latency and node availability), lacking in-depth analysis of the consistency, integrity, and compliance of configuration parameters.

[0079] Furthermore, operations and maintenance personnel typically compare configuration files node by node using scripts or manually. However, this method has significant drawbacks: first, it is inefficient, requiring the comparison of hundreds of parameters line by line, which is time-consuming and prone to omissions; second, it has poor accuracy, failing to identify the severity of parameter value differences (such as the spelling difference between "log_level=DEBUG" and "log_level=debug"); and third, it is difficult to adapt to large-scale cluster environments, as manual comparison becomes almost impractical when the number of nodes exceeds dozens. More seriously, existing solutions often fail to distinguish the risk of differences between "critical parameters" and "non-critical parameters," making it difficult for operations and maintenance personnel to prioritize high-risk issues.

[0080] In summary, existing technologies rely on manual comparison of configuration files node by node by operations and maintenance personnel, or basic checks using script tools. These methods are inefficient because manual comparison requires analyzing hundreds of parameters line by line, which is time-consuming and prone to omissions. Furthermore, the inability to recognize spelling or unit differences (such as "1024MB" versus "1GB") leads to low accuracy. Simultaneously, the failure to differentiate the severity of differences between critical parameters (such as "master-slave replication latency threshold") and non-critical parameters (such as "log file name") results in inconsistent operational response priorities and a lack of risk grading. Moreover, the inability to detect deviations between dynamically modified parameters (such as temporary adjustments to "memory allocation" parameters by operations and maintenance personnel) and configuration files leads to insufficient monitoring of dynamic parameters.

[0081] Starting from the technical problems discovered in the aforementioned prior art, the inventors first identified the core contradiction in parameter consistency detection: the low efficiency of manual comparison and the limited functionality of automated tools. To solve this problem, the inventors proposed the following technical concept.

[0082] First, a multi-node parameter value mapping table is constructed. Specifically, a unique key between the node's Internet Protocol address (IP) and parameter name is stored using an associative array (hash table), achieving O(1) level (constant time complexity) parameter retrieval efficiency. Second, a predefined rule set is implemented. Specifically, inspection rules (such as "must be consistent", "must be inconsistent", "compliance threshold") are defined for different parameters, and alarm levels (such as "critical", "warning", "hint") are assigned to parameters. Third, automated comparison and hierarchical early warning are implemented. Specifically, an algorithm traverses all parameters, compares the differences between nodes, and automatically classifies and outputs the results according to the rule set. Fourth, dynamic parameter verification is implemented. Specifically, by collecting the differences between the database runtime parameters and the configuration file parameters, configuration changes that have not yet taken effect are identified.

[0083] Ultimately, through the aforementioned technical means, a complete multi-node parameter anomaly detection framework was constructed, achieving full-process automation from parameter acquisition and comparison to risk warning.

[0084] In view of this, this application provides a method for parameter detection in a multi-node database cluster. This method is based on a multi-node configuration consistency verification and rule-based compliance detection mechanism using a multi-node parameter value mapping table. By constructing an association mapping table of multi-node parameter values ​​and combining it with a predefined rule set, the method achieves consistency comparison, integrity verification, and compliance analysis of the configuration parameters of each node in the database cluster. This technical concept replaces manual comparison with automated algorithms, improves parameter retrieval efficiency using hash structures, and distinguishes the severity of parameter differences through a hierarchical early warning mechanism, thereby solving the problems of low efficiency, poor accuracy, and insufficient risk identification capabilities in parameter consistency detection in existing technologies.

[0085] The method provided in this application is applicable to any multi-node database cluster operation and maintenance scenario. For example, it can be applied to parameter consistency detection scenarios in enterprise-level multi-node database clusters, such as systems with stringent high data availability requirements, such as those in finance, telecommunications, and e-commerce platforms. In a typical architecture, the cluster contains one master node (master database) and multiple slave nodes (standby databases), achieving data synchronization and failover through master-slave replication. Operation and maintenance personnel must ensure that the configuration parameters of all nodes (such as memory allocation, log paths, connection limits, etc.) remain consistent; otherwise, replication delays, data loss, or master-slave failover may occur. For example, in an e-commerce platform's order system, if the master node's "maximum connections" parameter is 1000 while the slave node's is 500, it may cause slave node resource overload, leading to order processing delays.

[0086] The technical solutions of this application will be described in detail below with reference to specific embodiments. The specific embodiments described below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0087] Figure 1 A flowchart illustrating the multi-node database cluster parameter detection method provided in this application embodiment. Figure 1 The execution subject of this method can be an electronic device with corresponding data storage and computing capabilities, such as a computer, server, or server cluster. Figure 1 As shown, the method includes:

[0088] S101, construct a multi-node parameter value mapping table to identify the association between nodes and parameters through a unique key in the multi-node parameter value mapping table.

[0089] For example, a multi-node parameter value mapping table can be understood as a data structure that stores the association between parameter values ​​for each node, using a combination of node identifier and parameter name as the unique key. The node identifier can be, for example, a node IP address, and the parameters can include parameter name and parameter value, etc.

[0090] For example, the unique key is {"192.168.1.1:log_level":"DEBUG"}, where "192.168.1.1" represents the node identifier, "log_level" represents the parameter name, and "DEBUG" represents the parameter value of "log_level". This associated data structure can be understood as a key-value pair data structure for nodes and parameters, or as a hash table structure.

[0091] In one possible implementation, constructing a multi-node parameter value mapping table includes: remotely reading the configuration parameter values ​​configured in any node via a secure shell protocol; and / or obtaining the running parameter values ​​running in any node by calling the database application interface; and / or reading the configuration parameter values ​​in the system's configuration file by reading the file system.

[0092] For example, the Secure Shell (SSH) protocol can be understood as a protocol used to remotely connect to nodes, such as `ssh user@192.168.1.1`. The database's Application Programming Interface (API) can be understood as the programming interface provided by the database, such as the `SHOW VARIABLES` command.

[0093] Reading the file system can be understood as accessing configuration files through the file system, such as reading ` / etc / mysql / my.cnf`. The file system can be understood as the file system within the operating system of an electronic device. Database systems can construct multi-node parameter value mapping tables in various ways. This allows for adaptation to different node access permissions and configuration methods through multiple pathways, ensuring the comprehensiveness and flexibility of parameter collection.

[0094] In this embodiment, parameter collection through multiple methods covers access restrictions and configuration methods for different nodes. For example, when some nodes cannot have SSH access enabled, the system can read parameters through the database API interface or file system, ensuring the universality of the detection scheme. Based on this, the applicability of the method in complex cluster environments can be improved.

[0095] S102, Predefined parameter check rule set, which includes parameter consistency requirements and compliance thresholds.

[0096] For example, a parameter checking rule set can be understood as a predefined set of rules for parameter comparison logic. The parameter checking rule set may include rules of type such as parameter consistency requirements and compliance thresholds. Parameter consistency requirements may be such as "must be consistent" and / or "must be inconsistent", and compliance thresholds may be judgment thresholds set for parameter values ​​to determine whether they are compliant.

[0097] S103, based on the multi-node parameter value mapping table and parameter inspection rule set, compares and analyzes the parameter values ​​of each node in the multi-node database cluster and outputs abnormal information.

[0098] For example, comparative analysis can be understood as traversing a multi-node parameter value mapping table using an algorithm, comparing the differences in parameter values ​​between nodes item by item according to a set of parameter checking rules. Anomaly information can be understood as a structured output that records the type of parameter difference (such as "inconsistent" or "missing") and the corresponding node identifier.

[0099] For example, to implement the steps of the embodiments of this application, the consistency detection of parameters of a multi-node database cluster can be achieved through the following process.

[0100] First, construct a multi-node parameter value mapping table, storing the parameter values ​​of each node with a unique key consisting of a combination of the node identifier and the parameter name. For example, if the log_level parameter value of the node with IP address 192.168.1.1 is DEBUG, then the mapping table will store it as {"192.168.1.1:log_level":"DEBUG"}.

[0101] Secondly, predefined parameter checking rule sets are used. For example, a "must be consistent" rule is set for the max_connections parameter, requiring that the parameter value be the same for all nodes; and a compliance threshold rule is set for innodb_buffer_pool_size, requiring that its value not be lower than 70% of the physical memory.

[0102] Finally, based on the multi-node parameter value mapping table and parameter checking rule set, the parameter values ​​of each node are compared item by item by the comparison algorithm. If the values ​​of a certain parameter are inconsistent across multiple nodes or do not meet the threshold requirements, it is recorded as an abnormal information and output.

[0103] Furthermore, tiered alerts can be implemented for abnormal information. For example, preset alarm levels can include multiple levels representing different degrees of abnormality, such as "Severe," "Warning," and "Alert." Different levels of alerts can be issued based on the abnormal information and the alarm level.

[0104] Based on the above steps, the association between nodes and parameters is identified by a unique key. Combined with the parameter checking rule set, automated comparison is achieved, and finally a structured anomaly report is generated.

[0105] The multi-node database cluster parameter detection method provided in this application solves the problems of low efficiency and poor accuracy in parameter consistency detection in multi-node database clusters by constructing a multi-node parameter value mapping table and a parameter checking rule set.

[0106] Specifically, the multi-node parameter value mapping table identifies the association between nodes and parameters through a unique key, achieving O(1) level parameter retrieval efficiency and avoiding the redundant operation of manual line-by-line comparison in existing methods. For example, in a cluster of 1000 nodes, the system can instantly locate any parameter value, significantly shortening the detection time.

[0107] Meanwhile, the predefined parameter check rule set allows the system to automatically identify the type of parameter discrepancies (such as "inconsistent maximum connection count between master and slave nodes") and differentiate the severity of the discrepancies through a tiered warning mechanism. For example, if the "log path" parameter of the master node is missing, it is marked as "critical," while a spelling difference in the "log file name" is marked as "hint," thus guiding operations personnel to prioritize high-risk issues. Furthermore, the parameter check rule set can also support dynamic updates, such as adjusting the compliance threshold range based on cluster size to adapt to the needs of different business scenarios.

[0108] Based on this, the method provided in this application can improve the detection efficiency and accuracy of multi-node database cluster parameters. Furthermore, a tiered early warning mechanism can optimize the priority of operation and maintenance responses, avoiding resource consumption due to low-priority issues.

[0109] In one possible implementation, a multi-node parameter value mapping table is constructed, including: generating a unique key based on the combination of node identifier and parameter name, and storing the parameter value corresponding to the parameter name in the unique key; predefining a parameter inspection rule set, including: setting a consistency requirement type for parameters to be checked for consistency, the consistency requirement type including must be consistent, must be inconsistent, and can be consistent or inconsistent; and / or setting a compliance threshold range for parameters to be checked for compliance, the compliance threshold range including numerical range, unit conversion rules, and format specifications.

[0110] For example, the combination of node identifier and parameter name can be understood as the concatenation of node identifier (such as IP address) and parameter name (such as max_connections), for example, 192.168.1.1: max_connections. The consistency requirement type can be understood as defining the comparison logic of parameters across multiple nodes; for example, "must be consistent" requires all nodes to have the same parameter value. The compliance threshold range can be understood as the numerical range (such as max_connections>500) or format specification (such as log_level must be uppercase) that the parameter value must meet.

[0111] When constructing the multi-node parameter value mapping table, the system generates a unique key using a combination of node identifier (e.g., 192.168.1.1) and parameter name (e.g., log_level), ensuring that each parameter value is uniquely located within the table. For example, 192.168.1.1: log_level corresponds to the value DEBUG; 192.168.1.2: log_level corresponds to the value DEBUG. When predefining rule sets, consistency requirement types are assigned to parameters, such as setting max_connections to "must be consistent"; compliance threshold ranges are also defined, such as innodb_buffer_pool_size being greater than or equal to 70% of physical memory. The parameter check rule set is dynamically loaded through an algorithm, ensuring the flexibility of the detection logic.

[0112] In this embodiment, the efficient construction of a multi-node parameter value mapping table and flexible rule adaptation are achieved through unique key generation and predefined parameter checking rule sets. The combination of node identifier and parameter name ensures accurate positioning of parameter values ​​and avoids data conflicts caused by duplicate keys; the predefined consistency requirement types allow the system to automatically identify parameter difference types (such as "inconsistent maximum connection count between master and slave nodes"), while the setting of compliance threshold ranges can dynamically adapt to the specification requirements of different clusters. Based on this, the accuracy and adaptability of detection are further improved, especially in heterogeneous clusters or dynamic configuration scenarios.

[0113] For example, if the parameter values ​​in the configuration file are inconsistent with the database operating parameters, it can lead to potential performance problems or replication interruptions, but related methods cannot automatically identify such discrepancies. Therefore, the method provided in this application compares the differences between the configuration file parameters and the database operating parameters using a multi-node parameter value mapping table and records any anomalies.

[0114] In one possible implementation, based on a multi-node parameter value mapping table and a parameter checking rule set, the parameter values ​​of each node in the multi-node database cluster are compared and analyzed. This includes: extracting the configuration parameter value and running parameter value of any parameter from the multi-node parameter value mapping table; comparing whether there is a difference between the configuration parameter value and the running parameter value of any parameter; if there is a difference between the configuration parameter value and the running parameter value of any parameter, recording any parameter as an abnormal parameter, and recording the configuration parameter value and the running parameter value of any parameter as abnormal information.

[0115] For example, configuration parameter values ​​can be understood as parameter values ​​in a configuration file, which can be read from a database configuration file (such as my.cnf), such as max_connections=1000. Runtime parameter values ​​can be understood as parameter values ​​dynamically obtained through database commands (such as SHOW VARIABLES) that are currently used in the runtime, such as max_connections=500.

[0116] The system extracts configuration parameter values ​​(e.g., `max_connections=1000` from the configuration file) via scripts or application programming interfaces (APIs), and retrieves runtime parameter values ​​(e.g., `max_connections=500`) via database commands (e.g., `SHOW VARIABLES`). When comparing the two, if the configuration parameter value and the runtime parameter value are inconsistent (e.g., 1000 ≠ 500), an exception is recorded (e.g., `{"192.168.1.1:max_connections": {"config": "1000", "runtime": "500"}}`). This process quickly locates parameter values ​​using the unique key of a multi-node parameter value mapping table, ensuring efficient comparison.

[0117] By directly comparing configuration parameter values ​​with runtime parameter values, potential failures caused by parameters not taking effect are resolved. For example, if operations personnel update the "memory allocation" parameter in the configuration file but do not restart the database, the runtime parameter value will still use the old value. The database system can identify this deviation and mark it as "critical." Furthermore, by recording the IP addresses of abnormal nodes and the parameter names, operations personnel can quickly locate the problematic nodes and repair their configurations. This effectively prevents performance degradation or replication interruptions caused by parameters not taking effect, ensuring the stable operation of the cluster.

[0118] In this embodiment of the application, by comparing the configuration parameter value with the running parameter value, the potential failure problem caused by the parameter not taking effect is solved, which can reduce the performance degradation or replication interruption caused by the parameter not taking effect and ensure the operational stability of the database cluster.

[0119] For example, if key parameters are not set according to cluster specifications (such as "innodb_buffer_pool_size" not being set to 70% of physical memory), it may lead to data loss risks or abnormal master-slave failover. To address this, the method provided in this application reduces the probability of data loss risks or abnormal master-slave failover by predefining a set of compliance rules for key parameters and using threshold checks to determine whether the parameters comply with specifications.

[0120] In one possible implementation, a predefined set of parameter checking rules is included, comprising: setting compliance threshold ranges for key parameters, wherein the compliance threshold ranges include at least one of numerical ranges, unit conversion rules, and format specifications, and the key parameters are parameters in a predefined set of key parameters; and comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on a multi-node parameter value mapping table and the parameter checking rule set, including: recording any key parameter as an abnormal parameter if the value of any key parameter does not meet the compliance threshold range corresponding to any key parameter.

[0121] For example, critical parameters can be understood as parameters that are essential to the operation of the cluster, such as `innodb_buffer_pool_size` and `max_allowed_packet`. Whether a parameter is critical can be determined by a predefined set of critical parameters. For example, a subset is pre-determined from all parameters, and this subset includes all critical parameters selected from all parameters; this subset is the set of critical parameters.

[0122] Compliance threshold ranges can be understood as the numerical range that parameter values ​​must meet (e.g., innodb_buffer_pool_size ≥ 70% of physical memory) or format specifications (e.g., log_file_path must start with / var / log / ). Database systems can predefine compliance threshold ranges for key parameters (e.g., innodb_buffer_pool_size) (e.g., greater than or equal to 70% of physical memory) and dynamically collect node memory information to calculate the threshold. During comparison analysis, if the key parameter value does not meet the threshold (e.g., innodb_buffer_pool_size = 50% of physical memory), it is marked as an anomaly (e.g., {"192.168.1.1:innodb_buffer_pool_size": {"value": "50%", "threshold": "70%"}}). This process adapts to the specification requirements of different clusters by dynamically loading the parameter checking rule set.

[0123] By employing a rule-based verification mechanism, the system mitigates cluster operational risks caused by non-compliant settings of critical parameters. For example, if a node's "innodb_buffer_pool_size" is set to 50% of physical memory, the system can identify this deviation and mark it as "critical," prompting operations personnel to adjust the parameter to comply with specifications. Furthermore, the parameter check rule set supports dynamic updates, such as adjusting the threshold range based on cluster size (e.g., "60% of physical memory" for small clusters), thus adapting to the needs of different business scenarios. Based on this, the system significantly reduces the risk of failures caused by improper configuration of critical parameters, improving cluster reliability.

[0124] In this embodiment of the application, by checking the compliance threshold of key parameters, the risk of failure caused by improper configuration of key parameters is reduced, and the reliability of the cluster is improved, especially in high-load or disaster recovery scenarios.

[0125] For example, differences in parameter formats (such as units, syntax, and hierarchical structure) among different database types in a heterogeneous database cluster can lead to misjudgments in parameter parsing, thus affecting detection accuracy. Therefore, the method provided in this application sets up a dynamic parsing engine to reduce the probability of misjudgments in parameter parsing. A corresponding parameter parsing rule base, including unit conversion rules and hierarchical structure parsing logic, can be loaded according to the database type (such as MySQL or PostgreSQL).

[0126] In one possible implementation, constructing a multi-node parameter value mapping table includes: loading a corresponding parameter parsing rule base according to the database types included in the multi-node database cluster, the parameter parsing rule base including unit conversion rules and hierarchical structure parsing logic; and constructing the multi-node parameter value mapping table according to the unit conversion rules and / or hierarchical structure parsing logic in the parameter parsing rule base.

[0127] For example, database type can be understood as the type of database system used in a multi-node database cluster, such as MySQL or PostgreSQL. Unit conversion rules can be understood as rules for converting parameter values ​​to a unified unit, such as converting 1024MB to 1GB, meaning "1024MB" and "1GB" are equivalent. Hierarchical structure parsing logic can be understood as the logic for parsing multiple parameters in a configuration file, such as the parameters in the [mysqld] section of MySQL's my.cnf file.

[0128] Database systems can load the corresponding parameter parsing rule base using database type identifiers (such as MySQL-5.7, PostgreSQL-12). For example, when parsing MySQL's my.cnf file, the database system identifies the parameters in the [mysqld] section and converts 1024MB to 1GB for comparison. Based on this, dynamically loading the parameter parsing rule base can adapt to the differences in parameter formats between different database types, avoiding misjudgments caused by inconsistent formats.

[0129] For example, by dynamically adapting the parameter parsing rules of different databases, the problem of misjudgment caused by inconsistent parameter formats in heterogeneous clusters is solved. For instance, in a multi-node database cluster where MySQL nodes (MySQL-type databases) and PostgreSQL nodes (PostgreSQL-type databases) are deployed in combination, the database system can automatically identify the configuration file formats of the two databases, avoiding misjudging "1024MB" as inconsistent with "1GB". Furthermore, it can eliminate abnormal false alarms caused by unit differences (such as milliseconds "ms" versus seconds "s"), improving the accuracy of detection results.

[0130] Furthermore, the hierarchical structure parsing logic ensures that parameters in complex configuration files (such as my.cnf containing multiple sections) are fully extracted, avoiding the omission of key configuration items. This significantly improves the accuracy of the detection results and enhances the solution's compatibility with various types of database clusters.

[0131] In this embodiment of the application, the problem of misjudgment caused by differences in parameter formats in heterogeneous clusters is solved by dynamically loading a parameter parsing rule base, thereby improving the flexibility and accuracy of detection.

[0132] For example, comparing all parameters in a large-scale cluster would result in excessively long detection times, high resource consumption, and difficulty in meeting real-time operation and maintenance needs. Therefore, the method provided in this application introduces an incremental detection mechanism, comparing only recently modified parameters (such as changes in configuration file update timestamps or dynamic adjustment records of running parameters) instead of scanning all parameters, thereby shortening detection time and reducing resource consumption. For instance, the system maintains a parameter change log (recording parameter name, change time, old value, and new value) and node status snapshots, extracting only the changed parameters for comparison during each detection.

[0133] In one possible implementation, before comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and parameter checking rule set, the method further includes: creating and maintaining a parameter change log, which records the target parameters that have changed; and comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and parameter checking rule set, including: comparing and analyzing the parameter values ​​of the target parameters in the parameter change log based on the multi-node parameter value mapping table and parameter checking rule set.

[0134] For example, a target parameter can be understood as a parameter whose name and / or value have been modified, added, or deleted. A parameter change log can be understood as a data table that records the modification history of the target parameter. A parameter change log can be created by creating a data table. The parameter change log can record the target parameter's name, change time, parameter source, old value, and new value. The old value is the value before the change, and the new value is the value after the change.

[0135] Change time can be understood as the timestamp of a parameter value modification. For example, it can be used to further identify which target parameters are the objects of this comparison. For instance, a preset time range (preset time period) can be set, and only when the change time of a target parameter falls within the preset time range will the target parameter be compared and detected.

[0136] For example, a record in the parameter change log is {"max_connections": {"old": "1000", "ew": "1500", "timestamp": "2023-01-01 12:00:00"}}, where "max_connections" is the name of the target parameter; "old": "1000" indicates that the old value of the target parameter is 1000; "ew": "1500" indicates that the new value of the target parameter is 1500; and "timestamp": "2023-01-01 12:00:00" indicates that the timestamp of the change of the target parameter is 2023-01-01 12:00:00.

[0137] The database system can maintain a parameter change log or combine it with node status snapshots (status snapshots record parameter values ​​from the last detection). During each detection, only the target parameters recorded in the parameter change log are extracted for comparison and analysis. For example, if a node's `max_connections` has not been modified in the past 24 hours, it will not be recorded in the latest parameter change log, and the comparison of that parameter can be skipped. This process reduces redundant comparison calculations and improves detection efficiency through incremental updates to the parameter change log.

[0138] Incremental consistency checks significantly reduce resource consumption and time consumption during the process. For example, in a 1000-node cluster, if only 10 parameters change (i.e., 10 target parameters require incremental consistency checks), the database system only needs to compare these 10 target parameters, instead of comparing all parameters. Furthermore, the creation and maintenance of parameter change logs provide data support for subsequent root cause analysis (such as locating the source of parameter modifications), enhancing operational traceability.

[0139] In this embodiment of the application, the incremental detection mechanism can reduce the resource consumption and time consumption of the detection process, such as reducing processor or memory usage, reducing redundant calculations, shortening detection time, improving detection efficiency, and enabling the method to adapt to the real-time operation and maintenance needs of large-scale clusters.

[0140] In one possible implementation, maintaining a parameter change log includes: triggering the maintenance of the parameter change log through modification events in the database transaction log or configuration file, wherein the parameter change log records the change time; and performing comparative analysis on the parameter values ​​of the target parameters, including: filtering out the target parameters corresponding to change times within a preset time period based on the change time of the target parameters; and performing comparative analysis only on the parameter values ​​of the target parameters corresponding to change times within the preset time period.

[0141] For example, a database transaction log can be understood as a system log that records database operations, such as a binlog file. A configuration file modification event can be understood as a triggering event that occurs when a configuration file (such as my.cnf) is modified, such as a file write operation.

[0142] Database systems can trigger the maintenance of parameter change logs through database transaction logs (such as binlog) or modification events in configuration files (such as write operations to my.cnf) to record target parameters. For example, when the max_connections value in my.cnf is modified, the system records the change time and new value of the corresponding target parameter.

[0143] The preset time period can be any length, such as the past 24 hours. During comparative analysis, the change times of each target parameter in the parameter change log can be filtered according to the preset time period. The target parameters corresponding to these change times are the objects of this parameter consistency comparison. This allows for further filtering of the comparison objects, such as selecting the most recently modified target parameters for consistency testing, avoiding a full scan of all target parameters. This process, through event-driven and time-based filtering, reduces redundant calculations.

[0144] In this embodiment, the accuracy and efficiency of incremental detection are optimized through event-driven and time-based filtering. For example, only the most recently modified parameters are compared, avoiding invalid comparisons caused by historical changes, thereby further reducing resource consumption and improving real-time performance.

[0145] For example, based on the above embodiments, the method provided in this application can also incorporate machine learning-based anomaly pattern recognition and risk prediction.

[0146] Specifically, a machine learning model is constructed and trained using historical detection data (such as parameter difference types, alarm levels, and repair time) to identify abnormal patterns. Model inputs include parameter difference features (such as difference type, parameter importance level, and deviation magnitude), node operating status (such as replication latency and processor load), and cluster topology (such as master-slave node relationships). The model output is a risk prediction level for the difference (such as "high risk" or "medium risk"). For example, if a difference in the "log_level" parameter is accompanied by an increase in replication latency, the model can predict that this difference may trigger log synchronization anomalies and automatically escalate the alarm level.

[0147] Based on this, machine learning models are used to identify potential risk patterns, overcoming the limitations of static judgment in rule sets and improving the ability to identify complex and abnormal scenarios (such as the implicit correlation between parameter differences and cluster performance degradation). Simultaneously, the risk prediction function can provide early warnings of parameter configuration issues that may cause failures (such as inconsistencies in the "binlog_format" between master and slave nodes potentially affecting data consistency), assisting operations personnel in prioritizing high-risk issues and enhancing cluster stability.

[0148] For example, based on the above embodiments, the method provided in this application embodiment can also introduce a strategy for causal chain analysis of parameter differences and generation of repair suggestions.

[0149] Specifically, upon detecting parameter differences, the system uses a causal chain analysis engine to deduce potential fault paths caused by these differences. For example, if the "innodb_buffer_pool_size" value is lower on the slave node than on the master node, the system can deduce a causal chain of "insufficient memory - degraded query performance - replication delay - master-slave failover failure," and generate repair suggestions (such as "adjust the slave node parameter value to 70% of physical memory") by combining historical repair records. The analysis process is based on a predefined fault tree model (containing a mapping relationship between parameters, faults, and repairs) and a dynamic graph (a real-time updated graph showing the relationship between node states and parameters).

[0150] Based on this, causal chain analysis and remediation suggestion generation directly link parameter differences with potential faults, helping operations and maintenance personnel quickly understand the severity of the differences and take targeted measures. For example, remediation suggestions can guide operations and maintenance personnel to prioritize adjusting high-risk parameters (such as inconsistencies in "max_allowed_packet" between master and slave nodes), reducing troubleshooting time. In addition, causal chain analysis can reveal the chain reaction of parameter differences (such as "incorrect log path - missing log file - failed failover"), improving fault prediction capabilities.

[0151] For example, based on the above embodiments, the method provided in this application can also introduce a multi-node parallel detection mechanism based on a distributed architecture.

[0152] Specifically, the detection task is broken down into multiple subtasks (e.g., grouped by node or by parameter type), and executed in parallel using a distributed task scheduling framework (e.g., Kafka, Celery). Each subtask independently handles parameter collection, comparison, and rule validation, and the results are aggregated through a message queue. For example, a detection task with 1000 nodes can be distributed across 10 compute nodes for parallel execution, with each compute node processing data from 100 nodes. Finally, an aggregator integrates all results to generate a global detection report.

[0153] Based on this, a distributed parallel detection mechanism significantly improves the detection efficiency of large-scale clusters, avoiding single-node processing bottlenecks. For example, in clusters with more than 1000 nodes, the detection time is reduced from hours to minutes. Simultaneously, the distributed architecture supports elastic scaling (such as adding computing nodes on demand), adapting to dynamic changes in cluster size. Furthermore, the fault-tolerance mechanism of the task scheduling framework (such as task failure retries and node failover) ensures the reliability of the detection process, preventing detection interruptions due to single points of failure.

[0154] Figure 2 A flowchart illustrating the multi-node database cluster parameter detection method provided in this application embodiment. Figure 2 , Figure 3 This is a schematic diagram of the parameter comparison process provided in the embodiments of this application. Figure 4 This is a schematic diagram of the node parameter value mapping table provided in the embodiments of this application. The following will further illustrate this. Figure 2 , Figure 3 and Figure 4 The method for detecting parameters of a multi-node database cluster provided in the embodiments of this application will be further described.

[0155] For example, an existing database may contain hundreds of parameters. In a database cluster, the configuration files and internal parameters of each node often need to be kept consistent to ensure the normal operation of replication, synchronization, backup, and high availability mechanisms. However, in actual operation and maintenance, various problems can easily arise with the configuration parameters between different nodes.

[0156] For example, inconsistent parameter configurations, where parameter values ​​in the external configuration files of each node may differ, can lead to replication anomalies or synchronization failures between master and slave nodes. Another example is inconsistencies between file and actual database parameters; mismatches between parameter values ​​in the configuration files and the actual operating parameters of the database system can cause potential performance issues or replication interruptions. Yet another example is the failure to set critical parameters according to cluster specifications; if certain core configuration items do not meet cluster operating requirements, it can result in data loss risks or abnormal master-slave failover. Finally, the lack of automated detection mechanisms means that traditional inspection methods rely on manual comparison of each node, which is inefficient, error-prone, and makes it difficult to detect potential risks in a timely manner.

[0157] Therefore, the method in this application provides a parameter anomaly detection method for multi-node database clusters. By using automated means to check the consistency, integrity and standardization of configuration files and database operating parameters of each node in the cluster, it can quickly discover, accurately locate and warn of cluster configuration anomalies, thereby improving the reliability and maintenance efficiency of database cluster operation.

[0158] For example, the method in this application embodiment can be understood as a parameter anomaly detection method for multi-node database clusters. Through remote collection, parameter comparison and rule-based analysis, it realizes automated detection and anomaly identification of configuration parameters of each node in the database cluster.

[0159] like Figure 2 As shown, firstly, the detection environment is initialized, and basic database information is obtained. Secondly, the database and configuration file parameters for each node are obtained, and the IP addresses of faulty nodes are recorded. For example, basic database information and configuration file parameters can be obtained through local and / or remote connections.

[0160] Next, a predefined list of alarm levels and a list of different fault inspection parameters are created. This step allows for the predefinition of multiple parameter lists for different inspection rules. Then, the parameters of each node are checked sequentially according to different rules and requirements. The parameters of each node can be traversed and checked based on a multi-node parameter value mapping table and a set of parameter inspection rules. Finally, anomalies are recorded according to different alarm levels, and the results are output. For example, inspection results can be recorded and anomaly information can be output according to inspection rules.

[0161] like Figure 3 As shown, after starting, initialization is performed to obtain database information. Then, parameters for each node are retrieved. It is determined whether retrieval failed; if so, the abnormal node information is recorded, such as node IP and parameter name. If not, a multi-node parameter value mapping table is constructed for parameter preprocessing. After starting the comparison, for any parameter, each node parameter is checked according to the parameter checking rule set. It is determined whether all parameters have been checked; if not, the process returns to execute the check of the next parameter. If so, the exception information is recorded and the result is output.

[0162] For example, when initializing the detection environment and obtaining basic database information, the main information obtained includes the IP address of the node to be checked; the database role (e.g., whether the database is a primary or secondary database); the database port; and the path to the configuration file to be checked.

[0163] Retrieve the database and configuration file parameters and their values ​​for each node. If a node fails and its parameters cannot be retrieved, record the IP address of the faulty node and output it to the results.

[0164] When predefining multiple parameter lists, for example, all parameters can be categorized by error level to generate parameter lists with multiple alarm levels; multiple parameter lists under different inspection rules can also be predefined; and inspection rule sets for different parameters can be predefined to set expected values.

[0165] like Figure 4 As shown, when establishing a multi-node parameter value mapping table, the multi-node parameter value mapping table can include parameter mapping table 1 and parameter mapping table 2. A unique key is formed by the node IP and parameter name to record the parameter value of each parameter in each node in parameter mapping table 1; all discovered parameter names are recorded in parameter mapping table 2. The values ​​in table 2 can be preset, and the key is the unique parameter name.

[0166] During parameter preprocessing, for example, parameter values ​​with different units can be standardized to a uniform unit. When checking the parameters of each node according to different rules, abnormal node information can be recorded for faulty nodes whose parameter values ​​cannot be obtained. Detection can be performed according to any of the following rules.

[0167] Rule 1: Retrieve a parameter name from parameter mapping table 2, iterate through the node IP list, construct a key consisting of IP and parameter name, and retrieve the parameter value corresponding to this key from parameter mapping table 1 using a hash algorithm; compare the database parameters of this node with the configuration file parameters in turn, and if they are different, prompt an exception and record the parameter name and node IP. Repeat this step for each node in turn; some parameter values ​​are different but have the same meaning, and these parameters are handled specially and are not recorded as exceptions; repeat the above operation until all parameters have been checked.

[0168] Rule 2: Obtain parameter values ​​using the same method as in Rule 1; compare the parameter values ​​in the configuration files of each node sequentially, and check them according to the predefined parameter list of Rule 2. Specifically: for parameters that must be consistent, check whether the parameters of each node are completely consistent; otherwise, prompt an exception; for parameters that must be inconsistent, check whether the parameters of each node are different; otherwise, prompt an exception; for parameters that may or may not be consistent, do not check them. Repeat the above operation until all parameters have been checked.

[0169] Rule 3: According to the established parameter mapping table 2, traverse the list of node IPs, construct a key of IP + parameter name, check whether the key exists in parameter mapping table 1. If it does not exist or the value is empty, record that the node is missing the parameter, and record the IP and parameter name.

[0170] Rule 4: Compliance verification of standardized parameters. Specifically, according to the predefined set of inspection rules for different parameters, check whether each parameter of each node meets the preset value requirements. If the preset value is not met, it is recorded as an anomaly. If an anomaly is found, the inspection results are recorded according to the parameter list of the preset alarm level for different parameters, and the results are output.

[0171] The method provided in this application is a consistency verification algorithm based on a multi-node parameter value mapping table. An associative array is used to construct the multi-node parameter value mapping table, storing parameter values ​​with the node IP + parameter name as the unique key. A hash structure is used to achieve O(1) level parameter retrieval efficiency. The first node value is used as a benchmark for comparison, and the values ​​of the same parameter across different nodes are compared one by one. Differences are automatically determined, and graded warnings are issued according to a preset rule set.

[0172] The method provided in this application also incorporates a parameter compliance judgment mechanism based on a parameter check rule set. This method presets different check rules, with different parameters having different preset warning levels under different check rules, and sets expected values ​​or threshold ranges for each parameter. The detection algorithm determines whether the parameters conform to the cluster operation specifications according to each rule, achieving automatic detection and hierarchical warning of parameter standardization, and providing corresponding quantitative output.

[0173] Through the synergistic effect of the aforementioned technical features, the method provided in this application improves the stability and reliability of the cluster system. By proactively identifying potential configuration vulnerabilities and providing tiered early warnings, it effectively prevents failures such as replication interruptions, data loss, or abnormal master-slave switching, thereby enhancing the stability of the database cluster operation. Furthermore, this method significantly improves detection efficiency and accuracy. Through automated multi-node information collection and comparison algorithms, it avoids manual node-by-node verification by maintenance personnel, increasing detection speed several times over while reducing human error and facilitating integration into database management systems or automated inspection platforms.

[0174] This application embodiment also provides a method for detecting parameter consistency in a multi-node database cluster, the method comprising:

[0175] The parameter acquisition module obtains the configuration file parameter values ​​and database running parameter values ​​of each node and constructs a multi-node parameter value mapping table. The rule configuration module loads a predefined parameter check rule set, which includes parameter consistency requirement types and compliance threshold ranges. The comparison and analysis module compares and analyzes the parameter values ​​of each node based on the parameter mapping table and the rule set and outputs abnormal information.

[0176] The multi-node database cluster parameter consistency detection method provided in this application embodiment is similar in implementation process to the multi-node database cluster parameter detection method provided in the above embodiments. Its implementation principle and technical effect can be referred to the description of the above embodiments, and will not be repeated here.

[0177] This application embodiment also provides a multi-node database cluster parameter consistency detection system, the system comprising:

[0178] The parameter acquisition module is used to read the configuration file parameter values ​​and database running parameter values ​​of each node through the SSH protocol, database API interface or file system, and build a multi-node parameter value mapping table;

[0179] The rule configuration module is used to load predefined parameter check rule sets, which include parameter consistency requirement types and compliance threshold ranges.

[0180] The comparison and analysis module is used to compare and analyze the parameter values ​​of each node based on the parameter mapping table and rule set, and output anomaly information.

[0181] For example, the parameter acquisition module can be understood as a software component used to collect configuration file parameter values ​​and runtime parameter values ​​from a multi-node database cluster, such as remotely reading parameter values ​​from the my.cnf file via the SSH protocol.

[0182] The rule configuration module can be understood as a software component used to load and manage parameter checking rules, such as setting a "must be consistent" rule for the `max_connections` parameter. The comparison and analysis module can be understood as a software component that performs parameter value comparison and anomaly detection, such as comparing whether the `innodb_buffer_pool_size` parameter values ​​of each node meet compliance thresholds.

[0183] The parameter acquisition module accesses each node via SSH protocol, database API interface or file system, extracts configuration file parameter values ​​(such as max_connections=1000 in my.cnf) and runtime parameter values ​​(such as max_connections=500 obtained from SHOW VARIABLES), and constructs a parameter mapping table with node identifier and parameter name as unique keys.

[0184] The rule configuration module loads predefined rule sets, such as setting "must be consistent" rules or compliance threshold ranges for key parameters (e.g., innodb_buffer_pool_size ≥ 70% of physical memory). The comparison and analysis module compares parameter values ​​item by item based on the mapping table and rule set. If there are differences or the threshold is not met, an exception message is generated (e.g., {"192.168.1.1:max_connections": {"config": "1000", "runtime": "500"}}).

[0185] By employing modularly designed parameter acquisition, rule configuration, and comparison analysis functions, the entire process of parameter consistency detection in a multi-node database cluster is automated. For example, the parameter acquisition module adapts to different node access methods (such as SSH or API) to ensure comprehensive parameter acquisition; the rule configuration module supports dynamic adjustment of rule sets to adapt to the specifications of different clusters; and the comparison analysis module achieves O(1) level parameter retrieval through a hash table structure, significantly improving detection efficiency. Based on this, the problems of low efficiency and poor accuracy of manual comparison are solved, and the hierarchical early warning mechanism optimizes the priority of operation and maintenance response, ensuring the stable operation of the cluster.

[0186] The multi-node database cluster parameter consistency detection system provided in this application embodiment is similar in implementation process to the multi-node database cluster parameter detection method provided in the above embodiments. Its implementation principle and technical effect can be referred to the description of the above embodiments, and will not be repeated here.

[0187] Figure 5 This is a schematic diagram of the structure of the multi-node database cluster parameter detection device provided in the embodiments of this application, as shown below. Figure 5 As shown in the figure, this application embodiment provides a multi-node database cluster parameter detection device, the device comprising:

[0188] Module 501 is used to construct a multi-node parameter value mapping table, so as to identify the association between nodes and parameters through a unique key in the multi-node parameter value mapping table;

[0189] Predefined module 502 is used to predefine parameter checking rule sets, which include parameter consistency requirements and compliance thresholds;

[0190] The comparison module 503 is used to compare and analyze the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and parameter checking rule set, and output abnormal information.

[0191] In one possible implementation, the construction module 501 is specifically used to: generate a unique key based on the combination of node identifier and parameter name, and store the parameter value corresponding to the parameter name into the unique key;

[0192] The predefined module 502 is specifically used to: set the consistency requirement type for the parameters for detecting consistency, including the consistency requirement type as required, the consistency requirement type as required, and the consistency requirement type as optional; and / or to set the compliance threshold range for the parameters for detecting compliance, including the numerical range, unit conversion rules, and format specifications.

[0193] In one possible implementation, the comparison module 503 is specifically used for:

[0194] Extract the configuration parameter value and runtime parameter value of any parameter from the multi-node parameter value mapping table;

[0195] Compare the configuration parameter value with the running parameter value of any parameter to see if there is a difference;

[0196] If there is a difference between the configuration parameter value and the running parameter value of any parameter, record that parameter as an abnormal parameter, and record the configuration parameter value and the running parameter value of that parameter as abnormal information.

[0197] In one possible implementation, the predefined module 502 is specifically used for:

[0198] Set compliance threshold ranges for key parameters. The compliance threshold range includes at least one of the following: numerical range, unit conversion rules, and format specifications. Key parameters are parameters in a predefined set of key parameters.

[0199] The comparison module 503 is specifically used for:

[0200] If the value of any key parameter does not meet the compliance threshold range corresponding to that key parameter, then that key parameter is recorded as an abnormal parameter.

[0201] In one possible implementation, the construction module 501 is specifically used for:

[0202] Based on the database types included in the multi-node database cluster, load the corresponding parameter parsing rule base, which includes unit conversion rules and hierarchical structure parsing logic;

[0203] Based on the unit conversion rules and / or hierarchical structure parsing logic in the parameter parsing rule base, construct a multi-node parameter value mapping table.

[0204] In one possible implementation, the device further includes a logging module for:

[0205] Create and maintain a parameter change log, which records the target parameters that have changed.

[0206] The comparison module 503 is specifically used for:

[0207] For the target parameter in the parameter change log, the parameter value of the target parameter is compared and analyzed based on the multi-node parameter value mapping table and parameter inspection rule set.

[0208] In one possible implementation, the logging module is specifically used for:

[0209] The parameter change log is triggered by modification events in the database transaction log or configuration file, and the change time is recorded in the parameter change log.

[0210] The comparison module 503 is specifically used for:

[0211] Based on the change time of the target parameter, filter out the target parameters corresponding to the change time within the preset time period;

[0212] The parameter values ​​of the target parameters are compared and analyzed only for the change time within the preset time period.

[0213] The multi-node database cluster parameter detection device provided in this application embodiment can be used to execute the technical solution of the multi-node database cluster parameter detection method in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be described again in this embodiment.

[0214] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 6 As shown, the electronic device of this embodiment may include: at least one processor 601; and a memory 602 communicatively connected to the at least one processor; wherein the memory 602 stores instructions that can be executed by the at least one processor 601, and the instructions are executed by the at least one processor 601 to cause the electronic device to perform the method as described in any of the above embodiments.

[0215] Optionally, the memory 602 can be either standalone or integrated with the processor 601.

[0216] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0217] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method of any of the foregoing embodiments.

[0218] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the foregoing embodiments.

[0219] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0220] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0221] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU) or other general-purpose processors. The processor can also be a Digital Signal Processor (DSP) or an Application Specific Integrated Circuit (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0222] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be various media that can store program code, such as USB flash drives, portable hard drives, read-only memory (ROM), disks or optical discs.

[0223] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof. Examples of storage media include Static Random-Access Memory (SRAM) or Electrically Erasable Programmable Read Only Memory (EEPROM).

[0224] Storage media can be, for example, erasable programmable read-only memory (EPROM) or programmable read-only memory (PROM). Storage media can also be read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0225] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside within an application-specific integrated circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components within an electronic device or host device.

[0226] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0227] The sequence numbers of the embodiments in this application are merely for description and do not represent the superiority or inferiority of the embodiments. Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0228] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0229] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0230] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0231] It should be further noted that although the steps in the flowchart are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated in this document, there is no strict order requirement for the execution of these steps, and they can be executed in other orders.

[0232] Furthermore, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0233] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0234] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0235] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for parameter detection of a multi-node database cluster, characterized in that, The method includes: Construct a multi-node parameter value mapping table to identify the association between nodes and parameters using a unique key in the multi-node parameter value mapping table; A predefined set of parameter checking rules, which includes parameter consistency requirements and compliance thresholds; Based on the multi-node parameter value mapping table and the parameter checking rule set, the parameter values ​​of each node in the multi-node database cluster are compared and analyzed, and abnormal information is output.

2. The method according to claim 1, characterized in that, The construction of the multi-node parameter value mapping table includes: generating a unique key based on the combination of node identifier and parameter name, and storing the parameter value corresponding to the parameter name into the unique key; The predefined parameter check rule set includes: setting consistency requirement types for parameters that detect consistency, including mandatory consistency, mandatory inconsistency, and optional consistency; and / or setting compliance threshold ranges for parameters that detect compliance, including numerical ranges, unit conversion rules, and format specifications.

3. The method according to claim 1, characterized in that, The step of comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and the parameter checking rule set includes: Extract the configuration parameter value and running parameter value of any parameter from the multi-node parameter value mapping table; Compare the configuration parameter value and the running parameter value of any of the parameters to see if there is a difference; If there is a difference between the configuration parameter value and the running parameter value of any of the above parameters, record the above parameter as an abnormal parameter, and record the configuration parameter value and the running parameter value of the above parameter as abnormal information.

4. The method according to claim 1, characterized in that, The predefined parameter check rule set includes: Set compliance threshold ranges for key parameters, wherein the compliance threshold ranges include at least one of numerical ranges, unit conversion rules, and format specifications, and the key parameters are parameters in a predefined set of key parameters; The step of comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and the parameter checking rule set includes: If the value of any key parameter does not meet the compliance threshold range corresponding to that key parameter, then that key parameter is recorded as an abnormal parameter.

5. The method according to claim 1, characterized in that, The construction of the multi-node parameter value mapping table includes: Based on the database types included in the multi-node database cluster, the corresponding parameter parsing rule base is loaded. The parameter parsing rule base includes unit conversion rules and hierarchical structure parsing logic. Based on the unit conversion rules and / or hierarchical structure parsing logic in the parameter parsing rule base, construct the multi-node parameter value mapping table.

6. The method according to any one of claims 1-5, characterized in that, Before comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and the parameter checking rule set, the method further includes: Create and maintain a parameter change log, which records the target parameters that have been changed. The step of comparing and analyzing the parameter values ​​of each node in the multi-node database cluster based on the multi-node parameter value mapping table and the parameter checking rule set includes: For the target parameter in the parameter change log, the parameter value of the target parameter is compared and analyzed based on the multi-node parameter value mapping table and the parameter check rule set.

7. The method according to claim 6, characterized in that, The maintenance parameter change log includes: The parameter change log is maintained by modifying the database transaction log or configuration file, and the parameter change log records the change time. The comparison and analysis of the parameter values ​​of the target parameter includes: Based on the change time of the target parameter, filter out the target parameters corresponding to the change time within a preset time period; The parameter values ​​of the target parameters corresponding to the change time within the preset time period are compared and analyzed only.

8. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images