Database master-slave switching method and system based on performance self-adaptive evaluation

Abstract

The invention discloses a main and standby database switching method and system based on performance self-adaptive evaluation. According to the method, multi-dimensional performance indexes of main and standby database nodes are collected in real time, the service health score of each node is dynamically calculated based on an adaptive weight model, and the fundamental transformation from recovery after failure to prevention before performance degradation is realized. And when the health score of the main node is continuously lower than a preset threshold value and a standby node with obviously higher health score exists, the system automatically triggers a preventive switching instruction and sequentially executes an elegant degradation process of write protection, data chasing, flow switching and role flipping. According to the method, the problems of single state judgment dimension, switching trigger lagging and extensive process control of a traditional heartbeat mechanism are effectively solved, the sub-health risk that the process survives but the service is unavailable can be accurately identified, the data consistency and the service continuity in the switching process are guaranteed, the service influence is remarkably reduced, and the user experience is improved. The method is suitable for key business scenes with strict high-availability requirements, such as finance and telecommunication.

Description

Technical Field

[0001] This application relates to the field of database management technology, and in particular to a database master-slave switching method, system, computer-readable storage medium, and electronic device based on performance adaptive evaluation. Background Technology

[0002] As the core data carrier of an information system, the high availability of a database directly determines the continuity and stability of upper-layer business operations. With master-slave replication architecture becoming the mainstream high-availability solution, the industry commonly uses heartbeat detection mechanisms for failover. This mechanism communicates between the master and slave databases by periodically sending heartbeat packets. If the slave database does not receive a heartbeat from the master database within a preset time, it determines that the master database has failed and triggers a failover. However, this binary-based liveness detection mechanism has inherent flaws and struggles to meet the high quality-of-service requirements of modern businesses.

[0003] (1) The status assessment is based on a single dimension and cannot identify the risk of "sub-health".

[0004] The heartbeat mechanism can only determine whether the master database process is alive; it's a Boolean-based check. For a "fake dead" state caused by the master database due to resource exhaustion (e.g., persistent CPU saturation), internal blocking (e.g., lock waits, slow query backlog), or network performance degradation (e.g., latency spikes, packet loss)—meaning the process is alive but unable to provide effective service—the heartbeat mechanism completely fails. This will cause the system to incorrectly maintain the master database connection even when business operations have actually been interrupted, resulting in prolonged business unavailability.

[0005] (2) Switching to passive trigger mode fails to achieve fault prevention.

[0006] Existing technologies employ a typical "failure recovery" strategy, requiring a clear failure event—the primary database becoming completely unavailable (heartbeat timeout)—before initiating the switchover process. This means the system cannot intervene in the early stages of gradual performance degradation and continuous decline in service capabilities, thus missing the critical window of opportunity to avoid business interruption and hindering the shift from "failure recovery" to "risk prevention."

[0007] (3) The handover process was poorly controlled, resulting in significant business disruption.

[0008] Traditional solutions typically employ hard failover when triggering a switchover, lacking fine-grained guarantees for data consistency and business continuity. A sudden interruption of writes to the primary database may lead to data loss or transaction inconsistencies; simultaneously, the standby database, without preloading or warming up, instantly takes over all traffic, which can easily cause performance fluctuations, resulting in further delays or interruptions to services after the switchover.

[0009] In summary, existing database master-slave failover technologies based on heartbeat detection have significant shortcomings in terms of state awareness foresight, failover trigger timeliness, and process control precision, making it difficult to meet the stringent requirements for database service continuity, consistency, and stability in demanding scenarios such as finance, telecommunications, and the internet. Summary of the Invention

[0010] To overcome the shortcomings of existing master-slave failover technologies that rely on a single heartbeat detection, this application proposes a novel database master-slave failover method and system based on performance adaptive evaluation. This invention constructs a weighted model based on real-time statistical feedback to synthesize multi-dimensional performance indicators into a single, accurate "service health score," which drives proactive and graceful master-slave failover, achieving a fundamental shift from "post-failure recovery" to "prevention before service degradation."

[0011] Specifically, this application provides the following technical solutions:

[0012] The first aspect of this application provides a database master-slave failover method based on performance adaptive evaluation, the method comprising:

[0013] S1. Collect multi-dimensional performance index data of the primary database node and at least one backup database node;

[0014] S2. Evaluate the multi-dimensional performance index data based on the adaptive weight model, and calculate the service health score of the main database node and each backup database node, wherein the adaptive weight model dynamically adjusts the index weights according to the real-time status of each performance index.

[0015] S3. When the service health score of the primary database node meets the switching trigger condition and there is a backup database node with a service health score higher than that of the primary database node, a preventive switching instruction is generated.

[0016] S4. Execute the graceful degradation switchover process to switch business traffic from the primary database node to the target standby database node. The graceful degradation switchover process includes write protection, data catch-up, traffic switching, and role reversal operations executed in sequence.

[0017] Furthermore, in the method of this application, the multi-dimensional performance index data mentioned in step S1 includes at least: CPU utilization, memory utilization, disk I / O latency, network round-trip latency, transactions per second or queries per second;

[0018] The multi-dimensional performance index data is obtained through a collection agent deployed on the database node and underlying infrastructure, with a collection frequency configured from 1 second to 30 seconds.

[0019] Furthermore, in the method of this application, the adaptive weight model in step S2 includes a sliding window statistics module, which is used to maintain a fixed-length time series window for each performance index and calculate the moving average and moving standard deviation within the time series window to characterize the recent normal baseline and fluctuation range of the index.

[0020] Furthermore, in the method of this application, the calculation process of the service health score in step S2 includes:

[0021] The raw values ​​of each performance indicator are standardized and converted into standard scores ranging from 0 to 10. The standardization process includes segmented scoring based on static thresholds and deviation inverse scoring based on dynamic baselines.

[0022] Adaptive weights are calculated based on the basic weights of each performance indicator and dynamic adjustment rules.

[0023] A service health score ranging from 0 to 100 is synthesized based on the standard score and the normalized adaptive weights. The lower the score, the worse the service health.

[0024] Furthermore, in the method of this application, the adaptive weight model described in step S2 dynamically adjusts the weights of each performance indicator based on the real-time status of each indicator. The dynamic adjustment rules include:

[0025] Deviation amplification rule: When the current value of a performance indicator deviates from its moving average by more than K times the moving standard deviation, where K is a configurable parameter, the weight of the indicator is amplified according to the degree of deviation, and the amplification factor is positively correlated with the degree of deviation.

[0026] Trend deterioration enhancement rule: When a performance indicator shows a deteriorating trend for three or more consecutive evaluation periods, an incremental factor is added to the weight of the indicator based on the linear regression slope.

[0027] Key anomaly top rule: When any performance indicator exceeds the absolute safety red line, the weight of that indicator is set to the maximum value to dominate the health score calculation and decision. The absolute safety red line includes at least one of the following: replication delay greater than 10 seconds, CPU utilization greater than 95% for 1 minute.

[0028] Furthermore, in the method of this application, the switching triggering conditions in step S3 include:

[0029] The service health score of the main database node is lower than the preset health score threshold for three consecutive evaluation cycles.

[0030] The service health score of the backup database node is higher than the service health score of the primary database node by a preset difference or more.

[0031] Furthermore, in the method of this application, the graceful degradation switching process described in step S4 specifically includes:

[0032] Write protection: Send a write protection command to the master database node to put it into read-only mode and prevent new transactions from writing to it;

[0033] Data catch-up: Monitor the replication latency of the target backup database node, and perform traffic switching once the data latency approaches zero or is within a preset safety threshold;

[0034] Traffic switching: Application write traffic is smoothly redirected to the target backup database node through database connection middleware or virtual IP migration technology;

[0035] Role flipping: Change the target backup database node to a new writable primary database node, and demote the original primary database node to a backup database node.

[0036] A second aspect of this application provides a database master-slave failover system based on performance adaptive evaluation. The system, when running, implements the aforementioned database master-slave failover method based on performance adaptive evaluation. The system includes:

[0037] The multi-dimensional performance data acquisition module is used to collect multi-dimensional performance index data of the primary database node and at least one backup database node.

[0038] An adaptive weight health assessment module is communicatively connected to the multi-dimensional performance data acquisition module. It is used to evaluate the multi-dimensional performance index data based on the adaptive weight model and calculate the service health score of the main database node and each backup database node. The adaptive weight model dynamically adjusts the index weights according to the real-time status of each performance index.

[0039] The switching instruction generation module is used to generate a preventive switching instruction when the service health score of the primary database node meets the switching triggering conditions and there is a backup database node with a service health score higher than that of the primary database node.

[0040] The proactive switching and graceful degradation module is communicatively connected to the adaptive weight health assessment module and is used to execute the graceful degradation switching process, switching business traffic from the primary database node to the target backup database node. The graceful degradation switching process includes write protection, data catch-up, traffic switching, and role reversal operations executed sequentially.

[0041] Furthermore, in this application system:

[0042] The multi-dimensional performance data acquisition module includes: a CPU utilization monitoring unit, a memory utilization monitoring unit, a disk I / O latency monitoring unit, a network round-trip latency monitoring unit, and a transaction per second / query per second monitoring unit.

[0043] The adaptive weighted health assessment module includes: a sliding window statistics submodule, used to maintain a fixed-length time window for each performance indicator and calculate the moving average and moving standard deviation; an indicator standardization submodule, used to convert the original values ​​of the performance indicators into standard scores; an adaptive weight calculation submodule, used to dynamically adjust the weights according to the real-time status of the indicators; and a service health score synthesis submodule, used to calculate the service health score based on the standard scores and the normalized dynamic weights.

[0044] The active switching and graceful degradation module includes: an active decision logic submodule, used to determine whether the switching trigger condition is met; and a graceful degradation submodule, used to execute write protection, data catch-up, traffic switching, and role reversal operations in sequence.

[0045] A third aspect of this application provides an electronic device, including: a memory and a processor;

[0046] Memory: Used to store computer programs;

[0047] Processor: Used to execute the computer program to implement the steps of the aforementioned database master-slave switchover method based on performance adaptive evaluation.

[0048] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned database master-slave switching method based on performance adaptive evaluation.

[0049] In summary, this invention achieves a technological leap in database master-slave switching from "passive response after a failure" to "proactive prevention before performance degradation" by constructing a closed-loop control system of "collection-adaptive evaluation-proactive decision-making-graceful switching". Compared to traditional heartbeat mechanisms that can only perform binary survival judgments, this invention establishes an adaptive weight model based on multi-dimensional performance indicators and sliding window statistics, quantifying complex states into precise service health scores. This effectively identifies the "sub-healthy" risk of processes being alive but services being unavailable, significantly improving the granularity and timeliness of state awareness. Through proactive decision-making logic with preset health score thresholds and multi-condition verification, the system can intervene in the early stages of performance degradation, avoiding business interruption and shortening recovery time. Combined with graceful degradation processes such as write protection, data catching up, traffic switching, and role reversal, it ensures data consistency during the switching process and performance stability after the switch, ultimately minimizing business impact. This solution is particularly suitable for scenarios with high availability requirements, such as finance and telecommunications, and can effectively improve the overall stability and service quality of database systems.

[0050] Other features and advantages of this application will be set forth in detail in the following description, or will become apparent through the implementation of the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved through the technical features and means explicitly pointed out in the description, claims, and drawings, and will be obtained through the implementation of these technical contents. Attached Figure Description

[0051] To more clearly illustrate the technical solution of this application, the accompanying drawings involved in the description of this invention will be briefly introduced below. It should be noted that the drawings only show some embodiments of the invention. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating the overall implementation process of the database master-slave failover method based on performance adaptive evaluation in this application.

[0053] Figure 2 This is the overall design architecture diagram of the closed-loop control system of this application.

[0054] Figure 3 This is a structural diagram of the database master-slave failover system based on performance adaptive evaluation in this application.

[0055] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0057] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0058] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0059] Example: A database master-slave failover method and system based on performance adaptive evaluation

[0060] Figure 1 The diagram shows the overall implementation flow of the database master-slave failover method based on performance adaptive evaluation provided in this application, including the following steps:

[0061] S1. Collect multi-dimensional performance index data of the primary database node and at least one backup database node;

[0062] S2. Evaluate the multi-dimensional performance index data based on the adaptive weight model, and calculate the service health score of the main database node and each backup database node, wherein the adaptive weight model dynamically adjusts the index weights according to the real-time status of each performance index.

[0063] S3. When the service health score of the primary database node meets the switching trigger condition and there is a backup database node with a service health score higher than that of the primary database node, a preventive switching instruction is generated.

[0064] S4. Execute the graceful degradation switchover process to switch business traffic from the primary database node to the target standby database node. The graceful degradation switchover process includes write protection, data catch-up, traffic switching, and role reversal operations executed in sequence.

[0065] The core of this solution lies in constructing a closed-loop control system that integrates data acquisition, adaptive evaluation, proactive decision-making, and graceful switching. The system architecture is as follows: Figure 2 As shown, Figure 2 The hierarchical structure and interaction logic of the three-level core device are presented, including:

[0066] Data acquisition layer (multi-dimensional performance data acquisition device): collects primary and standby database performance indicators through monitoring modules such as CPU utilization and memory usage;

[0067] Decision Engine Layer (Adaptive Weighted Health Assessment Device): Through sub-modules such as sliding window statistics and indicator standardization, the collected indicators are synthesized into a "service health score";

[0068] Execution control layer (active failover and graceful degradation device): Based on the service health score, the active decision-making logic module triggers conditions and the graceful degradation module executes the primary / standby failover according to the process;

[0069] Figure 2 It also reflects the signal flow between devices (performance indicators → health score → switching instructions), as well as the streaming replication relationship between the database master node and the backup node, which conforms to the full-process control logic of "collection-evaluation-decision-switching".

[0070] Specifically, this closed-loop system achieves end-to-end control from performance awareness to switching execution through the collaborative work of three core modules. These modules include a multi-dimensional performance data acquisition module, an adaptive weighted health assessment module, and a proactive switching and graceful degradation module. The functions and interaction logic of each module are as follows:

[0071] 1. Multi-dimensional performance data acquisition module (device): The acquisition agent is deployed on the primary and standby database nodes and the underlying infrastructure. It collects core performance indicators through the database native interface and the operating system interface. The acquisition frequency can be configured to the second level (1-30 seconds). The core indicators include: CPU utilization, memory utilization, disk I / O latency, network round-trip latency (RTT), and transactions per second / queries per second (TPS / QPS).

[0072] 2. Adaptive Weighted Health Assessment Module (Device): The core of the system's decision-making process, dynamically calculating the "service health score" of the primary and backup databases based on collected multi-dimensional data. Figure 2 The "Decision Engine Layer" in the system. Specifically, it includes the following sub-modules:

[0073] (1) Sliding window statistics module: Maintain a fixed-length time window for each performance indicator (e.g., the most recent 300 sampling points, corresponding to 5-15 minutes of data), and calculate the moving average (μ) and moving standard deviation (σ) within the window in real time, which respectively characterize the recent "normal baseline" and "fluctuation range" of the indicator;

[0074] (2) Indicator standardization module: Convert the original values ​​of each indicator into standard scores of 0-10, eliminate the difference in dimensions, and the scoring rules support two modes: based on static thresholds (e.g., CPU usage <50% gets 10 points, 50%-80% gets 5-10 points, >90% gets 1 point) and associated with dynamic baselines (the score is inversely proportional to the deviation of (current value - μ) / σ, and the greater the deviation, the lower the probability of the score).

[0075] (3) Adaptive weight calculation module: The weights are dynamically adjusted according to the real-time status of the indicators. The basic weights are preset by the business scenario (e.g., in the financial scenario: IO latency weight 35%, CPU utilization 25%; in the e-commerce scenario: TPS weight 30%, network latency 25%). The dynamic adjustment is triggered based on the following deterministic rules:

[0076] a) Deviation amplification: When the current value of an indicator deviates from its moving average μ by more than Kσ (e.g., K=2, configurable), weight amplification is triggered. The amplification factor is positively correlated with the degree of deviation (e.g., a deviation of 2σ amplifies by 1.5 times, a deviation of 3σ amplifies by 2 times).

[0077] b) Enhanced deterioration trend: When an indicator shows a deteriorating trend for three or more consecutive periods (judged by the slope of linear regression, with a slope <-0.1 indicating deterioration), its weight receives an additional incremental factor (e.g., an increase of 5%-10%).

[0078] c) Top-level critical anomaly: When any indicator exceeds the absolute safety threshold (e.g., replication delay > 10 seconds, CPU utilization > 95% for 1 minute), the weight of that indicator will be set to the maximum value (e.g., 100%), dominating the health score calculation and decision-making;

[0079] (4) Service health score synthesis module: The score of 0-100 is calculated according to the formula "health score = Σ (standard score of indicator × normalized dynamic weight)". The lower the score, the worse the service health (0 points means completely unavailable, 100 points means the best status).

[0080] 3. Proactive Switching and Graceful Degradation Module (Device): Performs preventative switching based on health scores, ensuring data consistency and business continuity through standardized processes. Figure 2 The "Execution Control Layer" in the document contains the following sub-modules:

[0081] (1) Proactive decision-making logic module: A preset health score threshold (e.g., 70 points, configurable) is set. When the following two conditions are met, the system proactively triggers the switchover process instead of waiting for the master database to completely crash:

[0082] a) The main database health score is continuously below the threshold for more than the set time (e.g., 3 consecutive evaluation cycles, corresponding to 3-90 seconds).

[0083] b) At least one backup database has a health score that is significantly higher than that of the primary database (e.g., more than 20 points higher, the difference can be configured).

[0084] (2) Graceful degradation module: It is executed in the following order, with verification nodes between each step to ensure process controllability:

[0085] a) Write protection: Send a command through the database management interface to notify the old master database to enter read-only mode, prevent new transactions from writing, and at the same time retain the execution rights of unfinished transactions;

[0086] b) Data catching up: Real-time monitoring of the replication latency of the target standby database, waiting for its data latency to catch up to zero or within a safe threshold (e.g., latency < 1 second, threshold is configurable), if the latency continues to be higher than the threshold, an alarm is triggered and the standby database is replaced;

[0087] c) Traffic switching: Through database connection middleware or virtual IP (VIP) migration technology, application write traffic is smoothly redirected to the new primary database, while read traffic can be temporarily distributed to other backup databases to share the pressure;

[0088] d) Role reversal: The primary database is officially changed to a writable state, the old primary database is set as the standby database and data synchronization is started, or maintenance is carried out online according to the health status.

[0089] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0090] The following section uses a typical application scenario—"database performance fluctuations during the midday peak business hours of a financial trading system"—to explain in detail the workflow of the closed-loop control system of this invention.

[0091] 1. Scene setting:

[0092] The financial transaction system database uses a master-slave architecture. During the midday settlement period, the master database experienced a surge in complex report queries, causing CPU utilization to consistently exceed 90% and disk I / O latency to increase significantly, but the database processes remained alive.

[0093] 2. System workflow:

[0094] Step 1: Real-time data collection and reporting

[0095] The data collection agent deployed on the primary and standby databases collects metrics such as CPU utilization, IO latency, and TPS every 10 seconds and reports them to the decision engine.

[0096] Step Two: Adaptive Health Assessment

[0097] The decision engine calculates dynamic baselines for various metrics (e.g., a normal CPU baseline of 50%) based on nearly 30 minutes of sliding window data. The current primary database CPU utilization (95%) deviates significantly from the baseline, triggering a weighting adjustment based on rules, amplifying CPU weight as the dominant factor. After comprehensive calculation, the primary database's service health score drops sharply to 30 points (out of 100). The standby database's health score remains at 85 points.

[0098] Step 3: Proactively switch decision-making

[0099] The system detected that the primary database's health score (30 points) has been below the threshold (70 points) for three consecutive periods, while the standby database's health score (85 points) is significantly higher than that of the primary database. The decision engine immediately generates a preventative switchover instruction, designating the standby database with the higher health score as the target new primary database.

[0100] Step 4: Graceful Execution Switch

[0101] Write protection: First, set the original primary database to read-only and suspend new transaction writes.

[0102] Data catch-up: Confirm that the target backup database data has been synchronized to the latest version (delay <1 second).

[0103] Traffic switching: By using virtual IP migration, the write traffic of the transaction system is smoothly switched to the new master database within seconds.

[0104] Role reversal: The standby database is officially promoted to the new primary database, the original primary database is downgraded to the standby database, and synchronization is started.

[0105] 3. Effect Description:

[0106] The entire process was completed automatically within 1 minute. In the absence of any action triggered by the traditional heartbeat mechanism (which did not respond because the master database process was not suspended), this solution proactively and smoothly completed the master-slave switchover when service performance was severely degraded but not completely interrupted, ensuring the continuous and stable operation of financial transaction services.

[0107] Figure 3 The figure shown is a database master-slave failover system based on performance adaptive evaluation proposed in this application. The system includes:

[0108] The multi-dimensional performance data acquisition module is used to collect multi-dimensional performance index data of the primary database node and at least one backup database node.

[0109] An adaptive weight health assessment module is communicatively connected to the multi-dimensional performance data acquisition module. It is used to evaluate the multi-dimensional performance index data based on the adaptive weight model and calculate the service health score of the main database node and each backup database node. The adaptive weight model dynamically adjusts the index weights according to the real-time status of each performance index.

[0110] The switching instruction generation module is used to generate a preventive switching instruction when the service health score of the primary database node meets the switching triggering conditions and there is a backup database node with a service health score higher than that of the primary database node.

[0111] The proactive switching and graceful degradation module is communicatively connected to the adaptive weight health assessment module and is used to execute the graceful degradation switching process, switching business traffic from the primary database node to the target backup database node. The graceful degradation switching process includes write protection, data catch-up, traffic switching, and role reversal operations executed sequentially.

[0112] The above system implements the steps of the database master-slave switchover method based on performance adaptive evaluation disclosed in this application during runtime.

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of systems, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0114] like Figure 4 As shown in the illustration, an embodiment of this application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned database master-slave switchover method based on performance adaptive evaluation.

[0115] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0116] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types:

[0117] Object-oriented programming languages, such as Java, Smalltalk, C++, etc.

[0118] Conventional procedural programming languages, such as "C" or similar programming languages.

[0119] The execution methods of program code include, but are not limited to:

[0120] It runs entirely on the user's computer;

[0121] Part of it executes on the user's computer, and part of it executes on a remote computer;

[0122] Execute as a standalone software package;

[0123] It is executed entirely on a remote computer or server.

[0124] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers via an internet service provider, for example, by utilizing the internet.

[0125] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the database master-slave switching method based on performance adaptive evaluation disclosed in this application.

[0126] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following:

[0127] (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0128] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0129] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0130] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0131] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0132] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0133] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0134] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0135] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0136] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0137] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0138] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for executing the database master-slave failover method based on performance adaptive evaluation disclosed in this application. When this computer program is executed by a processing system, it can achieve the functions defined in the embodiments of this application.

[0139] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0140] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A database master-slave failover method based on performance adaptive evaluation, characterized in that, The method includes: S1. Collect multi-dimensional performance index data of the primary database node and at least one backup database node; S2. Evaluate the multi-dimensional performance index data based on the adaptive weight model, and calculate the service health score of the main database node and each backup database node, wherein the adaptive weight model dynamically adjusts the index weights according to the real-time status of each performance index. S3. When the service health score of the primary database node meets the switching trigger condition and there is a backup database node with a service health score higher than that of the primary database node, a preventive switching instruction is generated. S4. Execute the graceful degradation switchover process to switch business traffic from the primary database node to the target standby database node. The graceful degradation switchover process includes write protection, data catch-up, traffic switching, and role reversal operations executed in sequence.

2. The method according to claim 1, characterized in that, The multi-dimensional performance metrics data mentioned in step S1 include at least: CPU utilization, memory utilization, disk I / O latency, network round-trip latency, transactions per second, or queries per second; The multi-dimensional performance index data is obtained through a collection agent deployed on the database node and underlying infrastructure, with a collection frequency configured from 1 second to 30 seconds.

3. The method according to claim 1, characterized in that, The adaptive weighting model in step S2 includes a sliding window statistics module, which is used to maintain a fixed-length time window for each performance indicator and calculate the moving average and moving standard deviation within the time window to characterize the recent normal baseline and fluctuation range of the indicator.

4. The method according to claim 1, characterized in that, The calculation process of the service health score in step S2 includes: The raw values ​​of each performance indicator are standardized and converted into standard scores ranging from 0 to 10. The standardization process includes segmented scoring based on static thresholds and deviation inverse scoring based on dynamic baselines. Adaptive weights are calculated based on the basic weights of each performance indicator and dynamic adjustment rules. A service health score ranging from 0 to 100 is synthesized based on the standard score and the normalized adaptive weights. The lower the score, the worse the service health.

5. The method according to claim 1, characterized in that, The adaptive weight model described in step S2 dynamically adjusts the weights of each performance indicator based on its real-time status. The dynamic adjustment rules include: Deviation amplification rule: When the current value of a performance indicator deviates from its moving average by more than K times the moving standard deviation, where K is a configurable parameter, the weight of the indicator is amplified according to the degree of deviation, and the amplification factor is positively correlated with the degree of deviation. Trend deterioration enhancement rule: When a performance indicator shows a deteriorating trend for three or more consecutive evaluation periods, an incremental factor is added to the weight of the indicator based on the linear regression slope. Key anomaly top rule: When any performance indicator exceeds the absolute safety red line, the weight of that indicator is set to the maximum value to dominate the health score calculation and decision. The absolute safety red line includes at least one of the following: replication delay greater than 10 seconds, CPU utilization greater than 95% for 1 minute.

6. The method according to claim 1, characterized in that, The switching triggering conditions mentioned in step S3 include: The service health score of the main database node is lower than the preset health score threshold for three consecutive evaluation cycles. The service health score of the backup database node is higher than the service health score of the primary database node by a preset difference or more.

7. The method according to claim 1, characterized in that, The graceful degradation switching process described in step S4 specifically includes: Write protection: Send a write protection command to the master database node to put it into read-only mode and prevent new transactions from writing to it; Data catch-up: Monitor the replication latency of the target backup database node, and perform traffic switching once the data latency approaches zero or is within a preset safety threshold; Traffic switching: Application write traffic is smoothly redirected to the target backup database node through database connection middleware or virtual IP migration technology; Role flipping: Change the target backup database node to a new writable primary database node, and demote the original primary database node to a backup database node.

8. A database master-slave failover system based on performance adaptive evaluation, characterized in that, The system implements the database master-slave failover method based on performance adaptive evaluation as described in any one of claims 1-7 during runtime, and the system includes: The multi-dimensional performance data acquisition module is used to collect multi-dimensional performance index data of the primary database node and at least one backup database node. An adaptive weight health assessment module is communicatively connected to the multi-dimensional performance data acquisition module. It is used to evaluate the multi-dimensional performance index data based on the adaptive weight model and calculate the service health score of the main database node and each backup database node. The adaptive weight model dynamically adjusts the index weights according to the real-time status of each performance index. The switching instruction generation module is used to generate a preventive switching instruction when the service health score of the primary database node meets the switching triggering conditions and there is a backup database node with a service health score higher than that of the primary database node. The proactive switching and graceful degradation module is communicatively connected to the adaptive weight health assessment module and is used to execute the graceful degradation switching process, switching business traffic from the primary database node to the target backup database node. The graceful degradation switching process includes write protection, data catch-up, traffic switching, and role reversal operations executed sequentially.

9. The system according to claim 8, characterized in that, The multi-dimensional performance data acquisition module includes: a CPU utilization monitoring unit, a memory utilization monitoring unit, a disk I / O latency monitoring unit, a network round-trip latency monitoring unit, and a transaction per second / query per second monitoring unit. The adaptive weighted health assessment module includes: a sliding window statistics submodule, used to maintain a fixed-length time window for each performance indicator and calculate the moving average and moving standard deviation; an indicator standardization submodule, used to convert the original values ​​of the performance indicators into standard scores; an adaptive weight calculation submodule, used to dynamically adjust the weights according to the real-time status of the indicators; and a service health score synthesis submodule, used to calculate the service health score based on the standard scores and the normalized dynamic weights. The active switching and graceful degradation module includes: an active decision logic submodule, used to determine whether the switching trigger condition is met; and a graceful degradation submodule, used to execute write protection, data catch-up, traffic switching, and role reversal operations in sequence.

10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the database master-slave switchover method based on performance adaptive evaluation as described in any one of claims 1-7.

Images