Switching method and device of distributed disaster recovery system and electronic equipment

Abstract

The invention discloses a switching method and device of a distributed disaster recovery system and electronic equipment, and relates to the technical field of distribution.The distributed disaster recovery system at least comprises a main cluster and a standby cluster, the main cluster and the standby cluster adopt an asynchronous replication mechanism, and the method comprises the steps that node information of L nodes included in the main cluster is collected through a monitoring module, the node information of the L nodes is transmitted to a control module to be analyzed, and the node state of each node is obtained; under the condition that the node state of the service node is an abnormal state, detecting the number of continuous abnormities of the IP address corresponding to the service node; and updating the service node as a main node in the standby cluster and generating a first signal under the condition that the number of continuous exceptions is greater than a preset number and the nodes in the same region corresponding to the service node are in an abnormal state. The technical problem that in the prior art, a disaster recovery system adopting a one-host and two-backup architecture is high in data loss risk during host and backup switching is solved.

Description

Technical Field

[0001] This application relates to the field of distributed technology, and more specifically, to a switching method, apparatus, and electronic device for a distributed disaster recovery system. Background Technology

[0002] With the rapid development of information technology, enterprises are increasingly demanding higher standards for data security and business continuity. In the current context of digital transformation, databases have become the core of critical infrastructure. To address the unavailability of data centers due to sudden hardware failures, network outages, or natural disasters, most enterprises currently adopt a primary-secondary disaster recovery system architecture. However, in scenarios where disaster recovery systems are deployed across geographical regions, this architecture exposes a high risk of data loss during primary-secondary failover.

[0003] In existing technologies, most disaster recovery systems are based on a primary-secondary architecture, where the primary database and two backup databases are deployed in different geographical locations to achieve high availability through geographical isolation. When the primary database fails, the system attempts to automatically switch to the backup databases to continue providing services. This switching mechanism is effective in local data centers or short-distance deployments. However, in long-distance disaster recovery scenarios across regions, data consistency during primary-backup switching is difficult to guarantee due to data synchronization latency and network uncertainty. Especially in extreme cases, such as natural disasters, the risk of data loss increases significantly, impacting business continuity and user experience.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a switching method, apparatus, and electronic device for a distributed disaster recovery system, which at least solves the technical problem of high data loss risk during primary-backup switching in existing disaster recovery systems with a primary-secondary architecture.

[0006] According to one aspect of this application, a distributed disaster recovery system is provided, comprising: a primary cluster and a backup cluster, wherein the primary cluster and the backup cluster adopt an asynchronous replication mechanism, the primary cluster includes L nodes distributed in a first region and a second region, and the backup cluster includes M nodes distributed in the second region, where L and M are both positive integers.

[0007] According to one aspect of this application, a switching method for a distributed disaster recovery system is provided, comprising: collecting node information of L nodes in a primary cluster through a monitoring module, and transmitting the node information of the L nodes to a control module for analysis to obtain the node status of each node; detecting the consecutive abnormal number of times the IP address corresponding to the service node is abnormal when the node status of the service node is abnormal; updating the service node to the primary node in the backup cluster and generating a first signal when the consecutive abnormal number of times is greater than a preset number and all nodes in the same region corresponding to the service node are in abnormal status, wherein the nodes in the same region are nodes in the same region as the service node among the L nodes, and the first signal is used to prompt the domain name server to update the domain name.

[0008] Optionally, the step of transmitting the node information of L nodes to the control module for analysis to obtain the node status of each node includes: if the node information received by the control module does not include the IP address of the i-th node, determining that the node status of the i-th node is disconnected, where the i-th node is one of the L nodes; if the node information received by the control module includes the IP address of the i-th node and abnormal response information, determining that the node status of the i-th node is abnormal, where the abnormal response information includes at least network timeout information and node authentication failure information; if the node information received by the control module includes the IP address of the i-th node and role identifier, determining that the node status of the i-th node is normal, where the role identifier is the primary node identifier or the backup node identifier.

[0009] Optionally, after obtaining the node status of the service node, the switching method of the distributed disaster recovery system further includes: if the node status of the service node is normal, processing client requests from user devices through the service node and obtaining the number of consecutive anomalies; if the number of consecutive anomalies is greater than 0, clearing the number of consecutive anomalies for the IP address corresponding to the service node to zero and initializing the monitoring period corresponding to the service node; if the number of consecutive anomalies is less than or equal to 0 / after initializing the monitoring period corresponding to the service node, monitoring the update status of the master node in the master cluster.

[0010] Optionally, after obtaining the node status of the service node, the switching method of the distributed disaster recovery system further includes: generating a second signal when the number of consecutive anomalies exceeds a preset number and not all nodes in the same region corresponding to the service node are in an abnormal state, wherein the second signal is used to prompt the operation and maintenance personnel to check the service node in the abnormal state.

[0011] Optionally, after detecting the number of consecutive anomalies of the IP address corresponding to the service node, the switching method of the distributed disaster recovery system further includes: if the number of consecutive anomalies is less than or equal to a preset number, updating the monitoring period of the service node in the monitoring module based on a preset multiple, and controlling the monitoring module to re-collect the node information of the service node based on the updated monitoring period.

[0012] Optionally, the step of monitoring the update status of the master nodes in the master cluster includes: generating a first signal when there is an update to the master nodes in the master cluster; and controlling the control module to analyze the new node information collected by the monitoring module when there is no update to the master nodes in the master cluster.

[0013] Optionally, after transmitting the node information of L nodes to the control module for analysis to obtain the node status of each node, the switching method of the distributed disaster recovery system further includes: when the node status of the service node is abnormal, obtaining the number of abnormal nodes in the main cluster, wherein the number of abnormal nodes is the total number of nodes in the main cluster whose node status is abnormal; when the number of abnormal nodes is less than or equal to a preset number, updating the master node of the main cluster based on the normal nodes in the cluster, wherein normal nodes are nodes whose node status is normal; when the number of abnormal nodes is greater than the preset number, updating the master node of the main cluster based on the normal nodes and the management node in the cluster.

[0014] According to another aspect of this application, a switching device for a distributed disaster recovery system is also provided, comprising: a first analysis unit, configured to collect node information of L nodes in the main cluster through a monitoring module, and transmit the node information of the L nodes to a control module for analysis to obtain the node status of each node; a first detection unit, configured to detect the number of consecutive abnormal IP addresses corresponding to the service node when the node status of the service node is abnormal; and a first update unit, configured to update the service node to the master node in the backup cluster and generate a first signal when the number of consecutive abnormalities exceeds a preset number and all nodes in the same region corresponding to the service node are in an abnormal state, wherein the nodes in the same region are nodes in the same region as the service node among the L nodes, and the first signal is used to prompt the domain name server to update the domain name.

[0015] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein, when the computer program is running, the switching method of the distributed disaster recovery system that controls the computer program product to execute any of the above-mentioned methods is provided.

[0016] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the switching method of the distributed disaster recovery system described above.

[0017] In this application, a distributed disaster recovery system is adopted, which includes a primary cluster and a backup cluster. The primary and backup clusters adopt an asynchronous replication mechanism. The primary cluster includes L nodes distributed in a first region and a second region, and the backup cluster includes M nodes distributed in the second region, where L and M are both positive integers. During the switching process of the distributed disaster recovery system, this application first collects the node information of the L nodes in the primary cluster through a monitoring module and transmits the node information of the L nodes to a control module for analysis to obtain the node status of each node. Then, if the node status of the service node is abnormal, this application detects the number of consecutive abnormal IP addresses corresponding to the service node. Then, if the number of consecutive abnormal IP addresses exceeds a preset number and all nodes in the same region corresponding to the service node are in an abnormal state, this application updates the service node to the primary node in the backup cluster and generates a first signal. The nodes in the same region are the nodes in the same region as the service node among the L nodes. The first signal is used to prompt the domain name server to update the domain name.

[0018] As can be seen from the above, this application adopts a real-time monitoring and intelligent switching approach. By integrating network status monitoring and control logic, it achieves the goal of quickly identifying and responding to anomalies in the main cluster nodes, thereby reducing the risk of data loss while ensuring service continuity.

[0019] Specifically, this application collects node information from L nodes in the main cluster through a monitoring module, and the control module analyzes the collected node information. Once it detects that a service node is currently in an abnormal state, the number of consecutive abnormal occurrences of a service node exceeds a preset number, and all nodes in the same region corresponding to the service node are abnormal, the disaster recovery switchover process is immediately initiated to switch the service node to the main node in the backup cluster. In other words, the service node role is switched to the main node in the backup cluster. A first signal is generated to notify the domain name server to update, and client traffic is guided to transmit to healthy nodes. This achieves the technical effect of improving data security and service reliability during the disaster recovery switchover process, thereby solving the technical problem of high data loss risk during the switchover of existing disaster recovery systems with a one-main-two-backup architecture. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is an architecture diagram of a disaster recovery system with an optional primary and two backup design pattern;

[0022] Figure 2 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a switching method of a distributed disaster recovery system according to an embodiment of this application.

[0023] Figure 3 This is an architecture diagram of an optional distributed disaster recovery system according to an embodiment of this application;

[0024] Figure 4 This is a flowchart of an optional switching method for a distributed disaster recovery system according to an embodiment of this application;

[0025] Figure 5 This is an architecture diagram of a distributed disaster recovery cluster with an optional two-site four-center architecture deployment according to an embodiment of this application;

[0026] Figure 6 This is a flowchart of an optional network status monitoring module according to an embodiment of this application;

[0027] Figure 7 This is a flowchart of an optional control module according to an embodiment of this application;

[0028] Figure 8 This is a flowchart of an optional reminder module according to an embodiment of this application;

[0029] Figure 9 This is a schematic diagram of a switching device for an optional distributed disaster recovery system according to an embodiment of this application;

[0030] Figure 10 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] It should also be noted that all information (including but not limited to cluster node information collected and analyzed) and data (including but not limited to data used for display and analysis) involved in this application are information and data authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining the relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information only after receiving consent from the aforementioned user or organization.

[0034] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken. This application does not violate public order and good morals. In addition, this application provides a corresponding operation entry point for users to choose to agree to or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.

[0035] In one alternative embodiment, Figure 1 This is an architecture diagram of a disaster recovery system with an optional primary and two backup design pattern, such as... Figure 1 As shown, Figure 1 The disaster recovery database adopts a one-master-two-standby architecture. One master database (the DB master database corresponding to IP1) and one standby database (the DB standby database corresponding to IP2) are deployed in City A, and the other standby database (the DB standby database corresponding to IP3) is deployed in City B. The disaster recovery system also includes a smart DNS (Domain Name System). The application container can obtain the IP address (i.e., IP1) of the database to be accessed from the domain name system through "domain A". The master database and the two corresponding standby databases use the Binlog (Binary Log) mechanism for full / incremental synchronization.

[0036] However, the primary-secondary architecture cannot achieve strong consistency across regions, and there is a risk of data loss when switching between primary and secondary databases. In some cases, network anomaly detection delays can cause the Recovery Time Objective (RTO) to reach the hour level, i.e., the Recovery Point Objective (RPO) > 0.

[0037] Furthermore, based on the Binlog asynchronous data replication mechanism, transaction commit and log transmission are decoupled; in the event of a master node failure, there is a situation where a failover is triggered before the transaction persistence status of the slave node is confirmed.

[0038] Optionally, examples of the technical shortcomings of the disaster recovery system with the above primary and secondary backup design in different application scenarios are as follows:

[0039] (1) Active request scenario:

[0040] Phenomenon: TCP (Transmission Control Protocol layer) exponential backoff retry strategy (e.g., 15-minute timeout retry);

[0041] Principle flaw: The application layer does not implement a circuit breaker mechanism and relies on the reliability guarantee of the transport layer;

[0042] Typical impact: Inconsistent order status for payment-related transactions.

[0043] (2) Idle connection scenario:

[0044] Phenomenon: The kernel TCP Keepalive (a default keepalive mechanism) has a 2-hour probe interval by default;

[0045] Protocol limitations: It does not incorporate application-layer heartbeats to shorten the detection cycle;

[0046] Typical impact: Database long-lived connection pool deadlock leads to transaction blocking.

[0047] Based on the technical deficiencies that need to be addressed in the above embodiments, this application proposes a disaster recovery system based on a distributed consensus protocol. Through real-time incremental log synchronization and multi-replica verification mechanism, it achieves cross-regional strong consistency guarantee with RPO=0 (zero data loss). At the same time, the disaster recovery system is equipped with a network topology awareness system, which can trigger intelligent routing switching to ensure that application traffic is automatically redirected to healthy and available servers.

[0048] According to an embodiment of this application, a switching method embodiment for a distributed disaster recovery system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0049] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 2 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a switching method of a distributed disaster recovery system according to an embodiment of this application. Figure 2 As shown, the computer terminal 20 (or mobile device) may include one or more processors 202 (shown as 202a, 202b, ..., 202n in the figure) 202 (processor 202 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 204 for storing data, and a transmission device 206 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 2 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 20 may also include... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown.

[0050] Optionally, it should be noted that the aforementioned one or more processors 202 and / or other data processing circuits may generally be referred to herein as "data processing circuitry". This data processing circuitry may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be wholly or partially integrated into any other element within the computer terminal 20 (or mobile device). As involved in the embodiments of this application, the data processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0051] Optionally, the memory 204 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the switching method of the distributed disaster recovery system in this embodiment. The processor 202 executes various functional applications and data processing by running the software programs and modules stored in the memory 204, thereby realizing the aforementioned switching method of the distributed disaster recovery system. The memory 204 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 204 may further include memory remotely located relative to the processor 202, and these remote memories can be connected to the computer terminal 20 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0052] Optionally, the transmission device 206 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 20. In one example, the transmission device 206 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 206 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0053] Alternatively, the display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 20 (or mobile device).

[0054] Optionally, under the above operating environment, this application provides a distributed disaster recovery system for executing the switching method of the distributed disaster recovery system in this application. Figure 3 This is an architecture diagram of an optional distributed disaster recovery system according to an embodiment of this application, such as... Figure 3 As shown, a distributed disaster recovery system includes at least a network status monitoring module, an alert module, a control module, a DNS system, user equipment, DB Instances Primary (primary cluster), and DB Instances Second (secondary cluster).

[0055] Optionally, the network status monitoring module is used to detect the network status of the primary cluster and the backup cluster in real time; the control module is used to obtain real-time data from the network status monitoring module and determine whether the current cluster network is abnormal according to the set logic. If the user device disconnects from the cluster network, it notifies the reminder module to switch; the reminder module is used to update the domain name server and remind the user to switch the cluster server; and the DNS is used to ensure that the domain name is always bound to the normal cluster server.

[0056] Optionally, after the user device / application receives the notification from the alert module, it first obtains a working IP address from the DNS, closes the old connection, connects to the new IP address (the leader's IP address), and sends the user request to the working cluster server.

[0057] Optionally, when the distributed disaster recovery system is in normal operation, the Leader node in "DB Instances Primary" executes the requests of user devices / applications and returns the execution results.

[0058] Optionally, when the distributed disaster recovery system is in an abnormal operating state, the Leader node in "DB Instances Second" executes the requests of user devices / applications and returns the execution results.

[0059] Optionally, the Leader in "DB Instances Primary" and "DB Instances Second" is maintained by the nodes in both clusters via the Paxos protocol.

[0060] Optionally, Figure 4 This is a flowchart of an optional distributed disaster recovery system switching method according to an embodiment of this application, such as... Figure 4 As shown, the method includes the following steps:

[0061] Step S401: The monitoring module collects the node information of the L nodes in the main cluster and transmits the node information of the L nodes to the control module for analysis to obtain the node status of each node.

[0062] Optionally, Figure 5 This is an architecture diagram of a distributed disaster recovery cluster deployed in an optional two-site, four-center architecture according to an embodiment of this application, such as... Figure 5As shown, both the primary and backup clusters in the distributed system adopt a two-site, four-center deployment configuration. That is, each cluster is distributed across two locations: City A (i.e., the first region) and City B (i.e., the second region). The primary and backup clusters together include four data centers (i.e., data centers 1-4). The primary cluster has 5 data replicas (i.e., L nodes), and the backup cluster has 4 data replicas (i.e., M nodes).

[0063] Optionally, the backup cluster may not deploy data replicas in City A to avoid doubling the cross-regional traffic transmission.

[0064] Optionally, when one backup node fails, the distributed disaster recovery system uses the internal Paxos majority mechanism to elect a leader; when more than one node fails in the disaster recovery cluster, the distributed disaster recovery system uses the management node to assist in the election; in the event of a data center-level failure, the management node also needs to elect a leader node through Paxos.

[0065] Optionally, a data replica is deployed in City B to deal with a central failure of the primary cluster.

[0066] Optionally, the primary cluster is the core cluster accessed by applications during normal operation of the distributed disaster recovery system. Its replicas achieve data synchronization, failover, and node election through the Paxos protocol to ensure high reliability and high availability of the system. The specific responsibilities of the primary cluster are as follows:

[0067] (1) Leader node: responsible for handling client requests (such as read and write operations) and coordinating the cluster state.

[0068] (2) Follower node:

[0069] 1) Synchronize Leader data in real time and perform backup function;

[0070] 2) When the Leader node fails, it will be promoted to a new Leader through the Paxos protocol's automatic election mechanism, ensuring service continuity.

[0071] Optionally, the backup cluster is used as a standby cluster when the primary cluster fails. Its working principle is the same as that of the primary cluster, and the specific responsibilities of the backup cluster are as follows:

[0072] (1) Leader node: responsible for receiving synchronization data from the main cluster;

[0073] (2) Follower node: has the same function as the Follower node in the main cluster;

[0074] Optionally, an asynchronous replication mechanism can be used between any two nodes in different locations.

[0075] Optionally, the monitoring module is as described above. Figure 3 The network status monitoring module is used to monitor the operational information of each component in the distributed disaster recovery system in real time, including but not limited to the health status and network connection status of nodes in the master / standby cluster.

[0076] Optionally, Figure 6 This is a flowchart of an optional network status monitoring module according to an embodiment of this application, as follows: Figure 6 As shown, the workflow of this module is described below:

[0077] (1) The monitoring cycle is set to 1 second;

[0078] (2) The monitoring module periodically obtains information from each node in the cluster through a preset data interface. The information of each node includes, but is not limited to:

[0079] 1) The node's IP address;

[0080] 2) Node roles: leader, follower;

[0081] 3) Node network connection status: Normal, Abnormal, Unable to be obtained;

[0082] (3) Send various information to the control module for analysis;

[0083] (4) The network status monitoring module is designed in a stateless mode, which is convenient for deployment in the cloud environment.

[0084] Optionally, the primary cluster includes L nodes, which are the primary nodes and backup nodes in the production environment. It is responsible for handling client requests (i.e., requests from user devices / applications) when the system is running normally, ensuring that the data read and write operations corresponding to the client requests can be performed smoothly. The L nodes maintain data synchronization through a preset distributed consistency protocol (e.g., Paxos) or a preset data replication mechanism (e.g., DTS).

[0085] Optionally, the control module is responsible for receiving data from the monitoring module, applying business logic to determine the node status, and making disaster recovery decisions based on these statuses (such as failover and electing a new leader).

[0086] In step S401, through the collaborative work of the monitoring module and the control module, the distributed disaster recovery system can monitor the health status of the primary cluster / standby cluster in real time, quickly detect and respond to node failures. This monitoring mechanism improves the system's response speed and fault handling efficiency, ensuring that the distributed disaster recovery system can take measures quickly when a node fails, reducing service interruption time and thus improving business continuity and user experience.

[0087] Step S402: If the node status of the service node is abnormal, detect the number of consecutive abnormal IP addresses corresponding to the service node.

[0088] In step S402, the distributed disaster recovery system can effectively distinguish between temporary node network fluctuations and serious, persistent node failures by setting monitoring of the number of consecutive anomalies and preset thresholds. This mechanism avoids unnecessary service interruptions or switching caused by occasional problems, while ensuring that the distributed disaster recovery system can respond and switch in a timely manner when a serious cluster failure actually occurs, thereby reducing the risk of data loss and improving the overall stability and reliability of the disaster recovery system.

[0089] Step S403: If the number of consecutive anomalies exceeds the preset number and all nodes in the same region corresponding to the service node are in an abnormal state, update the service node to the master node in the backup cluster and generate a first signal. The nodes in the same region are nodes in the same region as the service node among L nodes. The first signal is used to prompt the domain name server to update the domain name.

[0090] Optionally, nodes in the same region can be other nodes in the main cluster that are located in the same geographical area as the service node.

[0091] Optionally, the first signal is generated by the control module to notify other components of the distributed disaster recovery system (such as DNS servers, application services, etc.) that the service nodes have been switched.

[0092] Optionally, the domain name server, or DNS server, can immediately update the association between the domain name and the service node IP address after receiving the first signal, thereby enabling automatic redirection of client requests.

[0093] Optionally, when the number of consecutive anomalies of a service node and nodes in the same region exceeds a preset value, the distributed disaster recovery system immediately initiates a disaster recovery switch, promoting a node in the backup cluster to a new service node, i.e., the new Leader. At the same time, it notifies the DNS server to update domain name resolution via the first signal, ensuring that clients can access healthy service nodes in a timely manner and avoid service interruption. This process ensures that when the primary cluster encounters a regional failure, the distributed disaster recovery system can quickly restore services, reduce data loss, thereby shortening the RTO (Recovery Time Objective) value and improving the system's disaster recovery capabilities and data security.

[0094] Optionally, Figure 7 This is a flowchart of an optional control module according to an embodiment of this application, such as... Figure 7 As shown, the workflow of this module is described below:

[0095] (1) The control module receives and analyzes the status information from the monitoring module:

[0096] 1) When the monitoring module successfully obtains node information, that is, the node information includes the IP address of the target node and its role identifier (Leader or Follower), the monitoring module determines the running status of the node based on the node information.

[0097] 2) When the monitoring module fails to obtain node information, that is, the node information only contains the IP address of the target node and the abnormal status identifier (such as network timeout, authentication failure, etc.), the monitoring module prompts that there is an abnormality in the node information.

[0098] (2) Check if there are any anomalies in the node information:

[0099] 1) If an anomaly is found, increment the anomaly count for the node corresponding to the IP address by 1:

[0100] After incrementing the anomaly count of the node corresponding to the IP address by 1, if the consecutive anomaly count of the node corresponding to the IP address is greater than 8 at this time, check the operating status of all nodes in City A.

[0101] If all nodes in City A are abnormal, the distributed disaster recovery system determines that the primary cluster has experienced a regional disaster, immediately starts the backup cluster, sets the service node as the leader node of the disaster recovery cluster, and notifies the alert module for further switching processing; otherwise, it determines that the node is abnormal and notifies the alert module for further processing.

[0102] If the number of consecutive abnormal occurrences of the node corresponding to the IP address is less than or equal to 8, the monitoring module will be set to double the monitoring period of the node corresponding to the IP address.

[0103] 2) If it does not contain any exceptions:

[0104] If the node corresponding to the IP address has previously experienced an anomaly, the distributed disaster recovery system will clear the anomaly count of the node corresponding to the IP address to 0, and set the monitoring module to restore the monitoring period for the node corresponding to the IP address to the initial value.

[0105] If the leader node changes, the notification module will display the IP address of the new leader.

[0106] 3) Wait for the next information from the monitoring module;

[0107] 4) In order to achieve active-active disaster recovery environment within the same city, and without increasing the cross-regional network bandwidth overhead caused by data transmission from disaster recovery environment to production environment by doubling the data transmission overhead, the distributed disaster recovery system deploys 4 data replicas in each region's dual campuses (i.e., data centers 1-4), with 2 data replicas deployed in each campus, thereby ensuring high availability within the campus and also ensuring high availability of disaster recovery within the same city.

[0108] Optionally, when one DN instance fails in the disaster recovery node, the distributed disaster recovery system uses internal Paxos majority voting to achieve election. When the entire campus is unavailable, since only two data replicas remain, the majority principle is no longer satisfied, and Paxos cannot be used for self-election. In this case, the management node can be used to assist the disaster recovery cluster in achieving election. After the management node joins, the disaster recovery environment has four data replicas and City A has one data replica, which satisfies the majority principle. This helps the DN layer achieve active-active capability within the same city, that is, electing a leader node from the remaining two replicas. This saves bidirectional network bandwidth across different locations and also achieves high availability of active-active capability within the same city.

[0109] Optionally, Figure 8 This is a flowchart of an optional reminder module according to an embodiment of this application, such as... Figure 8 As shown, after receiving a notification from the control module, the reminder module checks the message notification type. The workflow of this module is as follows:

[0110] (1) If a node is abnormal (distinguished by IP address), notify the operation and maintenance personnel via email to restore the node to normal status;

[0111] (2) If the service node changes:

[0112] 1) Update DNS to associate the domain name with the correct service node;

[0113] 2) Notify the application service node that it has changed and instruct it to obtain the correct service node address again.

[0114] Optionally, after the user device's application receives a notification that the service node has changed, the following actions are taken:

[0115] (1) Close the current connection and release system resources: Due to network abnormalities, the server will not execute the closing process, which will result in a long normal closing process time and affect service quality. Therefore, a forced closing process will be executed at this time, for example, by closing the connection through system calls or interface calls.

[0116] (2) Obtain a valid service node address from the DNS server;

[0117] (3) Connect to the service node and continue to execute the business request.

[0118] Optionally, the technical effects of the technical solution of this application are as follows:

[0119] (1) Through Paxos protocol, multi-site and multi-center deployment, and automatic switching mechanism, RPO=0 and RTO<60s are achieved;

[0120] (2) The primary and backup clusters operate independently, and a data center-level failure does not affect the other cluster;

[0121] (3) The control node and the cluster node work together to complete multi-level fault recovery, successfully saving double the network bandwidth cost of the remote server room;

[0122] (4) Introduce a network detection module to increase the sensitivity of network detection;

[0123] (5) Optimize the process of closing abnormal connections in applications to avoid problems such as long-term blocking of the application layer due to network reasons.

[0124] In one optional embodiment, if the node information received by the control module does not include the IP address of the i-th node, the distributed disaster recovery system determines that the node status of the i-th node is disconnected, wherein the i-th node is one of the L nodes; if the node information received by the control module includes the IP address of the i-th node and abnormal response information, the distributed disaster recovery system determines that the node status of the i-th node is abnormal, wherein the abnormal response information includes at least network timeout information and node authentication failure information; if the node information received by the control module includes the IP address of the i-th node and role identifier, the distributed disaster recovery system determines that the node status of the i-th node is normal, wherein the role identifier is either the primary node identifier or the backup node identifier.

[0125] Optionally, when the control module does not receive the node's IP address, the distributed disaster recovery system immediately determines that the node is disconnected and triggers the subsequent fault handling process, thereby shortening the fault detection time, speeding up the system recovery speed, and helping to shorten the time required to achieve the RTO value. Furthermore, the timely determination of the disconnected state can prevent the distributed disaster recovery system from continuing to send requests to the "invalid node", saving network resources and application layer processing time, and improving the overall operating efficiency of the system.

[0126] Optionally, network timeout information is used to characterize the failure of a node to respond to the control module's request within the expected time, which may be caused by network latency or node processing delay.

[0127] Optionally, node authentication failure information is used to indicate that the authentication process failed when the node attempted to communicate with the control module or other nodes, which may be caused by configuration errors, permission issues, or malicious attacks.

[0128] Optionally, by using abnormal response information, the distributed disaster recovery system can accurately determine the type of abnormality of a node, providing more specific information for subsequent fault handling, such as whether it is a network problem or an authentication problem, which helps to respond quickly and take targeted measures. Furthermore, by judging abnormal response information, such as network timeout and authentication failure, the distributed disaster recovery system reduces the uncertainty of status judgment, avoids system misoperation caused by a single fault indicator, and improves the stability and reliability of the system.

[0129] Optionally, role identification refers to the identity of a node in its cluster, distinguishing it as a leader (master node) or a follower (slave node).

[0130] Optionally, the control module ensures that the judgment of the node status is consistent with the actual role by using the role identifier in the node information, avoiding confusion of status information and ensuring the consistency and correctness of the system. Furthermore, by clearly distinguishing the status of the primary node and the backup node, the distributed disaster recovery system can quickly identify the current business primary node, ensuring that traffic can be intelligently redirected to the normally operating backup node during failover, thereby ensuring service continuity and user experience.

[0131] In summary, the above embodiments can achieve the following technical effects:

[0132] (1) Fast response: shorten fault detection time and speed up system recovery.

[0133] (2) Fault location and handling: By identifying abnormal response information, the cause of the fault can be located more accurately and targeted handling can be carried out.

[0134] (3) Service continuity and resource optimization: Ensure that traffic can be automatically redirected to available nodes when a failure occurs, while reducing the monitoring burden of normal nodes and improving system stability and resource utilization efficiency.

[0135] (4) Enhanced security and reliability: The node status is confirmed by role identification, which avoids confusion of status information and improves the security and reliability of the system.

[0136] (5) Avoid invalid operations: timely confirmation of disconnection or abnormal status avoids the system sending requests to faulty nodes, reducing invalid operations and resource waste.

[0137] In one optional embodiment, after obtaining the node status of the service node, if the node status of the service node is normal, the distributed disaster recovery system processes client requests from user devices through the service node and obtains the number of consecutive anomalies; if the number of consecutive anomalies is greater than 0, the distributed disaster recovery system clears the number of consecutive anomalies for the IP address corresponding to the service node to zero and initializes the monitoring period corresponding to the service node; if the number of consecutive anomalies is less than or equal to 0 / after initializing the monitoring period corresponding to the service node, the distributed disaster recovery system monitors the update status of the master node in the main cluster.

[0138] Optionally, when the service node is in normal condition, the distributed disaster recovery system can monitor the health status of the service node in real time by processing client requests through the service node and continuously monitoring the number of consecutive anomalies. This mechanism ensures that the operations performed on the service node can proceed normally, and at the same time provides an early warning mechanism for possible subsequent failures. By continuously monitoring the number of anomalies, potential unstable states can be detected early, avoiding sudden service interruptions without the user's awareness, thus improving the stability of the system and the user experience.

[0139] Optionally, when the number of consecutive anomalies is greater than 0, it indicates that the service node had an anomaly in the previous one or more monitoring periods, but has now returned to normal.

[0140] Optionally, after the service node status returns to normal, the distributed disaster recovery system resets its consecutive anomaly count to 0 and restores to the initial monitoring cycle, ensuring that the monitoring mechanism does not continuously impose additional resource consumption or monitoring pressure on the recovered node.

[0141] Optionally, by resetting the consecutive anomaly count to zero and initializing the monitoring cycle after a service node recovers from an abnormal state, the distributed disaster recovery system avoids excessively frequent health checks on recovered nodes, thereby saving system resources, reducing network overhead during monitoring, and maintaining efficient system operation. This mechanism can dynamically adjust monitoring strategies, ensuring rapid response to potential faults while avoiding unnecessary resource waste and improving overall resource utilization efficiency.

[0142] In summary, the above embodiments can achieve the following technical effects:

[0143] By continuously monitoring the update status of the master nodes in the main cluster, the distributed disaster recovery system can ensure that it can respond immediately during master node switching and update service node information in a timely manner, avoiding service interruption or data loss. This mechanism is crucial for maintaining data consistency and service continuity, especially in disaster recovery switching scenarios. It can quickly identify and adapt to the new leader node, ensuring that client requests are processed correctly, thus enhancing the overall disaster recovery capability and user experience of the system. In particular, the master node status monitoring performed after the initial monitoring cycle is also a preventive measure, which helps to detect possible faults or status changes in advance, providing a solid guarantee for the high availability of the system.

[0144] In one optional embodiment, if the number of consecutive anomalies exceeds a preset number, and not all nodes in the same region corresponding to the service node are in an abnormal state, the distributed disaster recovery system generates a second signal, wherein the second signal is used to prompt the operation and maintenance personnel to check the service nodes in an abnormal state.

[0145] Optionally, the second signal, which is a signal generated by the control module when the number of consecutive abnormal occurrences of a service node reaches a preset threshold and not all nodes in the same region are abnormal, is used to directly notify the operation and maintenance personnel to pay attention to and check the service nodes in the abnormal state, so as to determine the specific cause of the fault and take corresponding repair measures.

[0146] Optionally, when the number of consecutive anomalies of a service node exceeds a preset threshold, but there are still healthy nodes in the same region, the distributed disaster recovery system directly notifies the operation and maintenance personnel to intervene and check by generating a second signal. This processing mechanism has the following functions:

[0147] (1) Precise fault location: Through the second signal, maintenance personnel can quickly locate the specific service node that is abnormal, avoiding blind troubleshooting and improving the efficiency and accuracy of fault location.

[0148] (2) Reduce system-level switching: With healthy nodes still available in the same region, unnecessary system-level disaster recovery switching is avoided, reducing the overhead of cross-regional data transmission and reducing the risk of business interruption caused by switching.

[0149] (3) Timely repair and recovery of services: After receiving the second signal, the operation and maintenance personnel can immediately check and repair the abnormal service nodes, which helps to quickly restore the normal operation of the nodes, shorten the RTO, and ensure business continuity.

[0150] (4) Efficient use of resources: It avoids uniform high-frequency monitoring of the entire cluster or all nodes in the same region, and only focuses on service nodes with known abnormalities, saving monitoring resources and improving operation and maintenance efficiency.

[0151] In summary, the above embodiments can achieve the following technical effects:

[0152] The distributed disaster recovery system sends a second signal when a service node experiences consecutive anomalies, but not all nodes in the same region are abnormal. This enables rapid response and accurate fault location, avoids excessive resource consumption and unnecessary system-level switching, and thus improves the stability and operational efficiency of the distributed disaster recovery system, providing strong technical support for maintaining business continuity and data security.

[0153] In one optional embodiment, after detecting the number of consecutive anomalies of the IP address corresponding to the service node, if the number of consecutive anomalies is less than or equal to a preset number, the distributed disaster recovery system updates the monitoring period of the service node in the monitoring module based on a preset multiple, and controls the monitoring module to re-collect the node information of the service node based on the updated monitoring period.

[0154] Optionally, a preset multiplier, i.e., a proportional factor for adjusting the monitoring cycle of service nodes, is dynamically set based on the historical performance and current status of the service nodes, with a priority of 2 times.

[0155] Optionally, the distributed disaster recovery system can achieve the following technical effects by dynamically updating the monitoring period based on a preset multiple when the number of consecutive anomalies on a service node does not reach a preset threshold, and controlling the monitoring module to re-collect node information according to the updated period:

[0156] (1) Resource optimization: When the number of consecutive anomalies of a service node is lower than the preset threshold, it indicates that the node is currently relatively stable and does not need to be monitored too frequently. By extending the monitoring cycle, the operating load of the monitoring module can be effectively reduced, system resources can be saved, and network bandwidth consumption and processing overhead can be reduced.

[0157] (2) Flexibility of fault detection: The introduction of preset multiples makes the adjustment of the monitoring cycle more flexible. The monitoring frequency can be dynamically adjusted according to the actual operating status of the service node, thereby ensuring the timeliness of fault detection while avoiding the waste of resources caused by over-monitoring.

[0158] (3) Precise response: The updated monitoring cycle can more accurately match the health status of service nodes, ensuring that the system can respond quickly when continuous anomalies occur, while reducing the monitoring frequency when the node is stable, avoiding frequent disturbances to stable nodes, and improving the overall responsiveness and operation and maintenance efficiency of the system.

[0159] (4) Preventive maintenance: By adjusting the monitoring cycle, the system can continuously monitor at a lower frequency before the number of consecutive abnormalities of the service node reaches the preset threshold, and promptly discover potential unstable factors, providing data support for preventive maintenance and helping to take measures in advance to prevent the occurrence or spread of faults.

[0160] In summary, by dynamically adjusting the monitoring cycle, the above embodiments achieve accurate monitoring of service node status and efficient utilization of resources. This ensures timely response when service nodes experience continuous anomalies, while saving system resources by reducing the monitoring frequency when nodes are running stably.

[0161] In one optional embodiment, if there is an update to the master node in the main cluster, the distributed disaster recovery system generates a first signal; if there is no update to the master node in the main cluster, the distributed disaster recovery system analyzes the new node information collected by the monitoring module through the control module.

[0162] Optionally, the master node is updated to indicate that in the master cluster, the position of the master node (Leader) that was originally responsible for handling read and write requests has changed due to events such as failure, maintenance, or election of a new leader, that is, a follower node (Follower) has been elected as the new master node.

[0163] Optionally, a first signal is generated when there is an update on the master node, enabling the distributed disaster recovery system to quickly switch service nodes. The function of this mechanism is as follows:

[0164] (1) Instant notification: The generation and propagation of the first signal ensures that all components in the system can immediately know the changes of the master node, avoiding application layer connection errors or data processing delays caused by information delays.

[0165] (2) Seamless switching: Through the first signal, applications and services can seamlessly switch from one master node to another, reducing business interruption time caused by master node changes and improving service continuity and user experience.

[0166] (3) Data consistency: After the master node is updated, all components ensure timely identification of the new master node by responding to the first signal, which promotes data consistency and avoids data conflicts or loss caused by using the wrong service node.

[0167] Optionally, the master node is not updated, meaning the leader node in the master cluster remains unchanged, and there is no failover or election of a new leader.

[0168] Optionally, if the master node does not update, the control module analyzes the new node information collected by the monitoring module. The function of this mechanism is as follows:

[0169] (1) Resource saving: When the master node is stable, the control module only analyzes the information collected by the monitoring module instead of generating the first signal across the entire network, thereby reducing unnecessary signal generation and propagation overhead and saving system resources.

[0170] (2) Continuous monitoring: Even if the master node does not change, the control module will still analyze the node information to ensure that potential faults or performance degradation trends can be detected in a timely manner, providing a basis for preventive maintenance.

[0171] (3) Refined management: By continuously monitoring rather than intervening only when the master node is updated, the system can achieve refined management of the status of each node, which enhances the ability to solve local problems and improves the stability and availability of the entire system.

[0172] In one optional embodiment, after transmitting the node information of L nodes to the control module for analysis to obtain the node status of each node, if the node status of a service node is abnormal, the distributed disaster recovery system obtains the number of abnormal nodes in the main cluster, wherein the number of abnormal nodes is the total number of nodes in the main cluster whose node status is abnormal; if the number of abnormal nodes is less than or equal to a preset number, the distributed disaster recovery system updates the master node of the main cluster based on the normal nodes in the cluster, wherein normal nodes are nodes whose node status is normal; if the number of abnormal nodes is greater than the preset number, the distributed disaster recovery system updates the master node of the main cluster based on the normal nodes and the management nodes in the cluster.

[0173] Optionally, when the number of abnormal nodes is less than or equal to a preset number, the distributed disaster recovery system relies solely on the normal nodes in the cluster to update the master node, typically implemented through distributed consensus algorithms such as the Paxos protocol, thus avoiding unnecessary resource consumption. When the number of abnormal nodes exceeds the preset number, a management node is introduced to participate in the election, ensuring that even in severe failure scenarios, the distributed disaster recovery system can quickly restore service capabilities and data consistency.

[0174] Optionally, if the number of abnormal nodes exceeds a preset number, the normal nodes and the management node in the cluster can jointly participate in the update of the master node, with the following effects:

[0175] (1) Enhance system robustness: When the main cluster suffers a large-scale failure, the reliability and robustness of the election are improved by introducing management nodes to participate in the election, ensuring that the system can still operate stably under complex failure scenarios.

[0176] (2) Avoid data loss: The addition of a control node helps maintain data consistency and integrity when electing a new master node, avoiding data loss caused by data conflicts during the election process.

[0177] (3) Optimize election strategy: The existence of control nodes can optimize election strategy, such as helping to break the election deadlock in specific situations, or providing additional decision-making basis to select the most suitable master node, thus ensuring service quality and user experience.

[0178] In summary, this embodiment achieves efficient management of disaster recovery switching by dynamically analyzing the number of abnormal nodes in the main cluster and adopting different master node update strategies accordingly. It can not only respond quickly to small-scale failures, but also ensure system stability and data security in large-scale failure scenarios. This mechanism based on state analysis and dynamic strategy adjustment improves the overall disaster recovery capability and resource utilization efficiency of the system.

[0179] This application embodiment also provides a switching device for a distributed disaster recovery system. It should be noted that the switching device for a distributed disaster recovery system in this application embodiment can be used to execute the switching method for a distributed disaster recovery system provided in this application embodiment. The following describes the switching device for a distributed disaster recovery system provided in this application embodiment.

[0180] According to an embodiment of this application, an apparatus for implementing the switching method of the above-described distributed disaster recovery system is also provided. Figure 9 This is a schematic diagram of a switching device for an optional distributed disaster recovery system according to an embodiment of this application, as shown below. Figure 9 As shown, the device includes: a first analysis unit 901, a first detection unit 902, and a first update unit 903.

[0181] Optionally, the first analysis unit 901 is used to collect node information of L nodes in the main cluster through the monitoring module, and transmit the node information of the L nodes to the control module for analysis to obtain the node status of each node; the first detection unit 902 is used to detect the number of consecutive abnormal IP addresses corresponding to the service node when the node status of the service node is abnormal; the first update unit 903 is used to update the service node to the master node in the backup cluster and generate a first signal when the number of consecutive abnormalities exceeds a preset number and all nodes in the same region corresponding to the service node are in an abnormal state, wherein the nodes in the same region are nodes in the same region as the service node among the L nodes, and the first signal is used to prompt the domain name server to update the domain name.

[0182] In one optional embodiment, the first analysis unit 901 includes: a first determination subunit, a second determination subunit, and a third determination subunit.

[0183] Optionally, the first determining subunit is configured to determine the node status of the i-th node as disconnected if the node information received by the control module does not include the IP address of the i-th node, wherein the i-th node is one of the L nodes; the second determining subunit is configured to determine the node status of the i-th node as abnormal if the node information received by the control module includes the IP address of the i-th node and abnormal response information, wherein the abnormal response information includes at least network timeout information and node authentication failure information; the third determining subunit is configured to determine the node status of the i-th node as normal if the node information received by the control module includes the IP address of the i-th node and role identifier, wherein the role identifier is a primary node identifier or a backup node identifier.

[0184] In one optional embodiment, the switching device of the distributed disaster recovery system further includes: a first acquisition unit, an initialization unit, and a monitoring and control unit.

[0185] Optionally, the first acquisition unit is used to process client requests from user devices through the service node and acquire the number of consecutive anomalies when the node status of the service node is normal; the initialization unit is used to clear the number of consecutive anomalies of the IP address corresponding to the service node to zero and initialize the monitoring period corresponding to the service node when the number of consecutive anomalies is greater than 0; the monitoring control unit is used to monitor the update status of the master node in the master cluster when the number of consecutive anomalies is less than or equal to 0 / after the monitoring period corresponding to the service node is initialized.

[0186] In one optional embodiment, the switching device of the distributed disaster recovery system further includes a generation unit.

[0187] Optionally, the generation unit is used to generate a second signal when the number of consecutive anomalies exceeds a preset number and not all nodes in the same region corresponding to the service node are in an abnormal state. The second signal is used to prompt the operation and maintenance personnel to check the service nodes in an abnormal state.

[0188] In one optional embodiment, the switching device of the distributed disaster recovery system further includes a monitoring and update unit.

[0189] Optionally, the monitoring update unit is used to update the monitoring period of the service node in the monitoring module based on a preset multiple when the number of consecutive anomalies is less than or equal to a preset number, and to control the monitoring module to re-collect the node information of the service node based on the updated monitoring period.

[0190] In one alternative embodiment, the monitoring and control unit includes: a generation subunit and a first analysis subunit.

[0191] Optionally, a generation subunit is used to generate a first signal when there is an update to the master node in the main cluster; and a first analysis subunit is used to control the control module to analyze the new node information collected by the monitoring module when there is no update to the master node in the main cluster.

[0192] In one optional embodiment, the switching device of the distributed disaster recovery system further includes: a second acquisition unit, a second update unit, and a third update unit.

[0193] Optionally, the second acquisition unit is used to acquire the number of abnormal nodes in the main cluster when the node status of the service node is abnormal, wherein the number of abnormal nodes is the total number of nodes in the main cluster whose node status is abnormal; the second update unit is used to update the master node of the main cluster based on the normal nodes in the cluster when the number of abnormal nodes is less than or equal to a preset number, wherein the normal nodes are nodes whose node status is normal; the third update unit is used to update the master node of the main cluster based on the normal nodes and the control nodes in the cluster when the number of abnormal nodes is greater than the preset number.

[0194] As can be seen from the above, this application adopts a real-time monitoring and intelligent switching approach. By integrating network status monitoring and control logic, it achieves the goal of quickly identifying and responding to anomalies in the main cluster nodes, thereby reducing the risk of data loss while ensuring service continuity.

[0195] Specifically, this application collects node information from L nodes in the main cluster through a monitoring module, and the control module analyzes the collected node information. Once it detects that a service node is currently in an abnormal state, the number of consecutive abnormal occurrences of a service node exceeds a preset number, and all nodes in the same region corresponding to the service node are abnormal, the disaster recovery switchover process is immediately initiated to switch the service node to the main node in the backup cluster. In other words, the service node role is switched to the main node in the backup cluster. A first signal is generated to notify the domain name server to update, and client traffic is guided to transmit to healthy nodes. This achieves the technical effect of improving data security and service reliability during the disaster recovery switchover process, thereby solving the technical problem of high data loss risk during the switchover of existing disaster recovery systems with a one-main-two-backup architecture.

[0196] It should be noted that the first analysis unit 901, the first detection unit 902, and the first update unit 903 mentioned above correspond to steps S401 to S403 in the method embodiment. The three units and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 204) and processed by one or more processors (e.g., processors 202a, 202b, ..., 202n). The above modules can also be part of the device and run in the computer terminal 20 provided in the embodiment.

[0197] Embodiments of this application can also provide an electronic device. Figure 10 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 10 As shown, the electronic device includes: one or more ( Figure 10 (Only one is shown) processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0198] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0199] The processor can access the information and application programs stored in the memory via the transmission device to execute the following steps: Collect node information of L nodes in the main cluster through the monitoring module, and transmit the node information of the L nodes to the control module for analysis to obtain the node status of each node; if the node status of the service node is abnormal, detect the number of consecutive abnormal IP addresses corresponding to the service node; if the number of consecutive abnormal IP addresses exceeds a preset number, and all nodes in the same region corresponding to the service node are in an abnormal state, update the service node to the master node in the backup cluster, and generate a first signal, wherein the nodes in the same region are nodes in the same region as the service node among the L nodes, and the first signal is used to prompt the domain name server to update the domain name.

[0200] The processor can invoke information and applications stored in the memory via the transmission device to execute the following steps: If the node information received by the control module does not include the IP address of the i-th node, determine that the node status of the i-th node is disconnected, where the i-th node is one of L nodes; If the node information received by the control module includes the IP address of the i-th node and abnormal response information, determine that the node status of the i-th node is abnormal, where the abnormal response information includes at least network timeout information and node authentication failure information; If the node information received by the control module includes the IP address of the i-th node and role identifier, determine that the node status of the i-th node is normal, where the role identifier is either the primary node identifier or the backup node identifier.

[0201] The processor can access information and applications stored in memory via the transmission device to perform the following steps: when the service node is in a normal state, process client requests from user devices through the service node and obtain the number of consecutive anomalies; when the number of consecutive anomalies is greater than 0, clear the number of consecutive anomalies for the IP address corresponding to the service node and initialize the monitoring period corresponding to the service node; when the number of consecutive anomalies is less than or equal to 0 / after initializing the monitoring period corresponding to the service node, monitor the update status of the master node in the master cluster.

[0202] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: when the number of consecutive anomalies exceeds a preset number, and not all nodes in the same region corresponding to the service node are in an abnormal state, a second signal is generated, wherein the second signal is used to prompt the operation and maintenance personnel to check the service nodes in an abnormal state.

[0203] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: when the number of consecutive anomalies is less than or equal to a preset number, update the monitoring period of the service node in the monitoring module based on a preset multiple, and control the monitoring module to re-collect the node information of the service node based on the updated monitoring period.

[0204] The processor can access information and applications stored in memory via a transmission device to perform the following steps: generating a first signal when there is an update to the master node in the main cluster; and controlling the control module to analyze the new node information collected by the monitoring module when there is no update to the master node in the main cluster.

[0205] The processor can access information and applications stored in the memory via a transmission device to execute the following steps: If the service node's node status is abnormal, obtain the number of abnormal nodes in the main cluster, where the number of abnormal nodes is the total number of nodes in the main cluster whose node status is abnormal; if the number of abnormal nodes is less than or equal to a preset number, update the main cluster's master node based on the normal nodes in the cluster, where normal nodes are nodes whose node status is normal; if the number of abnormal nodes is greater than the preset number, update the main cluster's master node based on the normal nodes and the control node in the cluster.

[0206] The present application provides a technical solution for a switching method of a distributed disaster recovery system. The present application adopts a real-time monitoring and intelligent switching approach. By integrating network status monitoring and control logic, it achieves the goal of quickly identifying and responding to anomalies in the main cluster nodes, thereby achieving the technical effect of reducing the risk of data loss while ensuring service continuity.

[0207] Specifically, this application collects node information from L nodes in the main cluster through a monitoring module, and the control module analyzes the collected node information. Once it detects that a service node is currently in an abnormal state, the number of consecutive abnormal occurrences of a service node exceeds a preset number, and all nodes in the same region corresponding to the service node are abnormal, the disaster recovery switchover process is immediately initiated to switch the service node to the main node in the backup cluster. In other words, the service node role is switched to the main node in the backup cluster. A first signal is generated to notify the domain name server to update, and client traffic is guided to transmit to healthy nodes. This achieves the technical effect of improving data security and service reliability during the disaster recovery switchover process, thereby solving the technical problem of high data loss risk during the switchover of existing disaster recovery systems with a one-main-two-backup architecture.

[0208] Those skilled in the art will understand that Figure 10 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 10 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 10 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 10 The different configurations shown.

[0209] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0210] Embodiments of this application may also provide a storage medium.

[0211] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the switching method of the distributed disaster recovery system provided in the above method embodiment.

[0212] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0213] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing the switching method steps of a distributed disaster recovery system.

[0214] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0215] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0216] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0217] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0218] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0219] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0220] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A switching method for a distributed disaster recovery system, characterized in that, The distributed disaster recovery system includes at least a primary cluster and a backup cluster. The primary cluster and the backup cluster adopt an asynchronous replication mechanism. The primary cluster includes L nodes distributed in a first region and a second region, and the backup cluster includes M nodes distributed in the second region, where L and M are both positive integers. The switching method of the distributed disaster recovery system includes: The monitoring module collects node information of the L nodes in the main cluster and transmits the node information of the L nodes to the control module for analysis to obtain the node status of each node. If the node status of a service node is abnormal, detect the number of consecutive abnormal IP addresses corresponding to the service node. If the number of consecutive anomalies exceeds a preset number, and all nodes in the same region corresponding to the service node are in an abnormal state, the service node is updated to the master node in the backup cluster, and a first signal is generated. The nodes in the same region are nodes in the same region as the service node among the L nodes. The first signal is used to prompt the domain name server to update the domain name.

2. The switching method for a distributed disaster recovery system according to claim 1, characterized in that, The node information of the L nodes is transmitted to the control module for analysis to obtain the node status of each node, including: If the node information received by the control module does not include the IP address of the i-th node, the node status of the i-th node is determined to be disconnected, wherein the i-th node is one of the L nodes; If the node information received by the control module includes the IP address of the i-th node and the abnormal response information, the node state of the i-th node is determined to be the abnormal state, wherein the abnormal response information includes at least network timeout information and node authentication failure information. If the node information received by the control module includes the IP address and role identifier of the i-th node, the node status of the i-th node is determined to be normal, wherein the role identifier is either the primary node identifier or the backup node identifier.

3. The switching method for a distributed disaster recovery system according to claim 1, characterized in that, After transmitting the node information of the L nodes to the control module for analysis to obtain the node status of each node, the switching method of the distributed disaster recovery system further includes: When the service node is in a normal state, the client requests from the user device are processed through the service node, and the number of consecutive anomalies is obtained. If the number of consecutive anomalies is greater than 0, the number of consecutive anomalies for the IP address corresponding to the service node is cleared to zero, and the monitoring period corresponding to the service node is initialized. If the number of consecutive anomalies is less than or equal to 0, or after the monitoring period corresponding to the service node is initialized, monitor the update status of the master node in the master cluster.

4. The switching method for a distributed disaster recovery system according to claim 1, characterized in that, After transmitting the node information of the L nodes to the control module for analysis to obtain the node status of each node, the switching method of the distributed disaster recovery system further includes: If the number of consecutive anomalies exceeds a preset number, and not all nodes in the same region corresponding to the service node are in the abnormal state, a second signal is generated. The second signal is used to prompt maintenance personnel to check the service nodes in the abnormal state.

5. The switching method for a distributed disaster recovery system according to claim 1, characterized in that, After detecting the number of consecutive abnormal IP addresses corresponding to the service node, the switching method of the distributed disaster recovery system further includes: If the number of consecutive anomalies is less than or equal to the preset number, the monitoring period of the service node in the monitoring module is updated based on a preset multiple, and the monitoring module is controlled to re-collect the node information of the service node based on the updated monitoring period.

6. The switching method for a distributed disaster recovery system according to claim 3, characterized in that, Monitoring the update status of the master nodes in the master cluster includes: The first signal is generated when there is an update to the master node in the main cluster; If the master node in the main cluster is not updated, the control module is instructed to analyze the new node information collected by the monitoring module.

7. The switching method for a distributed disaster recovery system according to claim 1, characterized in that, After transmitting the node information of the L nodes to the control module for analysis to obtain the node status of each node, the switching method of the distributed disaster recovery system further includes: When the node status of a service node is abnormal, obtain the number of abnormal nodes in the main cluster, wherein the number of abnormal nodes is the total number of nodes in the main cluster whose node status is abnormal. If the number of abnormal nodes is less than or equal to a preset number, the master node of the main cluster is updated based on the normal nodes in the cluster, wherein the normal node is a node whose node status is normal. If the number of abnormal nodes exceeds the preset number, the master node of the main cluster is updated based on the normal nodes and control nodes in the cluster.

8. A switching device for a distributed disaster recovery system, characterized in that, The distributed disaster recovery system includes at least a primary cluster and a backup cluster, wherein the primary cluster and the backup cluster employ an asynchronous replication mechanism. The primary cluster comprises L nodes distributed in a first region and a second region, and the backup cluster comprises M nodes distributed in the second region, where L and M are both positive integers. The switching device of the distributed disaster recovery system includes: The first analysis unit is used to collect node information of L nodes in the main cluster through the monitoring module, and transmit the node information of the L nodes to the control module for analysis to obtain the node status of each node. The first detection unit is used to detect the number of consecutive abnormal IP addresses corresponding to the service node when the node status of the service node is abnormal. The first update unit is used to update the service node to the master node in the backup cluster and generate a first signal when the number of consecutive anomalies exceeds a preset number and all nodes in the same region corresponding to the service node are in an abnormal state. The nodes in the same region are nodes in the same region as the service node among the L nodes. The first signal is used to prompt the domain name server to update the domain name.

9. A computer program product, characterized in that, The computer program product includes a computer program, wherein, when the computer program is executed, it controls the computer program product to perform the switching method of the distributed disaster recovery system according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the switching method of the distributed disaster recovery system according to any one of claims 1 to 7.

Images