A master / standby state switching method, system, device and storage medium for a master-multiple-standby mode heterogeneous system
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NARI NANJING CONTROL SYSTEM CO LTD
- Filing Date
- 2025-09-19
- Publication Date
- 2026-08-07
AI Technical Summary
[0003]同构依赖性强:传统方案要求主备系统在厂家版本及版本上高度一致,难以适配当前普遍存在的异构化环境
[0041]有益效果:本发明与现有技术相比,其显著优点是:1、本发明方法引入由三台独立服务器构成的分布式仲裁集群,基于共识算法实现全局状态一致性决策,从根本上杜绝“脑裂”;2、本发明方法中应用通过定期查询切换器的接口或文件来获知自身是主还是备,从而自动调整行为,实现与切换逻辑的彻底解耦;3、本发明核心切换流程采用“预切换-检查反馈-实际切换-状态应答”的多轮闭环机制,极大提升切换成功率与安全性,代理间通过标准文件(E文件)、TCP消息等通用协议交互,确保对不同厂家、不同版本的异构系统的广泛适应性。本发明实现了高安全、智能、低侵入的“一主多备”异构系统切换,为电网关键业务提供了可靠的安全防线。
Smart Images

Figure CN121239559B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of power dispatch automation technology, and in particular to a method, system, device and storage medium for switching between primary and standby states in a heterogeneous system with a primary-multiple-standby mode. Background Technology
[0002] In power grid dispatch and control centers, the stable operation of SCADA and AGC is directly related to power grid security. However, many existing solutions focus on model / data synchronization or communication channel switching, lacking sufficient reliability in consistent arbitration of global primary / backup states, secure transfer of control authority (such as SCADA / AGC), and heterogeneous adaptability. Specifically, these include:
[0003] Strong homogeneity dependency: Traditional solutions require the primary and backup systems to be highly consistent in terms of manufacturer version and version, which makes it difficult to adapt to the current heterogeneous environment.
[0004] Split-brain risk: Traditional master-slave switching often relies on arbitration and is basically manual. In abnormal situations such as network partitions, the master-slave switching system is prone to a situation where both sides believe they are the master node, i.e., "split-brain", which leads to business chaos.
[0005] The switching strategy is simple: most solutions trigger switching based on simple conditions such as heartbeat timeout, lacking a comprehensive judgment of the system's true health, which can easily lead to accidental switching or switching without any real action.
[0006] Highly invasive: Switching logic often deeply intrudes into business systems, requiring modifications to business code or configurations, resulting in high coupling, complex implementation, and difficult maintenance.
[0007] Lack of closed-loop control: The switching process is often a one-way command, lacking confirmation and feedback mechanisms for the switching preparation status and switching execution results, resulting in insufficient safety. Summary of the Invention
[0008] Purpose of the invention: The purpose of this invention is to provide a method for switching the primary / standby status of heterogeneous systems that solves the split-brain problem and has intelligent judgment capabilities and a safe closed-loop process; another purpose of this invention is to provide a primary / standby status switching system, device and storage medium for heterogeneous systems in a one-primary-multiple-standby mode.
[0009] Technical solution: The method for switching between primary and standby states in a heterogeneous system with one primary and multiple standby modes, as described in this invention, includes...
[0010] Construct a distributed arbitration cluster based on the Raft or Paxos consensus algorithm to adjudicate all primary and backup state transactions in the system; the distributed arbitration cluster includes at least three independent servers;
[0011] On each business node in the heterogeneous system that needs to participate in the primary / standby status determination, a switcher is deployed; on the agent node that is connected to the network of all business nodes, a switching agent is deployed; the switcher on the business node establishes a communication connection with the switching agent on the agent node, and the switching agent establishes a communication connection with the arbitration cluster.
[0012] The switch on the service node periodically collects the health status, resource utilization, and network metrics of the node in the first cycle T1. It obtains service status data by reading a preset standard format status file. The switch encapsulates the above status data into a heartbeat packet and sends it to the switch agent it is connected to.
[0013] The switching agent, in the second period T2, aggregates the heartbeat packets reported by all the service node switching agents it is connected to and forwards them to the arbitration cluster;
[0014] The arbitration cluster uses a consensus algorithm to obtain a primary and backup status view based on the received status heartbeat packets, thus confirming the primary and backup systems.
[0015] When the arbitration cluster determines that the switching conditions are met, it triggers a closed-loop switching process involving multiple rounds of interaction: The arbitration cluster initiates a pre-switching request to the target new master node and the switcher of the current master node through the relevant switching agent; After receiving the request, each switcher performs a self-check of local resources, business status, and data synchronization integrity, and feeds back the self-check results to the arbitration cluster through the switching agent; After collecting all feedback, if the arbitration cluster confirms that the switching is safe, it issues an "execute switch" command to the relevant switchers through the switching agent; After each switcher performs the switching operation, it replies with confirmation information to the arbitration cluster through the switching agent.
[0016] After the switchover is complete, the arbitration cluster sends the final primary / standby status view to all switch agents, which then distribute it to their respective connected switches. The switches then provide the received final status to the SCADA, AGC, and other upper-layer business applications that require mutually exclusive access by providing standardized service interfaces and / or updating local shared status files. Each application actively obtains and adapts to the current primary / standby status by periodically querying this interface or file, thereby decoupling business functions from the high-availability switchover mechanism.
[0017] Furthermore, the closed-loop switching process for multi-round interactions is as follows:
[0018] Pre-switch phase: The arbitration cluster sends a pre-switch request to the standby node that is pre-selected as the new master and the switcher of the current master node through the switching agent;
[0019] Inspection and feedback phase: After receiving the request, each switcher checks the local resource availability, whether the business service can be started and stopped, and whether the required data files have been synchronized. It then replies to the arbitration cluster with "ready ACK" or "reject switch with reason NACK" through the switch agent.
[0020] Arbitration and Command Phase: The arbitration cluster waits for a preset timeout to collect feedback; if all necessary nodes reply with "ACK", the cluster reaches a consensus and issues an "execute switch" command; if any node replies with "NACK" or fails to reply within the timeout period, the switch is terminated and an alarm is generated.
[0021] Execution and confirmation phase: After receiving the "execute switch" instruction, the switcher executes the predefined switch script, and after completion, sends a "switch complete" confirmation message to the arbitration cluster through the switch agent;
[0022] State synchronization and publication phase: After the arbitration cluster confirms the successful switch of the new master node, it updates the global state view and publishes it downwards through the switch agent-switcher chain path; applications on each business node obtain the latest state by periodically querying the state interface or file provided by the local switcher.
[0023] Furthermore, the communication between the switcher and the switching agent, and between the switching agent and the arbitration cluster, all adopt standardized interfaces, including TCP Socket messages and reading and writing standard format files.
[0024] Furthermore, the switching decision of the arbitration cluster is based on statically configured node priorities and dynamic adjustment factors. The dynamic adjustment factors are determined by the node's real-time health score, network latency, CPU / memory resource availability, and data synchronization latency.
[0025] The master / standby state switching system for heterogeneous systems in a master-slave mode, as described in this invention, includes:
[0026] A distributed arbitration cluster, consisting of at least three server nodes, serves as the decision-making center for heterogeneous systems. It receives state heartbeat packets, obtains the primary and backup state views through a consensus algorithm, and confirms the primary and backup systems.
[0027] The switcher is located on each service node in the heterogeneous system that needs to participate in the primary / standby status determination. It is used to collect the health status, resource utilization, and network indicators of the node at regular intervals of the first period T1. It obtains service status data by reading a preset standard format status file. The switcher encapsulates the above status data into a heartbeat packet and sends it to the switcher agent it is connected to.
[0028] A switching agent is deployed on an agent node that is connected to the network of all business nodes. It is used to aggregate the heartbeat packets reported by the switching agents of all business nodes connected to it in the second period T2 and forward them to the arbitration cluster.
[0029] The management configuration module is used to configure arbitration policies, node priorities, heartbeat cycles, and timeout parameters. When the arbitration cluster determines that the switching conditions are met, it triggers a closed-loop switching process involving multiple rounds of interaction: The arbitration cluster initiates a pre-switching request to the target new master node and the switcher of the current master node through relevant switching agents; After receiving the request, each switcher performs a self-check of local resources, business status, and data synchronization integrity, and feeds back the self-check results to the arbitration cluster through the switching agent; After collecting all feedback, if the arbitration cluster confirms that the switching is safe, it issues an "execute switch" command to the relevant switchers through the switching agent; After each switcher executes the switching operation, it replies with confirmation information to the arbitration cluster through the switching agent.
[0030] After the switchover is complete, the arbitration cluster sends the final primary / standby status view to all switch agents, which then distribute it to their respective connected switches. The switches then provide the received final status to the SCADA, AGC, and other upper-layer business applications that require mutually exclusive access by providing standardized service interfaces and / or updating local shared status files. Each application actively obtains and adapts to the current primary / standby status by periodically querying this interface or file, thereby decoupling business functions from the high-availability switchover mechanism.
[0031] Furthermore, in the management configuration module, the closed-loop switching process for multi-round interactions is as follows:
[0032] Pre-switch phase: The arbitration cluster sends a pre-switch request to the standby node that is pre-selected as the new master and the switcher of the current master node through the switching agent;
[0033] Inspection and feedback phase: After receiving the request, each switcher checks the local resource availability, whether the business service can be started and stopped, and whether the required data files have been synchronized. It then replies to the arbitration cluster with "ready ACK" or "reject switch with reason NACK" through the switch agent.
[0034] Arbitration and Command Phase: The arbitration cluster waits for a preset timeout to collect feedback; if all necessary nodes reply with "ACK", the cluster reaches a consensus and issues an "execute switch" command; if any node replies with "NACK" or fails to reply within the timeout period, the switch is terminated and an alarm is generated.
[0035] Execution and confirmation phase: After receiving the "execute switch" instruction, the switcher executes the predefined switch script, and after completion, sends a "switch complete" confirmation message to the arbitration cluster through the switch agent;
[0036] State synchronization and publication phase: After the arbitration cluster confirms the successful switch of the new master node, it updates the global state view and publishes it downwards through the switch agent-switcher chain path; applications on each business node obtain the latest state by periodically querying the state interface or file provided by the local switcher.
[0037] Furthermore, communication between the switcher and the switch agent, and between the switch agent and the arbitration cluster, uses standardized interfaces, including TCP Socket messages and reading and writing standard format files.
[0038] Furthermore, the decision-making basis for the arbitration cluster switching includes statically configured node priorities and dynamic adjustment factors. The dynamic adjustment factors are determined by the node's real-time health score, network latency, CPU / memory resource availability, and data synchronization latency.
[0039] The computer device of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above method.
[0040] The computer-readable storage medium of the present invention stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.
[0041] Beneficial Effects: Compared with existing technologies, the significant advantages of this invention are: 1. The method of this invention introduces a distributed arbitration cluster composed of three independent servers, achieving global state consistency decision-making based on a consensus algorithm, fundamentally eliminating "split-brain" scenarios; 2. The method of this invention uses periodic queries of the switcher's interface or files to determine whether it is a primary or backup, thereby automatically adjusting its behavior and achieving complete decoupling from the switching logic; 3. The core switching process of this invention adopts a multi-round closed-loop mechanism of "pre-switching - check feedback - actual switching - status response," greatly improving the switching success rate and security. Agents interact through standard files (E-files), TCP messages, and other common protocols, ensuring broad adaptability to heterogeneous systems from different manufacturers and versions. This invention achieves highly secure, intelligent, and low-intrusion "one primary, multiple backup" heterogeneous system switching, providing a reliable security defense for critical power grid operations. Attached Figure Description
[0042] Figure 1 A schematic diagram of the primary / standby status of a heterogeneous system with one primary and multiple backups.
[0043] Figure 2 This is a schematic diagram of a primary and two backup architecture. Detailed Implementation
[0044] The method for switching between primary and standby states in a heterogeneous system with a primary-multiple-standby mode, as described in this invention, includes the following steps:
[0045] Step S101: Construct a distributed arbitration cluster consisting of at least three independent servers. The arbitration cluster runs based on the Raft or Paxos consensus algorithm and is used to adjudicate all master-slave state transactions in the system, fundamentally avoiding split-brain.
[0046] Step S102: Deploy a lightweight switcher on each service node in the heterogeneous system that needs to participate in the primary / standby status determination; deploy a switching agent on the agent node that is connected to the network of all service nodes; establish a communication connection between the switcher on the service node and the switching agent on the agent node, and establish a communication connection between the switching agent and the arbitration cluster; the communication between the switcher and the switching agent, and between the switching agent and the arbitration cluster, all adopt standardized interfaces, including TCP Socket messages and reading and writing standard format files (E files), to adapt to heterogeneous environments with different operating systems and software from different manufacturers.
[0047] Step S103: The switch on the service node periodically collects the health status, resource utilization, and network indicators of the node in the first period T1, and obtains the service status data by reading the preset standard format status file (E file); then, the switch encapsulates the above status data into a heartbeat packet and sends it to the switching agent connected to it; the switch on the service node collects and reports the status at a higher frequency (T1), while the switching agent performs aggregation and forwarding at a slightly lower frequency (T2), thereby ensuring the real-time status while reducing the communication processing pressure on the arbitration cluster.
[0048] Step S104: The switching agent aggregates the heartbeat packets reported by all the service node switches connected to it in the second period T2 and forwards them to the arbitration cluster.
[0049] Step S105: The arbitration cluster reaches a consensus through a consensus algorithm based on all received state heartbeat packets, and maintains a globally unified and consistent master-slave state view.
[0050] Step S106: When the arbitration cluster determines that the switching conditions are met, a closed-loop switching process with multiple rounds of interaction is triggered: The arbitration cluster initiates a pre-switching request to the target new master node and the switcher of the current master node through the relevant switching agent; After receiving the request, each switcher performs a self-check of local resources, business status, and data synchronization integrity, and feeds back the self-check result ("Ready" or "Reject Switching") to the arbitration cluster through the switching agent; After collecting all feedback, if the arbitration cluster confirms that the switching is safe, it issues an "Execute Switching" command to the relevant switcher through the switching agent; After each switcher performs the switching operation, it replies with confirmation information to the arbitration cluster through the switching agent. The switching decision of the arbitration cluster includes the statically configured node priority and dynamic adjustment factor. The dynamic adjustment factor is calculated by comprehensively considering the node's real-time health score, network latency, CPU / memory resource availability, and data synchronization latency, realizing intelligent switching selection based on the system's real-time combat readiness status.
[0051] The multi-round closed-loop switching process specifically includes:
[0052] Pre-switch phase: The arbitration cluster sends a pre-switch request to the standby node that is pre-selected as the new master and the switcher of the current master node through the switching agent;
[0053] Inspection and feedback phase: After receiving the request, each switch immediately checks the local resource availability, whether the business service can be started and stopped, and whether the required data files have been synchronized. It then replies to the arbitration cluster with "ACK" (ready) or "NACK" (reject switch with reason) through the switch agent.
[0054] Arbitration and Command Phase: The arbitration cluster waits for a preset timeout to collect feedback; if all necessary nodes reply with "ACK", the cluster reaches a consensus and issues an "execute switch" command; if any node replies with "NACK" or fails to reply within the timeout period, the switch is terminated and an alarm is generated.
[0055] Execution and confirmation phase: After receiving the "Execute Switch" instruction, the switcher executes the predefined switch script (including permission transfer, service start and stop, configuration update, and file locking operations). After completion, it sends a "Switch Complete" confirmation message to the arbitration cluster through the switch agent.
[0056] State synchronization and publication phase: After the arbitration cluster confirms the successful switch of the new master node, it updates the global state view and publishes it downwards through the switch agent-switcher chain path; applications on each business node obtain the latest state by periodically querying the state interface or file provided by the local switcher.
[0057] Step S107: After the switchover is completed, the arbitration cluster sends the final primary / standby status view to all switchover agents, which then distribute it to their respective connected switches. The switchover provides the received final status to the SCADA, AGC, and other upper-layer business applications that require mutually exclusive access by providing standardized service interfaces and / or updating local shared status files (E files). Each application actively obtains and adapts to the current primary / standby status by periodically querying the interface or file, thereby decoupling business functions from the high-availability switchover mechanism.
[0058] The primary / standby state switching system for heterogeneous systems in a primary-multiple-standby mode, as described in this invention, consists of three layers:
[0059] Distributed arbitration cluster: As the "brain", it consists of three (or more odd number) servers, which make the final decision based on consensus algorithms such as Raft, ensuring state consistency and eliminating split-brain.
[0060] Switching Agent: Deployed on the network agent node, it acts as a bridge between the upper and lower layers, responsible for communicating with the switchers on the arbitration cluster and business nodes, and aggregating and forwarding status and instructions.
[0061] Switcher: Deployed on each business node, it is responsible for collecting the node's health status (CPU, memory, processes, network) and business status, and providing the final primary / standby status to the upper-layer application in the form of a service API or local file. The application queries this interface periodically to autonomously determine its behavior, thereby achieving complete decoupling from the core switching logic.
[0062] The key steps of the method are as follows:
[0063] Status collection and reporting: The switch of each business node collects the local status at regular intervals and sends it to the switching agent, which then aggregates the data and reports it to the arbitration cluster.
[0064] Global state decision-making: The arbitration cluster maintains a global view based on all information through a consensus algorithm.
[0065] Multi-round closed-loop switching: When a switch is required, the arbitration cluster initiates a pre-switching request; the relevant switches perform local checks and provide feedback; the arbitration cluster makes a decision based on all feedback; and only issues an execution command after confirming safety; the switches execute the operation and confirm.
[0066] State publishing and application adaptation: The final state is distributed to all switches via a proxy chain. Applications no longer passively receive notifications, but actively and periodically query the state from the interfaces or files provided by the local switch, thereby achieving seamless and decoupled linkage.
[0067] The core architecture of this system consists of three layers: the top layer is a distributed arbitration cluster, which consists of three arbitration nodes and acts as the brain of the system to make the final decision; the middle layer is a cross-system agent node, with a switching agent deployed on each node, which acts as a communication hub; the bottom layer consists of various business systems (primary system A, backup system C, and backup system B), with a switcher deployed on each system and interacting with upper-layer applications (such as AGC and AVC switches).
[0068] Example 1: SCADA system "one primary and two backup" failover scenario
[0069] A certain local dispatching system adopts a heterogeneous environment consisting of a primary dispatching system A (manufacturer 1, version 1, in primary use), a backup dispatching system B (manufacturer 1, version 2, in standby status), and a backup dispatching system C (manufacturer B, in standby status).
[0070] (1) Deployment and configuration phase:
[0071] An arbitration cluster was deployed on three different physical servers within the data center to form a decision-making center.
[0072] (11) Deploy lightweight switchers on the business servers of the main dispatch system A, the backup dispatch system B and the backup dispatch system C respectively;
[0073] (12) Deploy cross-system proxy nodes on network nodes that can connect to all business systems, and deploy switching agents on them;
[0074] (13) Configure the following through the management interface: IP address of each node in the arbitration cluster, node priority (system A>system B>system C), heartbeat collection period T1=1 second, status reporting period T2=3 seconds, and switchover timeout time=5 seconds.
[0075] (2) Normal operation phase:
[0076] (21) The switch on system A collects the CPU utilization, memory usage, and SCADA service process status of the local node once per second, and obtains the service status.
[0077] (22) The switch encapsulates these status data into heartbeat packets and immediately sends them to the switch agent on the cross-system agent node;
[0078] (23) The agent switches to package all the aggregated state information every 3 seconds and reports it to the arbitration cluster;
[0079] (24) The arbitration cluster maintains a global state view based on the state information of all nodes through a consensus algorithm, and confirms that: System A (primary), System B (backup), and System C (backup);
[0080] (25) The SCADA application on system A periodically queries the interface provided by the local switcher to know that it is in the primary state.
[0081] (3) Switching between triggering and execution phases:
[0082] A simulated system A failure occurs, and the arbitration cluster fails to receive system A's heartbeat information for 5 seconds.
[0083] (31) The arbitration cluster triggers the switching decision process and selects system B as the target new master based on static priority and dynamic health assessment.
[0084] (32) Pre-switch request: The arbitration cluster sends a pre-switch request to the switches of system B and system A through the cross-system agent node;
[0085] (33) Inspection and Feedback: After receiving the request, the switch of System B immediately performs a local self-check: checking whether resources are sufficient, the operation of services such as SCADA, and whether data files are synchronized. After passing the self-check, it replies "Ready" to the arbitration cluster through the switch agent;
[0086] (34) Arbitration and Instruction: The arbitration cluster receives "ready" feedback from system B within the timeout period (system A has lost contact and has no feedback), reaches a consensus, and issues "execute switch" instruction.
[0087] (35) Execution and Confirmation: After receiving the instruction, the switch of System B executes the predefined switching script: starts the local SCADA service, updates the configuration file, and creates the lock file. After completion, it sends a "switching complete" response to the arbitration cluster through the switching agent;
[0088] (36) Status synchronization: After the arbitration cluster confirms that the system B switch is successful, it updates the global status view to: system B (primary), system C (standby), system A (failed), and synchronizes it downward through the cross-system agent node-switcher chain path;
[0089] (37) In the next query cycle, the SCADA application on system B learns from the local switcher interface that it has become the primary state and immediately takes over all business functions.
[0090] Example 2: Emergency Manual Switching Scenario
[0091] Emergency response procedures:
[0092] (1) Operation and maintenance personnel log in to the arbitration cluster management system through the management interface;
[0093] (2) Select the "Force Switch" function and specify the target new host system (such as system C);
[0094] (3) You can select the "Ignore Check" mode to skip the pre-switching check stage;
[0095] (4) The arbitration cluster directly issues a switching command to the switcher of system C through the switching agent;
[0096] (5) The switcher of system C executes a simplified switching script to quickly take over the business.
[0097] All operations are recorded in detail in the audit log for later traceability.
[0098] This invention is not only applicable to conventional automatic switching scenarios, but also effectively handles emergency manual switching needs. Furthermore, it provides targeted mutual exclusion mechanisms for different types of applications (SCADA, AGC), demonstrating the completeness and practicality of the solution. By introducing distributed arbitration, dynamic prioritization, and lightweight proxy mechanisms, this invention achieves highly reliable and intelligent master-slave status management for heterogeneous systems, possessing strong practicality and promotional value.
Claims
1. A method for switching between primary and standby states in a heterogeneous system with one primary and multiple standby modes, characterized in that, include Construct a distributed arbitration cluster based on the Raft or Paxos consensus algorithm to adjudicate all primary and backup state transactions in the system; A distributed arbitration cluster consists of at least three independent servers; On each business node in the heterogeneous system that needs to participate in the primary / standby status determination, a switcher is deployed; on the agent node that is connected to the network of all business nodes, a switching agent is deployed; the switcher on the business node establishes a communication connection with the switching agent on the agent node, and the switching agent establishes a communication connection with the arbitration cluster. The switch on the service node periodically collects the health status, resource utilization, and network metrics of the node in the first cycle T1. It obtains service status data by reading a preset standard format status file. The switch encapsulates the above status data into a heartbeat packet and sends it to the switch agent it is connected to. The switching agent, in the second period T2, aggregates the heartbeat packets reported by all the service node switching agents it is connected to and forwards them to the arbitration cluster; The arbitration cluster uses a consensus algorithm to obtain a primary and backup status view based on the received status heartbeat packets, thus confirming the primary and backup systems. When the arbitration cluster determines that the switching conditions are met, it triggers a closed-loop switching process with multiple rounds of interaction: the arbitration cluster initiates a pre-switching request to the switchers of the target new master node and the current master node through the relevant switching agent; After receiving the request, each switch performs a self-check of local resources, business status, and data synchronization integrity, and feeds back the self-check results to the arbitration cluster through the switch agent; After collecting all feedback, if the arbitration cluster confirms that a safe switch is possible, it sends an "execute switch" command to the relevant switcher through the switch agent. After each switcher performs the switching operation, it sends a confirmation message to the arbitration cluster through the switching agent. After the switchover is complete, the arbitration cluster sends the final primary / standby status view to all switchover brokers, which then distribute it to their respective connected switchovers. The switcher will receive the final state and provide it to the SCADA, AGC and other upper-layer business applications that require mutually exclusive access to the node by providing a standardized service interface and / or updating the local shared state file. Each application can actively obtain and adapt to the current primary / standby state by periodically querying the interface or file, thereby decoupling business functions from the high-availability switching mechanism.
2. The method for switching primary / standby states in a heterogeneous system with one primary and multiple standby modes according to claim 1, characterized in that, The closed-loop switching process for multi-turn interactions is as follows: Pre-switch phase: The arbitration cluster sends a pre-switch request to the standby node that is pre-selected as the new master and the switcher of the current master node through the switching agent; Inspection and feedback phase: After receiving the request, each switcher checks the local resource availability, whether the business service can be started and stopped, and whether the required data files have been synchronized. It then replies to the arbitration cluster with "ready ACK" or "reject switch with reason NACK" through the switch agent. Arbitration and Command Phase: The arbitration cluster waits for a preset timeout to collect feedback; if all necessary nodes reply with "ACK", the cluster reaches a consensus and issues an "execute switch" command; if any node replies with "NACK" or fails to reply within the timeout period, the switch is terminated and an alarm is generated. Execution and confirmation phase: After receiving the "Execute Switch" instruction, the switcher executes the predefined switch script, and after completion, sends a "Switch Complete" confirmation message to the arbitration cluster through the switch agent; State synchronization and publication phase: After the arbitration cluster confirms the successful switch of the new master node, it updates the global state view and publishes it downwards through the switch agent-switcher chain path; applications on each business node obtain the latest state by periodically querying the state interface or file provided by the local switcher.
3. The method for switching primary / standby states in a heterogeneous system with one primary and multiple standby modes according to claim 1, characterized in that, The communication between the switcher and the switching agent, and between the switching agent and the arbitration cluster, all use standardized interfaces, including TCP Socket messages and reading and writing standard format files.
4. The method for switching primary / standby states in a heterogeneous system with one primary and multiple standby modes according to claim 1, characterized in that, The switching decision of the arbitration cluster is based on statically configured node priorities and dynamic adjustment factors. The dynamic adjustment factors are determined by the node's real-time health score, network latency, CPU / memory resource availability, and data synchronization latency.
5. A primary / standby state switching system for a heterogeneous system in a primary-multiple-standby mode, characterized in that, include A distributed arbitration cluster, consisting of at least three server nodes, serves as the decision-making center for heterogeneous systems. It receives state heartbeat packets, obtains the primary and backup state views through a consensus algorithm, and confirms the primary and backup systems. The switcher is located on each service node in the heterogeneous system that needs to participate in the primary / standby status determination. It is used to collect the health status, resource utilization, and network indicators of the node at regular intervals of the first period T1. It obtains service status data by reading a preset standard format status file. The switcher encapsulates the above status data into a heartbeat packet and sends it to the switcher agent it is connected to. A switching agent is deployed on an agent node that is connected to the network of all business nodes. It is used to aggregate the heartbeat packets reported by the switching agents of all business nodes connected to it in the second period T2 and forward them to the arbitration cluster. The management configuration module is used to configure arbitration policies, node priorities, heartbeat cycles, and timeout parameters. When the arbitration cluster determines that the switching conditions are met, it triggers a closed-loop switching process with multiple rounds of interaction: the arbitration cluster initiates a pre-switching request to the switchers of the target new master node and the current master node through the relevant switching agent; After receiving the request, each switch performs a self-check of local resources, business status, and data synchronization integrity, and feeds back the self-check results to the arbitration cluster through the switch agent; After collecting all feedback, if the arbitration cluster confirms that a safe switch is possible, it sends an "execute switch" command to the relevant switcher through the switch agent. After each switcher performs the switching operation, it sends a confirmation message to the arbitration cluster through the switching agent. After the switchover is complete, the arbitration cluster sends the final primary / standby status view to all switchover brokers, which then distribute it to their respective connected switchovers. The switcher will receive the final state and provide it to the SCADA, AGC and other upper-layer business applications that require mutually exclusive access to the node by providing a standardized service interface and / or updating the local shared state file. Each application can actively obtain and adapt to the current primary / standby state by periodically querying the interface or file, thereby decoupling business functions from the high-availability switching mechanism.
6. The primary / standby state switching system for a heterogeneous system in a primary-multiple-standby mode according to claim 5, characterized in that, In the management configuration module, the closed-loop switching process for multi-round interactions is as follows: Pre-switch phase: The arbitration cluster sends a pre-switch request to the standby node that is pre-selected as the new master and the switcher of the current master node through the switching agent; Inspection and feedback phase: After receiving the request, each switcher checks the local resource availability, whether the business service can be started and stopped, and whether the required data files have been synchronized. It then replies to the arbitration cluster with "ready ACK" or "reject switch with reason NACK" through the switch agent. Arbitration and Command Phase: The arbitration cluster waits for a preset timeout to collect feedback; if all necessary nodes reply with "ACK", the cluster reaches a consensus and issues an "execute switch" command; if any node replies with "NACK" or fails to reply within the timeout period, the switch is terminated and an alarm is generated. Execution and confirmation phase: After receiving the "Execute Switch" instruction, the switcher executes the predefined switch script, and after completion, sends a "Switch Complete" confirmation message to the arbitration cluster through the switch agent; State synchronization and publication phase: After the arbitration cluster confirms the successful switch of the new master node, it updates the global state view and publishes it downwards through the switch agent-switcher chain path; applications on each business node obtain the latest state by periodically querying the state interface or file provided by the local switcher.
7. The primary / standby state switching system for a heterogeneous system in a primary-multiple-standby mode according to claim 5, characterized in that, Communication between the switcher and the switch agent, and between the switch agent and the arbitration cluster, uses standardized interfaces, including TCP Socket messages and reading and writing standard format files.
8. The primary / standby state switching system for a heterogeneous system in a primary-multiple-standby mode according to claim 5, characterized in that, The decision-making criteria for switching the arbitration cluster include statically configured node priorities and dynamic adjustment factors. The dynamic adjustment factors are determined by the node's real-time health score, network latency, CPU / memory resource availability, and data synchronization latency.
9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.
Citation Information
Patent Citations
Hot backup method of VTS multi-sensor information comprehensive processing system
CN109639512A
Data storage method and device
CN116594551A