A dual-server failover arbitration high availability method and system

Abstract

This invention discloses a dual-server failover arbitration high-availability method and system, relating to the field of industrial software high-availability control. The method includes: obtaining high-availability configurations issued by the management terminal; establishing bidirectional communication between primary and backup nodes; exchanging node operating status data and determining single-active ownership identifiers; identifying system maintenance status; switching preset maintenance strategies; and entering a maintenance suppression window after offline maintenance is restored to online status; classifying active and inactive nodes based on the single-active ownership identifier, and performing monitoring recovery or scanning interception respectively; performing initial fault judgment and consistency verification based on node status, anomaly information, and multi-source detection information to determine takeover permission flags; and when takeover conditions are met, the backup node takes over and maintains single-active operation. Through bidirectional status communication, maintenance suppression windows, anomaly consistency verification, and single-active ownership control, the accuracy of fault takeover, maintenance security, and single-active operation stability are improved, while reducing the risks of erroneous failover and dual-active operation.

Description

Technical Field

[0001] This invention relates to the field of high availability control for industrial software, specifically a dual-server failover arbitration high availability method and system. Background Technology

[0002] With the increasing demands for continuous operation capabilities from industrial control software, database services, and business middleware, dual-server primary / standby deployment has become a common high-availability implementation method. Existing solutions typically use one server as the primary node to handle business operations, while the other server acts as a standby node, maintaining readiness and achieving failover through methods such as heartbeat detection, business health checks, virtual business address migration, or external arbitration.

[0003] In recent years, common technologies include heartbeat-based primary / backup failover, virtual IP-based access point migration, lease-based or leader election-based single-active control, and arbitration mechanisms that use external monitoring nodes for takeover confirmation. These solutions can reduce business downtime and improve system continuity to some extent.

[0004] However, in actual dual-server deployments, the following problems may still exist: First, some solutions mainly rely on heartbeat interruptions or single health check results to trigger takeover, which can easily lead to misjudgments when faced with short-term network jitter, state synchronization delays, or interface anomalies; Second, failover, service keep-alive, external arbitration, and maintenance control are usually implemented separately, lacking a unified control sequence and state coordination; Third, during configuration changes, program upgrades, or manual maintenance, automatic takeover, automatic recovery, or operation interception may interfere with maintenance operations; Fourth, if business programs on inactive nodes are accidentally started manually or automatically restarted by the system, it may still cause the risk of both nodes running simultaneously.

[0005] Therefore, it is necessary to design a more coordinated high-availability control system for state communication, maintenance control, single-active operation, arbitration judgment, and takeover execution in a dual-server environment. Summary of the Invention

[0006] Based on the shortcomings of the prior art described above, the purpose of this invention is to provide a dual-server failover arbitration high-availability method and system to solve the above-mentioned technical problems.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a dual-server failover arbitration high-availability method, comprising: S1: Obtain the dual-server high availability configuration issued by the management terminal, establish bidirectional status communication between the primary node and the backup node, periodically exchange node operation status data, update the node communication status according to the node operation status data received, and determine the single-active ownership identifier. S2: Identify the system maintenance status based on node operation status data, switch the corresponding preset maintenance strategy according to the system maintenance status, and enter the maintenance suppression window when the system is restored from offline maintenance status to online status. The system maintenance status includes offline maintenance status and online status. S3: Determine the node's operational eligibility based on the single-active ownership identifier, divide the nodes into active nodes and inactive nodes, perform controlled object monitoring, abnormal information generation and abnormal recovery on active nodes, and perform controlled object scanning and operation interception on inactive nodes; S4: Perform initial fault judgment based on node running status data and abnormal information. Perform consistency verification on the abnormal items that pass the initial fault judgment and the preset multi-source detection information to obtain valid abnormal items. When the valid abnormal items meet the preset boundary constraints, determine the fault takeover confidence value based on the valid abnormal items. When the fault takeover confidence value reaches the preset takeover threshold, generate a takeover permission flag. S5: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the standby node performs the takeover of the controlled object. After the takeover is completed, the single-active ownership identifier is updated, and the system maintains single-active operation based on the updated single-active ownership identifier.

[0008] The present invention is further configured such that the dual-server high availability configuration and the collection of local node operation information include: Dual-server high availability configuration includes: node identifiers, node roles, node addresses, peer addresses, controlled objects, controlled object status determination rules, service startup order, heartbeat detection cycle, fault determination threshold, arbitration detection method, virtual service address information, external detection interface address, maintenance status, and alarm policies for primary and standby nodes. The dual-server high availability configuration is parsed to obtain the configuration items of the local node and the peer node. The configuration items of the local node and the peer node include: node role, node address, peer address, heartbeat detection cycle, controlled objects, and maintenance status. A bidirectional communication link is established between the master node and the backup node based on the node address and the peer address, and a periodic interaction mechanism is formed based on the heartbeat detection cycle. The node's operational information is collected based on the controlled object and maintenance status. This information includes: node server connection status, controlled object operational status, maintenance status, status collection time, heartbeat transmission and reception status, and anomaly count information. According to the preset data field format of node operation status data, the node operation information is mapped, normalized, time-stamped, updated with anomaly count, and marked with validity to form node operation status data.

[0009] The present invention is further configured such that the communication status of the updating node includes: The node sends its own operational status data and receives operational status data from the peer node through a two-way communication link, and updates its communication status based on the received operational status data.

[0010] The present invention is further configured such that determining the single-active ownership identifier includes: Initial ownership confirmation is performed based on node role, local node running status data, and peer node running status data. When a node is designated as the master node and its running status data is valid, an initial single-active ownership identifier corresponding to the master node is formed. When a node is a standby node and receives a valid initial single-active ownership identifier from the peer node's running status data, it confirms the received initial single-active ownership identifier. When a node is a standby node and does not receive a valid initial single-active ownership identifier within the waiting period determined based on the heartbeat detection cycle, an initial single-active ownership identifier corresponding to the standby node is formed. The initial single-active ownership identifier is associated with and saved as the single-active ownership identifier and the node's running status data.

[0011] The present invention is further configured such that S2 includes: The current system maintenance status is identified by matching the maintenance status in the node running status data and the maintenance status in the dual-server high availability configuration. The current system maintenance status includes offline maintenance status and online status. When the current system maintenance status is offline maintenance status, switch to the preset maintenance strategy corresponding to the offline maintenance status, suppress automatic takeover, arbitration detection and operation interception, and retain node status acquisition, two-way status communication and log recording; When the current system maintenance status is online, switch to the preset maintenance strategy corresponding to the online status, so that node status acquisition, bidirectional status communication, controlled object monitoring and fault judgment are performed according to the dual-server high availability configuration; When the system maintenance status is detected to have switched from offline to online, a maintenance suppression window is created. Within the maintenance suppression window, node status acquisition and two-way status communication are retained, while automatic takeover is suppressed. When the node running status data within the maintenance suppression window continuously meets the preset stability conditions, the running status is determined to be stable and the maintenance suppression window ends. When the node running status data does not meet the preset stability conditions, the maintenance suppression window is maintained.

[0012] The present invention is further configured such that S3 includes: Parse the ownership node information in the single-active ownership identifier, and confirm the correspondence between the ownership node information and the node identifier and node role in the dual-server high availability configuration to obtain the node's running qualification; When a node is qualified to run services, it is classified as an active node; when a node is not qualified to run services, it is classified as an inactive node. When a node is classified as an active node, the operational status of the business program or system service is monitored according to the controlled object, and abnormal information is generated based on the operational status monitoring results. When abnormal information indicates that the controlled object is operating abnormally, the abnormal recovery control rules are determined based on the controlled object, the service startup sequence and the fault judgment threshold, and the abnormal recovery is performed on the controlled object in accordance with the abnormal recovery control rules. The abnormal information and abnormal recovery results are written into the node operation status data. When a node is classified as an inactive node, the business program or system service is scanned according to the controlled object to identify the controlled object that is running in the inactive node. When a controlled object in a running state exists in an inactive node, the running interception is performed on the controlled object, and the running interception result is written into the node running state data.

[0013] The present invention is further configured such that the initial fault determination includes: Based on the data fields of the abnormal information, the abnormal information is read and its status is marked, and the abnormal object, abnormal type, abnormal duration status and abnormal recovery result are extracted. Based on the preset fault judgment conditions, the node communication status, heartbeat transmission and reception status, status acquisition time, controlled object operation status, abnormal count information and abnormal information are initially judged to obtain the abnormal items that pass the initial fault judgment. Anomalies that fail the initial fault assessment are marked as anomalies to be monitored.

[0014] The present invention is further configured such that determining the fault takeover confidence value includes: For anomalies identified through initial fault diagnosis, corresponding multi-source detection information is obtained based on the dual-server high availability configuration. The multi-source detection information includes one or more of the following: arbitration detection results, business address attribution status, business interface response status, and database connection status. The preset consistency verification rules are invoked to perform correlation verification on the anomalies that pass the initial fault judgment and the multi-source detection information to obtain the multi-source detection consistency results, and to determine whether the anomalies and the multi-source detection information meet the preset consistency verification rules. Exceptions that meet the preset consistency verification rules are identified as valid exceptions, and exceptions that do not meet the preset consistency verification rules are identified as isolated exceptions. Boundary constraint judgment is performed on valid anomalies. When a valid anomaly meets the preset boundary constraints, anomaly category evaluation item, anomaly persistence evaluation item, and consistency evaluation item are generated based on the anomaly type, anomaly persistence status, and multi-source detection consistency results of the valid anomaly. The anomaly category evaluation item, anomaly persistence evaluation item, and consistency evaluation item are then comprehensively evaluated according to the preset takeover evaluation rules to determine the fault takeover confidence value.

[0015] The present invention is further configured such that S5 includes: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the controlled object takeover process of the standby node is triggered. Based on the dual-server high availability configuration, the controlled objects to be taken over are determined, and the controlled objects in the standby nodes are started according to the business startup order corresponding to the dual-server high availability configuration. Verify the operational status of the controlled object after startup to generate takeover verification results; When the takeover verification result indicates that the controlled object has been successfully taken over, the single-active ownership identifier is updated, and the standby node is determined as the new active node; Based on the updated single-active ownership identifier, inactive control is implemented for nodes that do not hold a valid single-active ownership identifier, and the single-active operation state of the dual-server system is maintained.

[0016] This invention also provides a dual-server failover arbitration high-availability system, the system comprising: Single-Active Identifier Determination Module: Obtains the dual-server high availability configuration issued by the management terminal, establishes bidirectional status communication between the primary node and the standby node, periodically exchanges node operation status data, updates the node communication status based on the received node operation status data, and determines the single-active ownership identifier. Maintenance control module: Identifies system maintenance status based on node operating status data, switches corresponding preset maintenance strategies according to the system maintenance status, and enters the maintenance suppression window when returning from offline maintenance status to online status. System maintenance status includes offline maintenance status and online status. Single-Active Management Module: Determines the running qualification of nodes based on single-active ownership identifier, divides nodes into active nodes and inactive nodes, performs controlled object monitoring, abnormal information generation and abnormal recovery for active nodes, and performs controlled object scanning and operation interception for inactive nodes; Arbitration decision module: Based on node running status data and abnormal information, it performs initial fault judgment, performs consistency verification on the abnormal items that pass the initial fault judgment and the preset multi-source detection information to obtain valid abnormal items, determines the fault takeover confidence value based on the valid abnormal items when the valid abnormal items meet the preset boundary constraints, and generates a takeover permission flag when the fault takeover confidence value reaches the preset takeover threshold. Takeover and Maintenance Module: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the standby node performs the takeover of the controlled object. After the takeover is completed, the single-active ownership identifier is updated, and the single-active operation of the system is maintained based on the updated single-active ownership identifier.

[0017] This invention provides a dual-server failover arbitration high-availability method and system. The method comprises: S1: obtaining the dual-server high-availability configuration issued by the management terminal, establishing bidirectional status communication between the primary and backup nodes, periodically exchanging node operating status data, updating the node communication status based on the received node operating status data, and determining the single-active ownership identifier; S2: identifying the system maintenance status based on the node operating status data, switching the corresponding preset maintenance strategy according to the system maintenance status, and entering a maintenance suppression window when recovering from offline maintenance status to online status. The system maintenance status includes offline maintenance status and online status; S3: determining the node's operating eligibility based on the single-active ownership identifier, dividing the nodes into active and inactive nodes, and performing controlled operations on the active nodes. The system monitors, generates and recovers from anomalies, and performs controlled object scanning and interception on inactive nodes; S4: Based on node operating status data and anomaly information, it performs initial fault judgment, performs consistency verification on anomalies that pass the initial fault judgment and preset multi-source detection information to obtain valid anomalies, determines the fault takeover confidence value based on the valid anomalies when the valid anomalies meet preset boundary constraints, and generates a takeover permission flag when the fault takeover confidence value reaches a preset takeover threshold; S5: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the standby node performs controlled object takeover, updates the single-active ownership identifier after takeover, and maintains the system's single-active operation based on the updated single-active ownership identifier. The beneficial effects include: Improve fault takeover accuracy: Obtain node operating status through bidirectional status communication, and generate takeover permission flag by combining anomaly information, multi-source detection information, consistency verification and fault takeover confidence value, avoiding switching based solely on heartbeat interruption or single detection result, and reducing the risk of false takeover caused by network jitter and interface anomalies.

[0018] Improve maintenance process safety: By identifying offline and online maintenance statuses and entering a maintenance suppression window after offline maintenance is restored to online status, automatic takeover and arbitration actions can be suppressed during maintenance, upgrades, or configuration changes, reducing the chances of maintenance operations being misjudged as faults.

[0019] Improve the stability of single-active operation: Determine the node's operating qualification by using the single-active ownership identifier, perform monitoring and recovery on active nodes, and perform scanning and interception on inactive nodes. This can prevent inactive nodes from being accidentally started or automatically restarted and providing services to the outside world, thereby reducing the risk of dual-active operation.

[0020] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating a dual-server failover arbitration high availability method is shown as an exemplary embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the structure of a dual-server failover arbitration high-availability system, as shown in an exemplary embodiment of the present invention. Detailed Implementation

[0022] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0023] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0024] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0025] Example 1: A dual-server failover arbitration high availability method, such as Figure 1 As shown, it includes: S1: Obtain the dual-server high availability configuration issued by the management terminal, establish bidirectional status communication between the primary node and the backup node, periodically exchange node operation status data, update the node communication status according to the node operation status data received, and determine the single-active ownership identifier. S2: Identify the system maintenance status based on node operation status data, switch the corresponding preset maintenance strategy according to the system maintenance status, and enter the maintenance suppression window when the system is restored from offline maintenance status to online status. The system maintenance status includes offline maintenance status and online status. S3: Determine the node's operational eligibility based on the single-active ownership identifier, divide the nodes into active nodes and inactive nodes, perform controlled object monitoring, abnormal information generation and abnormal recovery on active nodes, and perform controlled object scanning and operation interception on inactive nodes; S4: Perform initial fault judgment based on node running status data and abnormal information. Perform consistency verification on the abnormal items that pass the initial fault judgment and the preset multi-source detection information to obtain valid abnormal items. When the valid abnormal items meet the preset boundary constraints, determine the fault takeover confidence value based on the valid abnormal items. When the fault takeover confidence value reaches the preset takeover threshold, generate a takeover permission flag. S5: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the standby node performs the takeover of the controlled object. After the takeover is completed, the single-active ownership identifier is updated, and the system maintains single-active operation based on the updated single-active ownership identifier.

[0026] The present invention is further configured such that the dual-server high availability configuration and the collection of local node operation information include: Dual-server high availability configuration includes: node identifiers, node roles, node addresses, peer addresses, controlled objects, controlled object status determination rules, service startup order, heartbeat detection cycle, fault determination threshold, arbitration detection method, virtual service address information, external detection interface address, maintenance status, and alarm policies for primary and standby nodes. The dual-server high availability configuration is parsed to obtain the configuration items of the local node and the peer node. The configuration items of the local node and the peer node include: node role, node address, peer address, heartbeat detection cycle, controlled objects, and maintenance status. A bidirectional communication link is established between the master node and the backup node based on the node address and the peer address, and a periodic interaction mechanism is formed based on the heartbeat detection cycle. The node's operational information is collected based on the controlled object and maintenance status. This information includes: node server connection status, controlled object operational status, maintenance status, status collection time, heartbeat transmission and reception status, and anomaly count information. According to the preset data field format for node operation status data, the node operation information is mapped, normalized, time-stamped, anomaly count updated, and validity marked to form node operation status data. Specifically, the management terminal issues dual-server high availability configuration to the primary and backup nodes through configuration files, database configuration tables, or management terminal interfaces. The dual-server high availability configuration includes the node identifier, node role, node address, peer address, controlled object, controlled object status judgment rules, service startup order, heartbeat detection cycle, fault judgment threshold, arbitration detection method, virtual service address information, external detection interface address, maintenance status, and alarm policy of the primary and backup nodes. Among them, the heartbeat detection cycle is set to one second by default, the fault judgment threshold is set to three consecutive communication failures or three consecutive controlled object anomalies by default, the maintenance status includes offline maintenance status and online status, and the controlled object status judgment rules include process existence, service operation, port accessibility, or health check interface returning normal. After the node server starts, it parses the dual-server high-availability configuration to obtain the configuration items for both the primary and secondary nodes. Based on the primary and secondary addresses, it establishes a bidirectional communication link between the primary and secondary nodes. This bidirectional communication link can be implemented using TCP long connections, WebSocket connections, gRPC communication, or HTTP periodic requests. The node server collects its own operational information according to a heartbeat detection cycle. This information includes the node server's connection status, the running status of controlled objects, maintenance status, status collection time, heartbeat transmission and reception status, and anomaly count information. Specifically, the node server's connection status is obtained through communication port listening status and the secondary connection status; the running status of controlled objects is obtained through process queries, service status readings, port probes, or health check interface calls; the maintenance status is obtained through the dual-server high-availability configuration and management terminal status commands; and the anomaly count information is updated based on continuous communication failures, invalid status data, or controlled object anomalies. The node server performs field mapping, status normalization, time stamping, anomaly count updates, and validity marking on its node's operational information according to a preset node operational status data field format. The node operational status data field format includes a node identifier field, a node role field, a node server connection status field, a controlled object operational status field, a maintenance status field, a status acquisition time field, a heartbeat transmission and reception status field, an anomaly count information field, and a validity mark field. The node operational status data is marked as valid when all fields are complete, the status acquisition time does not exceed three heartbeat detection cycles, and the heartbeat transmission and reception status is valid; otherwise, it is marked as invalid. After processing, the node server sends its own node operational status data and receives the peer node's operational status data through a bidirectional communication link. It then updates the node's communication status based on the received results, field completeness, and validity mark, thus providing a unified data foundation for system maintenance status identification, single-active ownership control, initial fault diagnosis, and takeover judgment.

[0027] The present invention is further configured such that the communication status of the updating node includes: The node sends its own operational status data and receives operational status data from the peer node via a bidirectional communication link, updating the node's communication status based on the received data. Specifically, the node's communication status indicates whether the communication link between the primary and backup nodes can support status synchronization, maintenance judgment, initial fault judgment, and takeover judgment. The node's communication status is not directly determined by the result of a single data transmission and reception, but rather updated by combining the data transmission and reception results, the integrity and validity of the peer node's operational status data, and the continuous communication anomaly count, to reduce misjudgments caused by single packet loss or short-term network jitter. The node server sends its own operational status data and receives the peer node's operational status data via the bidirectional communication link according to a heartbeat detection period. The heartbeat detection period is derived from the dual-server high availability configuration issued by the management end, with a default value of one second. The bidirectional communication link can be implemented using TCP long connections, WebSocket connections, gRPC communication, or HTTP periodic requests, with TCP long connections being the preferred method. The node's operational status data includes node identifier, node role, node server connection status, controlled object operational status, maintenance status, status acquisition time, heartbeat transmission and reception status, anomaly count information, and validity flags. Specifically, the node identifier and node role are derived from the dual-server high-availability configuration; the node server connection status is derived from the communication port listening status and peer connection establishment status; the controlled object operational status is derived from process queries, service status reads, port probes, or health check interface call results; the maintenance status is derived from the dual-server high-availability configuration and management terminal maintenance commands; the status acquisition time is generated by the node server according to the local system time; the heartbeat transmission and reception status is derived from the status data transmission and reception results within the current heartbeat detection period; the anomaly count information is derived from the statistical results of continuous communication failures, invalid status data, or controlled object anomalies; and the validity flag is determined by field completeness, the validity of the status acquisition time, and the heartbeat transmission and reception status. Within each heartbeat detection period, the node server determines whether it has received peer node operational status data and checks whether the peer node's operational status data has complete fields, is within the valid time range, and has a valid validity flag. The valid time range is set based on the heartbeat detection cycle, and by default, it does not exceed three heartbeat detection cycles. For example, if the heartbeat detection cycle is one second, and the time between the acquisition of the peer node's running status data and the current time is no more than three seconds, then the time is considered valid. Based on the reception of the node's running status data, the communication results are categorized as normal reception, abnormal reception, and recovered reception. Normal reception indicates that complete and valid peer node running status data was received within the heartbeat detection cycle; abnormal reception indicates that no peer node running status data was received, or that the peer node's running status data has missing fields, a timeout, or an invalid validity flag; recovered reception indicates that there was a reception abnormality in the previous cycle, and valid peer node running status data has been received again in the current cycle.When the communication result is normal reception, the node's communication status is updated to normal communication, and the continuous communication anomaly count is cleared. When the communication result is abnormal reception, the continuous communication anomaly count increases. If the continuous communication anomaly count does not reach the preset communication anomaly threshold, the node's communication status is updated to unstable communication. If the continuous communication anomaly count reaches the preset communication anomaly threshold, the node's communication status is updated to abnormal communication. When the communication result is restored reception, the node's communication status is updated to normal communication, and the continuous communication anomaly count is cleared. The preset communication anomaly threshold is set according to the heartbeat detection cycle, with a default value of three consecutive abnormal receptions. Through the above processing, the node's communication status can reflect the reliability of status data interaction between the primary node and the standby node within a continuous period, rather than the result of a single status packet transmission and reception. The updated node communication status is written into the node's operating status data and serves as the data basis for subsequent system maintenance status identification, node operating qualification judgment, initial fault judgment, and takeover permission flag generation.

[0028] The present invention is further configured such that determining the single-active ownership identifier includes: Initial ownership confirmation is performed based on node role, local node running status data, and peer node running status data. When a node is designated as the master node and its running status data is valid, an initial single-active ownership identifier corresponding to the master node is formed. When a node is a standby node and receives a valid initial single-active ownership identifier from the peer node's running status data, it confirms the received initial single-active ownership identifier. When a node is a standby node and does not receive a valid initial single-active ownership identifier within the waiting period determined based on the heartbeat detection cycle, an initial single-active ownership identifier corresponding to the standby node is formed. The initial single-active ownership identifier is associated with and stored in the node's operational status data. Specifically, the single-active ownership identifier is used to represent the node currently qualified to operate services in the dual-server system, and serves as the basis for determining active nodes, intercepting inactive nodes, and subsequent takeover updates. The single-active ownership identifier includes ownership node information, generation time, ownership source, identifier version, and validity status; the ownership node information is used to represent the node currently qualified to operate services, and the ownership source is used to distinguish whether it is formed during the initialization of the primary node, the confirmation received by the standby node, or the standby node waiting for timeout. Node roles are derived from the dual-server high-availability configuration issued by the management terminal, including primary and standby nodes; the operational status data of this node is collected and organized by the node server; the operational status data of the peer node is received through the bidirectional communication link; the heartbeat detection cycle is derived from the dual-server high-availability configuration, with a default value of one second; the waiting period is determined according to the heartbeat detection cycle, which is set to three heartbeat detection cycles by default, and can also be set to three to five heartbeat detection cycles depending on network latency. During the initial ownership confirmation process, the node server reads the node role, its own node's running status data, and the peer node's running status data, and determines whether its own node's running status data is valid. If the nodes' running status data fields are complete, the status collection time does not exceed three heartbeat detection cycles, and the validity is marked as valid, the nodes' running status data is considered valid; otherwise, it is considered invalid. When the node role is the primary node and its own running status data is valid, the node server generates an initial single-active ownership identifier corresponding to the primary node, writes the primary node's node identifier into the ownership node information, writes the current system time into the generation time, marks the ownership source as the primary node's initialization, and marks the validity status as valid. Subsequently, the initial single-active ownership identifier is written into the nodes' running status data and synchronized to the backup node via a bidirectional communication link. When the node role is the backup node and receives a valid initial single-active ownership identifier from the peer node's running status data, the backup node confirms the initial single-active ownership identifier. The confirmation includes whether the ownership node information exists, whether the generation time is valid, whether the identifier version is valid, and whether the validity status is valid. After confirmation, the standby node uses the received initial single-active ownership identifier as its locally stored single-active ownership identifier. When a node is a standby node and has not received a valid initial single-active ownership identifier during the waiting period, the standby node generates an initial single-active ownership identifier corresponding to itself, writes the standby node's node identifier into the ownership node information, writes the current system time into the generation time, marks the ownership source as standby node waiting for timeout, and marks the validity status as valid. This process is used to handle situations where the primary node starts abnormally, the primary node fails to complete the initial ownership transmission, or the communication link is not established in time. After the initial single-active ownership identifier is generated or confirmed, the node server uses the initial single-active ownership identifier as the single-active ownership identifier and saves it in association with the node's running status data.Association storage can be implemented using a local in-memory state table, a local configuration cache, or a lightweight state database. Through the above processing, the eligibility for business operation can be clearly defined during the system initialization phase, and a continuous basis can be provided for subsequent active node division, inactive node interception, and ownership updates after takeover.

[0029] The present invention is further configured such that S2 includes: The current system maintenance status is identified by matching the maintenance status in the node running status data and the maintenance status in the dual-server high availability configuration. The current system maintenance status includes offline maintenance status and online status. When the current system maintenance status is offline maintenance status, switch to the preset maintenance strategy corresponding to the offline maintenance status, suppress automatic takeover, arbitration detection and operation interception, and retain node status acquisition, two-way status communication and log recording; When the current system maintenance status is online, switch to the preset maintenance strategy corresponding to the online status, so that node status acquisition, bidirectional status communication, controlled object monitoring and fault judgment are performed according to the dual-server high availability configuration; When the system maintenance status is detected to have switched from offline to online, a maintenance suppression window is created. Within the maintenance suppression window, node status acquisition and two-way status communication are retained, while automatic takeover is suppressed. When the node's operational status data within the maintenance suppression window continuously meets the preset stability conditions, the operational status is determined to be stable and the maintenance suppression window ends. When the node's operational status data does not meet the preset stability conditions, the maintenance suppression window is maintained. Specifically, the system maintenance status indicates whether the dual-server high-availability system allows automatic takeover, arbitration detection, and operational interception. The system maintenance status includes offline maintenance status and online status; offline maintenance status is used during program upgrades, configuration modifications, parameter adjustments, or manual verification, while online status is used during normal high-availability operation. The maintenance status in the node operational status data originates from the local maintenance status collected by the node server in each heartbeat detection cycle. The local maintenance status can be obtained from management-side maintenance commands, local status cache, or node server-side operational flags. The maintenance status in the dual-server high-availability configuration originates from the configuration data issued by the management end, representing the target maintenance status set by the management end. The node server reads and matches the two maintenance states mentioned above during each control cycle. When both are online, the current system maintenance state is identified as online. When either maintenance state is offline, or when an offline maintenance command is received from the management terminal, the current system maintenance state is prioritized as offline. Preset maintenance strategies include offline maintenance strategy, online operation strategy, and maintenance recovery suppression strategy. When the current system maintenance state is offline, the offline maintenance strategy is executed, suppressing automatic takeover, arbitration detection, and operation interception, while retaining node status collection, bidirectional status communication, and log recording. Suppressing automatic takeover means that the standby node will not immediately start the controlled object even if an anomaly is detected; suppressing arbitration detection means not actively calling third-party arbitration terminals, external detection interfaces, or business address attribution detection; suppressing operation interception means that during manual maintenance, the controlled object will not be immediately forcibly stopped due to manual startup. When the current system maintenance state is online and not within the maintenance suppression window, the online operation strategy is executed, ensuring that node status collection, bidirectional status communication, controlled object monitoring, anomaly information generation, initial fault judgment, and takeover judgment are performed according to the dual-server high availability configuration. The default heartbeat detection cycle in the online operation strategy is one second, and the default fault judgment threshold is three consecutive communication anomalies or three consecutive controlled object anomalies. When the node server detects that the system maintenance status has switched from offline maintenance to online maintenance, a maintenance suppression window is created. The maintenance suppression window lasts for sixty seconds by default, but can also be set from thirty to one hundred and twenty seconds depending on the controlled object startup time and network recovery time. Within the maintenance suppression window, the node server continues to collect node status and conduct bidirectional status communication, and continues to suppress automatic takeover to avoid short-term fluctuations that may trigger erroneous takeover during the initial stages of service recovery, status synchronization, or network recovery.The preset stability conditions are used to determine whether the maintenance suppression window has ended. These conditions include: the maintenance status in the node's operational status data remains online; the node's communication status remains normal; the validity marker in the node's operational status data remains valid; the controlled object's operational status does not exhibit continuous anomalies; and the anomaly count information has not reached the fault judgment threshold. By default, the preset stability conditions need to be met continuously for five heartbeat detection cycles; when the heartbeat detection cycle is one second, five consecutive seconds of stability is considered a stable operational status. If the preset stability conditions are met, the maintenance suppression window ends and the complete online operation strategy is restored; if the preset stability conditions are not met, the maintenance suppression window is maintained and the reason for not meeting the conditions is recorded; if the maintenance suppression window reaches the preset window time and the preset stability conditions are still not met, the maintenance suppression window is maintained and log recording, management terminal page prompts, or message notifications are triggered. Through the above processing, the offline maintenance status is used to isolate manual maintenance operations and automatic high-availability control, and the maintenance suppression window is used to isolate transient fluctuations and real faults in the initial stage of maintenance recovery, thereby reducing the risk of accidental takeover during maintenance and accidental switchover during the recovery phase.

[0030] The present invention is further configured such that S3 includes: Parse the ownership node information in the single-active ownership identifier, and confirm the correspondence between the ownership node information and the node identifier and node role in the dual-server high availability configuration to obtain the node's running qualification; When a node is qualified to run services, it is classified as an active node; when a node is not qualified to run services, it is classified as an inactive node. When a node is classified as an active node, the operational status of the business program or system service is monitored according to the controlled object, and abnormal information is generated based on the operational status monitoring results. When abnormal information indicates that the controlled object is operating abnormally, the abnormal recovery control rules are determined based on the controlled object, the service startup sequence and the fault judgment threshold, and the abnormal recovery is performed on the controlled object in accordance with the abnormal recovery control rules. The abnormal information and abnormal recovery results are written into the node operation status data. When a node is classified as an inactive node, the business program or system service is scanned according to the controlled object to identify the controlled object that is running in the inactive node. When a controlled object is running in an inactive node, the running object is intercepted, and the interception result is written to the node's running status data. Specifically, the single-active ownership identifier is used to indicate the node currently qualified to run services. The single-active ownership identifier includes ownership node information, generation time, ownership source, identifier version, and validity status. Ownership node information points to the node that is allowed to run services; generation time is used to determine whether the single-active ownership identifier is valid; ownership source is used to distinguish between initialization, takeover update, or manual confirmation; identifier version is used to distinguish ownership records in different switchover phases; and validity status indicates whether the single-active ownership identifier can be used to determine node running qualifications. The node server reads the single-active ownership identifier and reads the node identifier, node role, controlled object, service startup order, and fault judgment threshold from the dual-server high availability configuration. The node identifier is used to uniquely identify the node; the node role is used to indicate the initial primary / backup relationship; the controlled object is used to indicate the business program, system service, or business unit that needs to be monitored, restored, or intercepted; the service startup order is used to determine the recovery order of multiple controlled objects; and the fault judgment threshold is used to determine the degree of anomaly before execution of restoration or alarm. The node server parses the ownership node information from the single-active ownership identifier and confirms its correspondence with the node identifier and node role in the dual-server high-availability configuration. If the ownership node information corresponds to the node and the single-active ownership identifier is valid, the node is determined to have business operation permissions and is classified as an active node. If the ownership node information does not correspond to the node or the single-active ownership identifier is invalid, the node is determined not to have business operation permissions and is classified as an inactive node. This method dynamically determines node operation eligibility based on the single-active ownership identifier, rather than solely relying on fixed primary / backup roles. When a node is classified as an active node, the node server monitors the operational status of business programs or system services according to the controlled object list. Business programs can determine their operational status through process query, process name matching, process identifier detection, port probe, or health check interface calls; system services can read their service status through the system service management interface. The operational status can be normalized to running normally, running abnormally, starting, or stopping. When a controlled object malfunctions, the node server generates exception information, including the exception object, exception type, exception occurrence time, exception duration, exception count, and exception recovery result. Exception types can include process non-existence, service stoppage, port inaccessibility, health check failure, or startup timeout. The node server determines exception recovery control rules based on the controlled object, service startup order, and fault determination threshold. For a single controlled object, a restart or reboot is performed; for multiple dependent controlled objects, recovery is performed according to the service startup order. The fault determination threshold is set by default to three consecutive controlled object exceptions, but can be set to two to five consecutive exceptions depending on service importance. After recovery, the exception information and exception recovery result are written to the node's runtime status data.When a node is classified as inactive, the node server does not actively start controlled objects. Instead, it continuously scans its local business applications and system services according to the controlled object list. If a running controlled object is found in an inactive node, runtime interception is executed. For business applications, the process can be terminated; for system services, the service can be stopped or automatic recovery can be disabled. After runtime interception is completed, the intercepted object, interception time, interception reason, and interception result are written to the node's runtime status data. Through this process, active nodes are used to maintain continuous business operation, while inactive nodes are used to prevent business operation. This ensures that single-active control is implemented at the actual operational level of business applications and system services, thereby reducing the risk of two servers simultaneously providing services.

[0031] The present invention is further configured such that the initial fault determination includes: Based on the data fields of the abnormal information, the abnormal information is read and its status is marked, and the abnormal object, abnormal type, abnormal duration status and abnormal recovery result are extracted. Based on the preset fault judgment conditions, the node communication status, heartbeat transmission and reception status, status acquisition time, controlled object operation status, abnormal count information and abnormal information are initially judged to obtain the abnormal items that pass the initial fault judgment. Anomalies that fail the initial fault assessment are marked as anomalies to be monitored. Specifically, the initial fault assessment is used to preliminarily screen anomalies before arbitration detection and takeover judgment, avoiding single state fluctuations, short-term communication delays, or instantaneous anomalies of controlled objects from directly triggering the takeover process. The inputs for the initial fault assessment include node communication status, heartbeat transmission and reception status, status acquisition time, controlled object running status, anomaly count information, and anomaly information. The above data comes from node running status data and the active node monitoring process. Anomaly information is generated by active nodes when monitoring and recovering from anomalies of controlled objects. Anomaly information includes the anomaly object, anomaly type, anomaly duration, and anomaly recovery result. The anomaly object comes from the list of controlled objects in the dual-server high availability configuration; the anomaly type includes process non-existence, service stoppage, port inaccessibility, health check failure, startup timeout, or continuous recovery failure; the anomaly duration is determined based on the continuous anomaly cycle and anomaly count information; the anomaly recovery result includes recovery success, recovery failure, pending recovery, or exceeding the recovery count. The node server reads and marks the data fields of the exception information, extracts the exception object, exception type, exception duration, and exception recovery result, and determines whether the exception information meets the conditions for initial fault diagnosis. Node communication status is derived from the node's operational status data reception, including normal communication, unstable communication, and abnormal communication. Heartbeat transmission and reception status is derived from the sending and receiving results of status data packets within each heartbeat detection cycle, with the default heartbeat detection cycle set to one second. The status acquisition time is generated by the node server when collecting node operational status data and is used to determine whether the node operational status data has timed out; by default, if it has not been updated for more than three heartbeat detection cycles, it is considered a status timeout. The controlled object's operational status is derived from process queries, service status reads, port probes, or health check interface call results, and normalized to normal operation, abnormal operation, starting, or stopping. Exception count information is derived from the statistical results of continuous communication failures, continuous heartbeat anomalies, continuous invalid status data, or continuous controlled object anomalies. The preset fault judgment conditions are derived from the fault judgment threshold and controlled object status judgment rules in the dual-server high availability configuration. The default fault judgment threshold is three consecutive anomalies, but it can also be set to two to five consecutive anomalies depending on the business importance. The preset fault judgment conditions include one or more of the following: node communication status is abnormal, heartbeat transmission and reception status is continuously abnormal, status collection time exceeds the valid time range, controlled object running status is continuously abnormal, anomaly count information reaches the fault judgment threshold, and anomaly recovery result is recovery failure or exceeding the recovery count. When an anomaly meets the preset fault judgment conditions, the node server marks the anomaly as an anomaly that has passed the initial fault judgment and outputs it to the subsequent consistency verification process; when an anomaly does not meet the preset fault judgment conditions, the node server marks the anomaly as an anomaly to be monitored and continues to observe it in the subsequent heartbeat detection cycle.The above processing can filter out transient anomalies such as a single heartbeat failure, a single health check failure, or a single port probe timeout, thereby improving the reliability of subsequent arbitration detection and takeover judgment.

[0032] The present invention is further configured such that determining the fault takeover confidence value includes: For anomalies identified through initial fault diagnosis, corresponding multi-source detection information is obtained based on the dual-server high availability configuration. The multi-source detection information includes one or more of the following: arbitration detection results, business address attribution status, business interface response status, and database connection status. The preset consistency verification rules are invoked to perform correlation verification on the anomalies that pass the initial fault judgment and the multi-source detection information to obtain the multi-source detection consistency results, and to determine whether the anomalies and the multi-source detection information meet the preset consistency verification rules. Exceptions that meet the preset consistency verification rules are identified as valid exceptions, and exceptions that do not meet the preset consistency verification rules are identified as isolated exceptions. For valid anomalies, boundary constraints are assessed. When a valid anomaly meets preset boundary constraints, anomaly category evaluation items, anomaly persistence evaluation items, and consistency evaluation items are generated based on the anomaly type, anomaly persistence status, and multi-source detection consistency results of the valid anomaly. These evaluation items are then comprehensively evaluated according to preset takeover evaluation rules to determine the fault takeover confidence value. Specifically, the fault takeover confidence value represents the degree of trustworthiness of the standby node taking over the primary node's services. This generation process occurs after the initial fault assessment to avoid triggering takeover based solely on a single heartbeat anomaly or a single health check anomaly. The input to the fault takeover confidence value includes anomalies that pass the initial fault assessment and multi-source detection information. Anomalies originate from the initial fault assessment process, while multi-source detection information comes from the arbitration detection method in the dual-server high availability configuration, virtual service address information, external detection interface addresses, and service dependency resource detection configuration. Multi-source detection information includes one or more of the following: arbitration detection results, service address attribution status, service interface response status, and database connection status. Arbitration test results are obtained through third-party arbitration, management testing interfaces, or external monitoring interfaces; business address attribution status is obtained through virtual business address binding status, network interface address, or address drift detection commands; business interface response status is obtained through health check interfaces, business activity detection interfaces, or port probes; database connection status is obtained through database connection tests, connection pool probes, or dependency resource detection interfaces. Pre-defined consistency verification rules are configured by the management end or pre-set by the system to determine whether anomalies corroborate multi-source detection information. For example, a heartbeat anomaly needs to be corroborated by at least one of the following: arbitration detection unreachable, business interface unresponsive, or business address not in the master node; a controlled object operation anomaly needs to be corroborated by a business interface response anomaly or port inaccessibility; a business address attribution anomaly needs to be corroborated by a node communication anomaly or arbitration detection anomaly. The node server performs correlation verification on the anomalies that pass the initial fault judgment and multi-source detection information according to the pre-defined consistency verification rules to obtain multi-source detection consistency results. These results can be marked as consistent, partially consistent, or inconsistent. When an anomaly meets the preset consistency verification rules, it is determined to be a valid anomaly. When an anomaly does not meet the preset consistency verification rules, it is determined to be an isolated anomaly, which is not directly used as the basis for takeover. For example, if only the business interface probe fails, but the arbitration detection is normal, the business address still belongs to the master node, and the database connection status is normal, the corresponding anomaly is determined to be an isolated anomaly to avoid false takeover due to a single interface fluctuation. After obtaining valid anomalies, the node server performs boundary constraint judgment. The preset boundary constraints are used to limit the minimum conditions that valid anomalies must meet to support takeover judgment. The default setting is that there must be no fewer than two valid anomalies, or the valid anomalies must contain at least one of the following critical anomalies: node communication anomaly, business unavailability anomaly, or arbitration detection anomaly.If a valid anomaly does not meet the preset boundary constraints, the fault takeover confidence value determination process will not proceed; if a valid anomaly meets the preset boundary constraints, the takeover evaluation process will proceed. During the takeover evaluation, the node server generates anomaly category evaluation items, anomaly persistence evaluation items, and consistency evaluation items based on the anomaly type, anomaly persistence status, and multi-source detection consistency results, respectively. The anomaly category evaluation item represents the importance of the anomaly type, the anomaly persistence evaluation item represents the degree of anomaly persistence, and the consistency evaluation item represents the degree of corroboration between multi-source detection information. Preset takeover evaluation rules are provided by the dual-server high-availability configuration and are used to convert the above evaluation items into a unified takeover confidence level, thereby forming a fault takeover confidence value. The fault takeover confidence value can be represented using normalized levels or numerical methods, with a default takeover threshold set to 0.7. When the fault takeover confidence value reaches the takeover threshold, a takeover permission flag is generated; otherwise, standby monitoring continues. Through the above processing, transient and isolated anomalies can be filtered first, then multi-source detection information can be used to confirm whether the master node has truly lost its service capability, and finally, a unified evaluation item can be used to determine the fault takeover confidence value, thereby improving the reliability of fault takeover decisions and reducing the risk of erroneous failover.

[0033] The present invention is further configured such that S5 includes: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the controlled object takeover process of the standby node is triggered. Based on the dual-server high availability configuration, the controlled objects to be taken over are determined, and the controlled objects in the standby nodes are started according to the business startup order corresponding to the dual-server high availability configuration. Verify the operational status of the controlled object after startup to generate takeover verification results; When the takeover verification result indicates that the controlled object has been successfully taken over, the single-active ownership identifier is updated, and the standby node is determined as the new active node; Based on the updated single-active ownership identifier, inactive control is implemented on nodes that do not hold a valid single-active ownership identifier, maintaining the single-active operation of the dual-server system. Specifically, the controlled object takeover process is used to switch the business operation qualification to the standby node after the standby node meets the takeover conditions, and maintain the single-active operation of the system by updating the single-active ownership identifier. The takeover action must simultaneously meet the following conditions: the takeover permission flag is allowed, the system maintenance status is online, and the maintenance suppression window has ended. Among them, the takeover permission flag is derived from the initial fault judgment, consistency verification, boundary constraint judgment, and fault takeover confidence value judgment; the system maintenance status is derived from the node operation status data and the dual-server high availability configuration; the maintenance suppression window is a transition window created when the system recovers from offline maintenance status to online status, which lasts for 60 seconds by default, and can also be set to 30 to 120 seconds depending on the controlled object startup time and network recovery time. When all the above conditions are met, the standby node triggers the controlled object takeover process; if any condition is not met, the standby node does not start the controlled object, but only maintains status collection, bidirectional status communication, and log recording. The standby node determines the controlled objects to be taken over based on the dual-server high availability configuration and starts them sequentially according to the business startup order. Controlled objects can be business programs, system services, or multiple dependent business units; startup methods can include process startup, system service control interface startup, script startup, or service management tool startup. After the controlled objects start, the standby node verifies their running status, generating a takeover verification result. Verification methods include one or more of the following: process query, system service status reading, port probe, health check interface call, and virtual business address binding status check. The takeover verification result includes takeover success, takeover failure, and takeover in progress. By default, if a controlled object reaches a normal running state within three heartbeat detection cycles after startup, and the health check interface returns normal, the takeover is considered successful. If it fails to reach a normal running state after a preset startup waiting time, the takeover is considered failed. The preset startup waiting time can be set from ten to sixty seconds based on the business startup time. When the takeover verification result is successful, the standby node updates the single-active ownership identifier. The updated single-active ownership identifier includes new ownership node information, generation time, ownership source, identifier version, and validity status. The new ownership node information is written to the node identifier corresponding to the standby node, the ownership source is marked as formed by the standby node takeover, and the validity status is marked as valid. The standby node writes the updated single-active ownership identifier to its own runtime status data and synchronizes it to the peer node and management terminal. After updating the single-active ownership identifier, the standby node is determined as the new active node, and nodes without a valid single-active ownership identifier are treated as inactive nodes.Inactive nodes scan their local business programs and system services according to the controlled object list. If a controlled object is found to be running, it executes a runtime interception; for business programs, the process is terminated; for system services, service is stopped or automatic recovery is disabled, and the interception results are written to the node's running status data. Through the above process, orderly takeover by standby nodes, controlled degradation of the original node, and continuous single-active operation of the dual-server system can be achieved.

[0034] Example 2: Please see Figure 2 This exemplary dual-server failover arbitration high-availability system includes: Single-Active Identifier Determination Module: Obtains the dual-server high availability configuration issued by the management terminal, establishes bidirectional status communication between the primary node and the standby node, periodically exchanges node operation status data, updates the node communication status based on the received node operation status data, and determines the single-active ownership identifier. Maintenance control module: Identifies system maintenance status based on node operating status data, switches corresponding preset maintenance strategies according to the system maintenance status, and enters the maintenance suppression window when returning from offline maintenance status to online status. System maintenance status includes offline maintenance status and online status. Single-Active Management Module: Determines the running qualification of nodes based on single-active ownership identifier, divides nodes into active nodes and inactive nodes, performs controlled object monitoring, abnormal information generation and abnormal recovery for active nodes, and performs controlled object scanning and operation interception for inactive nodes; Arbitration decision module: Based on node running status data and abnormal information, it performs initial fault judgment, performs consistency verification on the abnormal items that pass the initial fault judgment and the preset multi-source detection information to obtain valid abnormal items, determines the fault takeover confidence value based on the valid abnormal items when the valid abnormal items meet the preset boundary constraints, and generates a takeover permission flag when the fault takeover confidence value reaches the preset takeover threshold. Takeover and Maintenance Module: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the standby node performs the takeover of the controlled object. After the takeover is completed, the single-active ownership identifier is updated, and the single-active operation of the system is maintained based on the updated single-active ownership identifier.

[0035] It should be noted that the dual-server failover arbitration high-availability system provided in the above embodiments and the dual-server failover arbitration high-availability method provided in the above embodiments belong to the same concept. The specific methods of operation of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the dual-server failover arbitration high-availability system provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0036] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A dual-server failover arbitration high-availability method, characterized in that, include: S1: Obtain the dual-server high availability configuration issued by the management terminal, establish bidirectional status communication between the primary node and the backup node, periodically exchange node operation status data, update the node communication status according to the node operation status data received, and determine the single-active ownership identifier. S2: Identify the system maintenance status based on node operation status data, switch the corresponding preset maintenance strategy according to the system maintenance status, and enter the maintenance suppression window when the system is restored from offline maintenance status to online status. The system maintenance status includes offline maintenance status and online status. S3: Determine the node's operational eligibility based on the single-active ownership identifier, divide the nodes into active nodes and inactive nodes, perform controlled object monitoring, abnormal information generation and abnormal recovery on active nodes, and perform controlled object scanning and operation interception on inactive nodes; S4: Perform initial fault judgment based on node running status data and abnormal information. Perform consistency verification on the abnormal items that pass the initial fault judgment and the preset multi-source detection information to obtain valid abnormal items. When the valid abnormal items meet the preset boundary constraints, determine the fault takeover confidence value based on the valid abnormal items. When the fault takeover confidence value reaches the preset takeover threshold, generate a takeover permission flag. S5: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the standby node performs the takeover of the controlled object. After the takeover is completed, the single-active ownership identifier is updated, and the system maintains single-active operation based on the updated single-active ownership identifier.

2. The dual-server failover arbitration high availability method according to claim 1, characterized in that, The dual-server high availability configuration and the collection of local node operation information include: Dual-server high availability configuration includes: node identifiers, node roles, node addresses, peer addresses, controlled objects, controlled object status determination rules, service startup order, heartbeat detection cycle, fault determination threshold, arbitration detection method, virtual service address information, external detection interface address, maintenance status, and alarm policies for primary and standby nodes. The dual-server high availability configuration is parsed to obtain the configuration items of the local node and the peer node. The configuration items of the local node and the peer node include: node role, node address, peer address, heartbeat detection cycle, controlled objects, and maintenance status. A bidirectional communication link is established between the master node and the backup node based on the node address and the peer address, and a periodic interaction mechanism is formed based on the heartbeat detection cycle. The node's operational information is collected based on the controlled object and maintenance status. This information includes: node server connection status, controlled object operational status, maintenance status, status collection time, heartbeat transmission and reception status, and anomaly count information. According to the preset data field format of node operation status data, the node operation information is mapped, normalized, time-stamped, updated with anomaly count, and marked with validity to form node operation status data.

3. The dual-server failover arbitration high availability method according to claim 2, characterized in that, The communication status of the update node includes: The node sends its own operational status data and receives operational status data from the peer node through a two-way communication link, and updates its communication status based on the received operational status data.

4. The dual-server failover arbitration high availability method according to claim 3, characterized in that, The identifier for determining single-active ownership includes: Initial ownership confirmation is performed based on node role, local node running status data, and peer node running status data. When a node is designated as the master node and its running status data is valid, an initial single-active ownership identifier corresponding to the master node is formed. When a node is a standby node and receives a valid initial single-active ownership identifier from the peer node's running status data, it confirms the received initial single-active ownership identifier. When a node is a standby node and does not receive a valid initial single-active ownership identifier within the waiting period determined based on the heartbeat detection cycle, an initial single-active ownership identifier corresponding to the standby node is formed. The initial single-active ownership identifier is associated with and saved as the single-active ownership identifier and the node's running status data.

5. The dual-server failover arbitration high availability method according to claim 2, characterized in that, S2 includes: The current system maintenance status is identified by matching the maintenance status in the node running status data and the maintenance status in the dual-server high availability configuration. The current system maintenance status includes offline maintenance status and online status. When the current system maintenance status is offline maintenance status, switch to the preset maintenance strategy corresponding to the offline maintenance status, suppress automatic takeover, arbitration detection and operation interception, and retain node status acquisition, two-way status communication and log recording; When the current system maintenance status is online, switch to the preset maintenance strategy corresponding to the online status, so that node status acquisition, bidirectional status communication, controlled object monitoring and fault judgment are performed according to the dual-server high availability configuration; When the system maintenance status is detected to have switched from offline to online, a maintenance suppression window is created. Within the maintenance suppression window, node status acquisition and two-way status communication are retained, while automatic takeover is suppressed. When the node running status data within the maintenance suppression window continuously meets the preset stability conditions, the running status is determined to be stable and the maintenance suppression window ends. When the node running status data does not meet the preset stability conditions, the maintenance suppression window is maintained.

6. The dual-server failover arbitration high availability method according to claim 2, characterized in that, S3 includes: Parse the ownership node information in the single-active ownership identifier, and confirm the correspondence between the ownership node information and the node identifier and node role in the dual-server high availability configuration to obtain the node's running qualification; When a node is qualified to run services, it is classified as an active node; when a node is not qualified to run services, it is classified as an inactive node. When a node is classified as an active node, the operational status of the business program or system service is monitored according to the controlled object, and abnormal information is generated based on the operational status monitoring results. When abnormal information indicates that the controlled object is operating abnormally, the abnormal recovery control rules are determined based on the controlled object, the service startup sequence and the fault judgment threshold, and the abnormal recovery is performed on the controlled object in accordance with the abnormal recovery control rules. The abnormal information and abnormal recovery results are written into the node operation status data. When a node is classified as an inactive node, the business program or system service is scanned according to the controlled object to identify the controlled object that is running in the inactive node. When a controlled object in a running state exists in an inactive node, the running interception is performed on the controlled object, and the running interception result is written into the node running state data.

7. The dual-server failover arbitration high availability method according to claim 2, characterized in that, The initial fault diagnosis includes: Based on the data fields of the abnormal information, the abnormal information is read and its status is marked, and the abnormal object, abnormal type, abnormal duration status and abnormal recovery result are extracted. Based on the preset fault judgment conditions, the node communication status, heartbeat transmission and reception status, status acquisition time, controlled object operation status, abnormal count information and abnormal information are initially judged to obtain the abnormal items that pass the initial fault judgment. Anomalies that fail the initial fault assessment are marked as anomalies to be monitored.

8. The dual-server failover arbitration high availability method according to claim 7, characterized in that, The confidence value for determining fault takeover includes: For anomalies identified through initial fault diagnosis, corresponding multi-source detection information is obtained based on the dual-server high availability configuration. The multi-source detection information includes one or more of the following: arbitration detection results, business address attribution status, business interface response status, and database connection status. The preset consistency verification rules are invoked to perform correlation verification on the anomalies that pass the initial fault judgment and the multi-source detection information to obtain the multi-source detection consistency results, and to determine whether the anomalies and the multi-source detection information meet the preset consistency verification rules. Exceptions that meet the preset consistency verification rules are identified as valid exceptions, and exceptions that do not meet the preset consistency verification rules are identified as isolated exceptions. Boundary constraint judgment is performed on valid anomalies. When a valid anomaly meets the preset boundary constraints, anomaly category evaluation item, anomaly persistence evaluation item, and consistency evaluation item are generated based on the anomaly type, anomaly persistence status, and multi-source detection consistency results of the valid anomaly. The anomaly category evaluation item, anomaly persistence evaluation item, and consistency evaluation item are then comprehensively evaluated according to the preset takeover evaluation rules to determine the fault takeover confidence value.

9. A dual-server failover arbitration high-availability method according to claim 2, characterized in that, S5 includes: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the controlled object takeover process of the standby node is triggered. Based on the dual-server high availability configuration, the controlled objects to be taken over are determined, and the controlled objects in the standby nodes are started according to the business startup order corresponding to the dual-server high availability configuration. Verify the operational status of the controlled object after startup to generate takeover verification results; When the takeover verification result indicates that the controlled object has been successfully taken over, the single-active ownership identifier is updated, and the standby node is determined as the new active node; Based on the updated single-active ownership identifier, inactive control is implemented for nodes that do not hold a valid single-active ownership identifier, and the single-active operation state of the dual-server system is maintained.

10. A dual-server failover arbitration high-availability system, used to implement the dual-server failover arbitration high-availability method according to any one of claims 1-9, characterized in that, include: Single-Active Identifier Determination Module: Obtains the dual-server high availability configuration issued by the management terminal, establishes bidirectional status communication between the primary node and the standby node, periodically exchanges node operation status data, updates the node communication status based on the received node operation status data, and determines the single-active ownership identifier. Maintenance control module: Identifies system maintenance status based on node operating status data, switches corresponding preset maintenance strategies according to the system maintenance status, and enters the maintenance suppression window when returning from offline maintenance status to online status. System maintenance status includes offline maintenance status and online status. Single-Active Management Module: Determines the running qualification of nodes based on single-active ownership identifier, divides nodes into active nodes and inactive nodes, performs controlled object monitoring, abnormal information generation and abnormal recovery for active nodes, and performs controlled object scanning and operation interception for inactive nodes; Arbitration decision module: Based on node running status data and abnormal information, it performs initial fault judgment, performs consistency verification on the abnormal items that pass the initial fault judgment and the preset multi-source detection information to obtain valid abnormal items, determines the fault takeover confidence value based on the valid abnormal items when the valid abnormal items meet the preset boundary constraints, and generates a takeover permission flag when the fault takeover confidence value reaches the preset takeover threshold. Takeover and Maintenance Module: When the takeover permission flag is enabled, the system maintenance status is online, and the maintenance suppression window has ended, the standby node performs the takeover of the controlled object. After the takeover is completed, the single-active ownership identifier is updated, and the single-active operation of the system is maintained based on the updated single-active ownership identifier.

Images