System disaster recovery switching method and device and nonvolatile storage medium

Abstract

The invention discloses a system disaster recovery switching method and device and a nonvolatile storage medium. The method comprises the steps that the real-time operation states of a first operation system and a second operation system are obtained, the first operation system is a main system, and the second operation system is an auxiliary system; under the condition that the real-time operation state of the first operation system is switched from normal operation to disaster occurrence and the real-time operation state of the second operation system is kept as normal operation, modifying a preset main system identifier in a database from a first identifier corresponding to the first operation system to a second identifier corresponding to the second operation system, obtaining a modified main system identifier; and on the basis of the modified main system identifier, local connection is established between the second operation system and the database again, the cache of the second operation system is updated, and the disaster recovery switching process is completed. The invention solves the technical problem that the current system disaster recovery switching technology is difficult to achieve second-level disaster recovery switching under the asymmetric active-active architecture.

Description

Technical Field

[0001] This invention relates to the field of information system security, and more specifically, to a system disaster recovery switching method, apparatus, and non-volatile storage medium. Background Technology

[0002] With the increasing demands for continuity and stability in business systems, disaster recovery has become an indispensable component. While traditional off-site disaster recovery models can meet data security requirements, they are significantly insufficient in terms of business continuity, especially in the face of campus-wide disasters. Recovery Time Objective (RTO) often ranges from hours to days, which clearly cannot meet high availability requirements. In recent years, there has been a shift towards intra-city active-active architectures, aiming to achieve rapid business takeover, shorten recovery time, and improve customer experience. However, the implementation of symmetric and asymmetric active-active architectures faces varying degrees of challenges. Asymmetric active-active architectures, due to their strong data consistency requirements and cross-campus data access characteristics, often have their disaster recovery switchover time limited by the synchronization speed of cached data, resulting in an RTO typically remaining at the minute level, making it difficult to achieve the goal of second-level recovery. This constitutes one of the main difficulties in the practical application of active-active architectures.

[0003] Current technologies attempt to improve RTO (Recovery Time Objective) and simplify disaster recovery failover by using dual synchronization in data centers. However, for applications that rely on globally unique data resources and struggle with data segmentation, this approach not only increases system construction costs but also faces risks of data inconsistency and increased complexity in traffic distribution during practical operation. Furthermore, current technologies typically require system restarts or reconfigurations during disaster recovery failover to establish data resource connections to the new master system. This process is not only time-consuming but can also lead to system instability or service interruptions during failover, impacting business operations.

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

[0005] This invention provides a system disaster recovery switching method, apparatus, and non-volatile storage medium to at least solve the technical problem that current system disaster recovery switching technologies are unable to achieve second-level disaster recovery switching under asymmetric dual-active architecture.

[0006] According to one aspect of the present invention, a system disaster recovery switching method is provided, comprising: acquiring the real-time operating status of a first operating system and a second operating system, wherein the first operating system is a primary system and the second operating system is a secondary system, and the real-time operating status includes normal operation or disaster occurrence; when the real-time operating status of the first operating system switches from normal operation to disaster occurrence while the real-time operating status of the second operating system remains normal operation, modifying the preset primary system identifier in the database from a first identifier corresponding to the first operating system to a second identifier corresponding to the second operating system to obtain the modified primary system identifier; based on the modified primary system identifier, re-establishing a local connection between the second operating system and the database, and updating the cache of the second operating system to complete the disaster recovery switching process.

[0007] Optionally, updating the cache of the second operating system includes: periodically refreshing static data from the database to the cache based on a preset time interval, wherein the static data is data whose change frequency during the operation of the second operating system is less than a preset threshold; and refreshing dynamic data from the database to the cache after re-establishing a local connection between the second operating system and the database, wherein the dynamic data is data whose change frequency during the operation of the second operating system is not less than a preset threshold.

[0008] Optionally, before obtaining the real-time operating status of the first and second operating systems, the method further includes: constructing a system disaster recovery flag table in the database, wherein the system disaster recovery flag table includes a master system identifier; configuring the master system identifier as a first identifier; adding an application disaster recovery flag to the application configuration files of the first and second operating systems; configuring the application disaster recovery flag corresponding to the first operating system as the first identifier; configuring the application disaster recovery flag corresponding to the second operating system as a second identifier; establishing a local connection between the first operating system and the database based on the application disaster recovery flag corresponding to the first operating system; and establishing a remote connection between the second operating system and the database based on the application disaster recovery flag corresponding to the second operating system.

[0009] Optionally, based on the modified master system identifier, the second operating system is re-established with the database locally, including: obtaining the application disaster recovery flag corresponding to the second operating system; and establishing a local connection between the second operating system and the database if the application disaster recovery flag corresponding to the second operating system matches the modified master system identifier.

[0010] Optionally, if the real-time operating status of the first operating system changes from normal operation to disaster occurrence while the real-time operating status of the second operating system remains normal operation, the method further includes: changing the access status of the second operating system in the database from read-only to read-write; and modifying the domain name system resolution rules to resolve the domain name to the load balancing address of the second operating system.

[0011] Optionally, it also includes: when the real-time operating status of the first operating system changes from disaster-stricken to normal operation and the real-time operating status of the second operating system remains normal operation, modifying the domain name system resolution rules to resolve the domain name to the load balancing address of the first operating system or the load balancing address of the second operating system.

[0012] According to another aspect of the present invention, a system disaster recovery switching device is also provided, comprising: an acquisition module, configured to acquire the real-time operating status of a first operating system and a second operating system, wherein the first operating system is a master system and the second operating system is a slave system, and the real-time operating status includes normal operation or disaster occurrence; a modification module, configured to, when the real-time operating status of the first operating system switches from normal operation to disaster occurrence and the real-time operating status of the second operating system remains normal operation, modify the preset master system identifier in the database from a first identifier corresponding to the first operating system to a second identifier corresponding to the second operating system, thereby obtaining a modified master system identifier; and a switching module, configured to, based on the modified master system identifier, re-establish a local connection between the second operating system and the database, and update the cache of the second operating system, thereby completing the disaster recovery switching process.

[0013] According to another aspect of the present invention, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored program, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute any of the above-described system disaster recovery switching methods.

[0014] According to another aspect of the present invention, a computer device is also provided, the computer device including a processor, the processor being configured to run a program, wherein the program executes any of the above-described system disaster recovery switching methods during runtime.

[0015] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements any of the above-described system disaster recovery switching methods.

[0016] In this embodiment of the invention, a system disaster recovery switching method is adopted. This involves acquiring the real-time operating status of a first operating system and a second operating system, where the first operating system is the primary system and the second operating system is the secondary system. The real-time operating status includes normal operation or a disaster event. When the real-time operating status of the first operating system switches from normal operation to a disaster event, while the real-time operating status of the second operating system remains normal operation, the preset primary system identifier in the database is modified from the first identifier corresponding to the first operating system to the second identifier corresponding to the second operating system, resulting in a modified primary system identifier. Based on the modified primary system identifier, a local connection is re-established between the second operating system and the database, and the cache of the second operating system is updated, completing the disaster recovery switching process. This achieves the goal of improving the system recovery speed after a disaster, thus realizing the technical effect of second-level disaster recovery switching under an asymmetric active-active architecture. This solves the technical problem that current system disaster recovery switching technologies struggle to achieve second-level disaster recovery switching under an asymmetric active-active architecture. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0018] Figure 1 This is a typical symmetrical dual-active system architecture diagram provided by an optional embodiment of the present invention;

[0019] Figure 2 This is a typical asymmetric dual-active system architecture diagram provided by an optional embodiment of the present invention;

[0020] Figure 3 A hardware structure block diagram of a computer terminal for implementing a system disaster recovery switching method is shown.

[0021] Figure 4 This is a flowchart illustrating the system disaster recovery switching method provided in an embodiment of the present invention;

[0022] Figure 5 This is a system cache update architecture diagram provided according to an optional embodiment of the present invention;

[0023] Figure 6 This is a schematic diagram of a single instance of the second operating system provided by an optional embodiment of the present invention;

[0024] Figure 7 This is a schematic diagram of the switching process when a disaster occurs in the first operating system, according to an optional embodiment of the present invention;

[0025] Figure 8 This is a schematic diagram of the switching process when a disaster occurs in the second operating system, according to an optional embodiment of the present invention;

[0026] Figure 9 This is a schematic diagram of a single instance of the first operating system provided by an optional embodiment of the present invention;

[0027] Figure 10 This is a structural block diagram of a system disaster recovery switching device provided according to an embodiment of the present invention. Detailed Implementation

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

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention 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 the invention 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 a 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.

[0030] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0031] Disaster: A sudden event that causes an information system to malfunction or reach an unacceptable level of service, and lasts for a specific period of time.

[0032] Disaster recovery: The system can ensure that data is lost as little as possible and that the system can operate without interruption or resume normal operation as quickly as possible when a disaster occurs, through various methods such as dual-active and disaster recovery deployment.

[0033] Active-active: The information system utilizes instances deployed on two geographical nodes to work collaboratively, enabling parallel access to services, parallel processing of services, and parallel storage of data. When an instance on one geographical node experiences a disaster or failure, only some services are affected, and instances deployed on other geographical nodes can promptly take over the services.

[0034] Symmetrical dual-active: Figure 1 This is a typical symmetric dual-active system architecture diagram provided by an optional embodiment of the present invention. For example... Figure 1 As shown, in a symmetric active-active system, both running instances can complete production tasks, with traffic distributed between the two instances. Each instance has its own application cluster providing external services; the data layer requires strong data consistency between the two instances, providing undifferentiated data services on both sides. A symmetric active-active approach can be adopted when business traffic can be clearly divided, data can be stored separately, and the system does not depend on globally unique data resources.

[0035] Asymmetric dual-active: Figure 2 This is a typical asymmetric dual-active system architecture diagram provided by an optional embodiment of the present invention. For example... Figure 2 As shown, both running instances can complete production operations, and traffic is distributed between the two instances. Each instance has its own application cluster to provide services to the outside world; the data layer only provides data services to the outside world on a daily basis, and there is cross-campus data access. The primary end replicates data to the secondary end through data replication technology.

[0036] Recovery Time Objective (RTO): The time required for information systems to recover from a shutdown and for all participating parties' information systems to regain normal access after a disaster.

[0037] Recovery Point Objective (RPO): The point in time to which data must be recovered after a disaster.

[0038] According to an embodiment of the present invention, a system disaster recovery switching method embodiment 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.

[0039] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 3 A hardware block diagram of a computer terminal used to implement a system disaster recovery switching method is shown. Figure 3As shown, the computer terminal 30 may include one or more processors (shown as 302a, 302b, ..., 302n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 304 for storing data. 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 3 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 30 may also include... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.

[0040] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 30. As described in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0041] The memory 304 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the system disaster recovery switching method in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 304, thereby realizing the above-mentioned system disaster recovery switching method for the application. The memory 304 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 304 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 30 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.

[0042] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 30.

[0043] Figure 4 This is a flowchart illustrating the system disaster recovery switching method provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the method includes the following steps:

[0044] Step S401: Obtain the real-time operating status of the first operating system and the second operating system respectively, wherein the first operating system is the main system and the second operating system is the auxiliary system, and the real-time operating status includes normal operation or disaster occurrence.

[0045] In this process, the first operating system is the primary system, responsible for handling the main business traffic and data access. The second operating system is the secondary system, which, under normal conditions, accesses data resources managed by the primary system through cross-campus connections, maintaining data consistency and business backup capabilities. The fundamental difference between the two is that the primary system bears the main workload of production operations, while the secondary system prepares for rapid takeover and disaster recovery of production operations, ensuring that even if the primary system fails, the secondary system can quickly switch to the primary system and continue to provide business services.

[0046] The real-time operating status of the system includes two scenarios: normal operation and disaster response. Normal operation means that the system is in the expected stable working state and can process all business requests without interruption. Disaster response means that the information system has encountered an unforeseen failure or disaster, which makes it unable to continue to provide services. In this state, the system may be unable to operate normally due to hardware failure, software error, network interruption or external attack, etc., and disaster recovery plan needs to be activated immediately to ensure business continuity.

[0047] This optional embodiment primarily obtains the real-time operating status of the system by monitoring and evaluating key system indicators and response mechanisms. Specifically, the health status and operational efficiency of the first and second operating systems can be periodically assessed through the system's built-in health check mechanism, log analysis, performance monitoring tools, or a dedicated disaster recovery monitoring system. When certain key indicators of the first operating system exceed preset thresholds, or when the system is unable to respond to specific health check requests, it can be determined that the first operating system has entered a disaster state. The status determination of the second operating system is similar. In practice, the above-mentioned status monitoring and determination is usually an automated process. Through pre-set algorithms and rules, the system can automatically identify and report changes in operating status to facilitate the immediate initiation of disaster recovery switchover processes, ensuring business continuity and data security.

[0048] Step S402: When the real-time operating status of the first operating system changes from normal operation to disaster occurrence, and the real-time operating status of the second operating system remains normal operation, the preset main system identifier in the database is modified from the first identifier corresponding to the first operating system to the second identifier corresponding to the second operating system, thus obtaining the modified main system identifier.

[0049] In this step, when the real-time operating status of the first operating system changes from normal operation to disaster state, while the real-time operating status of the second operating system remains normal, the disaster recovery switchover process will be triggered. The core of this process lies in modifying the preset master system identifier in the database. Specifically, the first identifier, originally pointing to the first operating system, is updated to a second identifier pointing to the second operating system, completing the role swap and making the second operating system the master system, assuming primary responsibility for business processing and data access. This switchover is executed quickly at the database level by calling specific interfaces or executing pre-programmed switchover scripts, ensuring that all application instances connected to the database can instantly identify the new master system, thereby achieving a smooth data access switchover and achieving the high efficiency of a second-level disaster recovery switchover. After the identifier update is complete, subsequent resource access adjustments will be made based on the modified master system identifier, including re-establishing local database connections and updating cached data, thereby ensuring that the second operating system can quickly take over business operations and reduce business interruption time.

[0050] Step S403: Based on the modified main system identifier, re-establish a local connection between the second running system and the database, and update the cache of the second running system to complete the disaster recovery switchover process.

[0051] In this step, based on the modified master system identifier, the second running system is designated as the master system. A new local connection is established with the database based on the database resource address information and cache server address information of the second running system. Simultaneously, to ensure data accuracy and system availability, the replication and synchronization of cached data on the second running system is initiated. This synchronization process includes timed synchronization of static data and real-time construction of dynamic data. The former benefits from the deployment of a pre-refresh mechanism, enabling the validity of static data to be confirmed quickly. The latter ensures that dynamic data remains synchronized with the database state under the updated master system identifier by querying the latest business data, such as transaction records and user status, thereby guaranteeing the continuity of business logic and the reliability of data services.

[0052] Through the above steps, the goal of improving the system recovery speed after a disaster is achieved, thereby realizing the technical effect of second-level disaster recovery switching under an asymmetric active-active architecture, and thus solving the technical problem that current system disaster recovery switching technology is difficult to achieve second-level disaster recovery switching under an asymmetric active-active architecture.

[0053] As an optional embodiment, updating the cache of the second operating system includes: periodically refreshing static data from the database to the cache based on a preset time interval, wherein the static data is data whose change frequency during the operation of the second operating system is less than a preset threshold; and refreshing dynamic data from the database to the cache after re-establishing a local connection between the second operating system and the database, wherein the dynamic data is data whose change frequency during the operation of the second operating system is not less than a preset threshold.

[0054] Optionally, static data mainly consists of configuration parameters required for system operation, which are rarely or never modified during system runtime. Dynamic data mainly consists of data that changes frequently during system runtime, such as message queue data.

[0055] Figure 5 This is a system cache update architecture diagram provided according to an optional embodiment of the present invention. For example... Figure 5 As shown, a timed pre-refresh mechanism is used for caching static data. The second running system, namely the A2 instance, runs a scheduled task to refresh the static data from the database to the cache according to a preset time interval. In actual operation, the time interval can be set according to factors such as the size of the static data and the refresh duration, for example, 10 seconds. Specifically, in the second running system, the application server reads the main system identifier from the local database. If the second identifier is not equal to the current main system identifier, it means that the current application system is a secondary system, and database connection and cache connection are required to read the data that needs to be cached from the database and load and refresh it into the cache of the second running system.

[0056] For dynamic data caching, this optional embodiment adds a switching interface, `switchRunMode`, to the application server. The switching interface receives both the original primary system identifier and the modified primary system identifier. When the switching interface identifies that the second identifier does not match the original primary system identifier but matches the modified primary system identifier, it indicates that the second running system was a secondary system before the switch and requires the construction of a dynamic data cache. Subsequently, based on the local connection between the second running system and the database, the second running system will initiate a series of queries to extract all dynamic data. Finally, after obtaining the latest dynamic data, the second running system loads the data into the local cache, ensuring that all necessary business data is up-to-date and accurate.

[0057] As an optional embodiment, before obtaining the real-time operating status of the first operating system and the second operating system, the method further includes: constructing a system disaster recovery flag table in the database, wherein the system disaster recovery flag table includes a master system identifier; configuring the master system identifier as a first identifier; adding an application disaster recovery flag to the application configuration files of the first operating system and the second operating system; configuring the application disaster recovery flag corresponding to the first operating system as the first identifier; configuring the application disaster recovery flag corresponding to the second operating system as a second identifier; establishing a local connection between the first operating system and the database based on the application disaster recovery flag corresponding to the first operating system; and establishing a remote connection between the second operating system and the database based on the application disaster recovery flag corresponding to the second operating system.

[0058] Optionally, the first identifier is A1, representing the first running system, and the second identifier is A2, representing the second running system. First, a system disaster recovery flag table is created in the database, with one field, `systemRunMode`, representing the primary system identifier, and the first identifier, A1, is used as the primary system identifier. Second, an application disaster recovery flag, `instanceFlag`, is added to the application configuration files of both the first and second running systems. The first running system's program is configured with A1, and the second running system's program is configured with A2. This application configuration separation technique ensures that the program versions of A1 and A2 are consistent, but their configuration files are different. During runtime, each running system can explicitly query its corresponding application disaster recovery flag.

[0059] The application configures addresses for both the first and second running systems' data resources. `db-A1` represents the database resource address information for the first running system, and `db-A2` represents the database resource address information for the second running system; `cache-A1` represents the cache server address information for the first running system, and `cache-A2` represents the cache server address information for the second running system. Upon startup, the application first establishes a local database connection `db-connection-local` and a local cache connection `cache-connection-local` based on `db-A1` and `cache-A1`. For the second running system, after establishing the local connection, the application identifies the application's corresponding application disaster recovery flag A2. After identifying the second running system as a secondary system, it establishes a remote database connection `db-connection-remote` and a remote cache connection `cache-connection-remote` from the application system to the primary system based on the primary system's database resources and cache server address information.

[0060] As an optional embodiment, based on the modified master system identifier, the second operating system is re-established with the database to establish a local connection, including: obtaining the application disaster recovery flag corresponding to the second operating system; and establishing a local connection between the second operating system and the database if the application disaster recovery flag corresponding to the second operating system matches the modified master system identifier.

[0061] Optionally, the application disaster recovery flag corresponding to the second running system, i.e., the second identifier A2, is first obtained. When the application server in the second running system confirms that its application disaster recovery flag is consistent with the updated primary system identifier in the database, it indicates that the second running system has become the new primary system. At this time, the second running system performs local connection reconstruction with the database, establishes a local database connection db-connection-local and a local cache connection cache-connection-local, directly uses its locally deployed data resources, and completes subsequent cache update operations.

[0062] As an optional embodiment, when the real-time operating status of the first operating system changes from normal operation to disaster occurrence while the real-time operating status of the second operating system remains normal operation, the method further includes: changing the access status of the second operating system in the database from read-only to read-write; and modifying the domain name system resolution rules to resolve the domain name to the load balancing address of the second operating system.

[0063] Optionally, Figure 6 This is a schematic diagram of a single instance operation of the second running system provided by an optional embodiment of the present invention. For example... Figure 6 As shown, when the first operating system, i.e., the A1 instance, experiences a disaster, while the second operating system, i.e., the A2 instance, continues to operate normally, a disaster recovery switchover operation is performed. First, the status of the second database is modified from read-only to read-write. Second, the DNS domain name resolution rules are modified to resolve the domain name to the second load balancer address, forwarding all business traffic to the second operating system. Finally, the primary system identifier in the disaster recovery flag table of the database is changed to the second identifier, and the second operating system is set as the primary system. This completes the construction of the dynamic data cache in the second operating system, updates the disaster recovery flag table, and enables the second operating system to provide services normally.

[0064] As an optional embodiment, it further includes: when the real-time operating state of the first operating system switches from disaster-stricken to normal operation and the real-time operating state of the second operating system remains normal operation, modifying the domain name system resolution rules to resolve the domain name to the load balancing address of the first operating system or the load balancing address of the second operating system.

[0065] Optionally, Figure 7This is a schematic diagram of the switching process when a disaster occurs in the first operating system, according to an optional embodiment of the present invention. Figure 7 As shown, when the first running system A1 experiences a disaster, it switches to a single instance of the second running system A2. When the first running system recovers and resumes normal operation, a switchback operation is performed, modifying the DNS domain name resolution rules to resolve the domain name to either the first or second load balancing address according to the established rules. After the switchover is completed, all business traffic is distributed to the first and second running instances according to the established rules, achieving (A2 primary, A1 secondary) dual-active operation. The switchover can be completed within seconds. Subsequently, the system can be maintained during periods of low business volume by maintaining the primary / standby status of the database and calling the switchover interface to switch the dual-active operation mode from (A2 primary, A1 secondary) to (A1 primary, A2 secondary).

[0066] As an alternative embodiment, Figure 8 This is a schematic diagram of the switching process when a disaster occurs in the second operating system, according to an optional embodiment of the present invention. Figure 8 As shown, when the second operating system A2 experiences a disaster, a switchover operation is performed, switching to single-instance operation of the first operating system A1; when the second operating system A2 returns to normal, a switchback operation is performed, restoring the dual-active operating mode (A1 primary, A2 secondary).

[0067] Specifically, Figure 9 This is a schematic diagram of a single instance of the first operating system provided by an optional embodiment of the present invention. For example... Figure 9 As shown, if the second operating system experiences a disaster or failure, since it is a secondary system in normal dual-active operation mode, the first operating system can still provide services normally. Therefore, only the DNS domain name resolution rules need to be modified to resolve the domain name to the address of the first load balancer. After the switchover is completed, all business traffic is distributed to the first operating system. The switchover can be completed within seconds, with almost no impact on business operations.

[0068] Furthermore, once the secondary operating system recovers from a disaster or failure, it can provide normal service. However, since all business traffic is currently distributed to the primary operating system, it has not yet returned to normal active-active operation. After confirming that the secondary operating system has recovered, only the DNS domain name resolution rules need to be modified to resolve the domain name to the load balancer address of either the primary or secondary system according to the established rules. After the switchover is completed, all business traffic is distributed to the primary and secondary operating instances according to the established rules, restoring normal active-active operation.

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

[0070] Through the above description of the embodiments, those skilled in the art can clearly understand that the system disaster recovery switching method according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0071] According to embodiments of the present invention, an apparatus for implementing the above-described system disaster recovery switching method is also provided. Figure 10 This is a structural block diagram of a system disaster recovery switching device provided according to an embodiment of the present invention, such as... Figure 10 As shown, the device includes: an acquisition module 1001, a modification module 1002, and a switching module 1003. The device will be described below.

[0072] The acquisition module 1001 is used to acquire the real-time operating status of the first operating system and the second operating system, wherein the first operating system is the main system and the second operating system is the auxiliary system, and the real-time operating status includes normal operation or disaster occurrence.

[0073] Modification module 1002, connected to acquisition module 1001, is used to modify the preset main system identifier in the database from the first identifier corresponding to the first operating system to the second identifier corresponding to the second operating system when the real-time operating status of the first operating system switches from normal operation to disaster occurrence and the real-time operating status of the second operating system remains normal operation, so as to obtain the modified main system identifier.

[0074] The switching module 1003, connected to the modification module 1002, is used to re-establish a local connection between the second running system and the database based on the modified main system identifier, and update the cache of the second running system to complete the disaster recovery switching process.

[0075] It should be noted that the acquisition module 1001, modification module 1002, and switching module 1003 mentioned above correspond to steps S401 to S403 in the embodiments. Multiple modules implement the same instances and application scenarios as their corresponding steps, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run on the computer terminal 30 provided in the embodiments.

[0076] Embodiments of the present invention may provide a computer device. Optionally, in this embodiment, the computer device may be located in at least one of a plurality of network devices in a computer network. The computer device includes a memory and a processor.

[0077] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the system disaster recovery switching method and apparatus in this embodiment of the invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned system disaster recovery switching method. 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 a computer 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.

[0078] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: obtaining the real-time operating status of the first operating system and the second operating system, wherein the first operating system is the master system and the second operating system is the auxiliary system, and the real-time operating status includes normal operation or disaster occurrence; when the real-time operating status of the first operating system switches from normal operation to disaster occurrence, while the real-time operating status of the second operating system remains normal operation, modifying the preset master system identifier in the database from the first identifier corresponding to the first operating system to the second identifier corresponding to the second operating system to obtain the modified master system identifier; based on the modified master system identifier, re-establishing a local connection between the second operating system and the database, and updating the cache of the second operating system to complete the disaster recovery switchover process.

[0079] Optionally, the processor may also execute program code that performs the following steps: updating the cache of the second operating system, including: periodically refreshing static data from the database to the cache based on a preset time interval, wherein the static data is data whose change frequency is less than a preset threshold during the operation of the second operating system; and refreshing dynamic data from the database to the cache after re-establishing a local connection between the second operating system and the database, wherein the dynamic data is data whose change frequency is not less than a preset threshold during the operation of the second operating system.

[0080] Optionally, the processor may also execute program code with the following steps: before obtaining the real-time operating status of the first operating system and the second operating system, the processor further includes: constructing a system disaster recovery flag table in the database, wherein the system disaster recovery flag table includes a master system identifier; configuring the master system identifier as a first identifier; adding an application disaster recovery flag to the application configuration files of the first operating system and the second operating system; configuring the application disaster recovery flag corresponding to the first operating system as the first identifier; configuring the application disaster recovery flag corresponding to the second operating system as a second identifier; establishing a local connection between the first operating system and the database based on the application disaster recovery flag corresponding to the first operating system; and establishing a remote connection between the second operating system and the database based on the application disaster recovery flag corresponding to the second operating system.

[0081] Optionally, the processor may also execute program code that performs the following steps: re-establishing a local connection between the second operating system and the database based on the modified master system identifier, including: obtaining the application disaster recovery flag corresponding to the second operating system; and establishing a local connection between the second operating system and the database if the application disaster recovery flag corresponding to the second operating system matches the modified master system identifier.

[0082] Optionally, the processor may also execute program code that performs the following steps: when the real-time operating state of the first operating system changes from normal operation to disaster occurrence, and the real-time operating state of the second operating system remains normal operation, the processor may further perform the following steps: change the access state of the second operating system in the database from read-only to read-write; and modify the domain name system resolution rules to resolve the domain name to the load balancing address of the second operating system.

[0083] Optionally, the processor may also execute program code that performs the following steps: when the real-time operating state of the first operating system switches from disaster-stricken to normal operation and the real-time operating state of the second operating system remains normal operation, modify the domain name system resolution rules to resolve the domain name to the load balancing address of the first operating system or the load balancing address of the second operating system.

[0084] This invention provides a system disaster recovery switching scheme. By acquiring the real-time operating status of a first operating system and a second operating system (where the first operating system is the primary system and the second operating system is the secondary system), the real-time operating status includes normal operation or disaster occurrence. When the real-time operating status of the first operating system switches from normal operation to disaster occurrence while the real-time operating status of the second operating system remains normal, the preset primary system identifier in the database is modified from the first identifier corresponding to the first operating system to the second identifier corresponding to the second operating system, resulting in a modified primary system identifier. Based on the modified primary system identifier, a local connection is re-established between the second operating system and the database, and the cache of the second operating system is updated, completing the disaster recovery switching process. This achieves the goal of improving the system recovery speed after a disaster, thus realizing the technical effect of second-level disaster recovery switching under an asymmetric active-active architecture, and solving the technical problem that current system disaster recovery switching technologies struggle to achieve second-level disaster recovery switching under an asymmetric active-active architecture.

[0085] 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 non-volatile storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0086] Embodiments of the present invention also provide a non-volatile storage medium. Optionally, in this embodiment, the aforementioned non-volatile storage medium can be used to store the program code executed by the system disaster recovery switching method provided in the above embodiments.

[0087] Optionally, in this embodiment, the non-volatile 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.

[0088] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: obtaining the real-time operating status of the first operating system and the second operating system, wherein the first operating system is the master system and the second operating system is the auxiliary system, and the real-time operating status includes normal operation or disaster occurrence; when the real-time operating status of the first operating system switches from normal operation to disaster occurrence, while the real-time operating status of the second operating system remains normal operation, modifying the preset master system identifier in the database from the first identifier corresponding to the first operating system to the second identifier corresponding to the second operating system to obtain the modified master system identifier; based on the modified master system identifier, re-establishing a local connection between the second operating system and the database, and updating the cache of the second operating system to complete the disaster recovery switchover process.

[0089] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: updating the cache of the second operating system, including: periodically refreshing static data from the database to the cache based on a preset time interval, wherein the static data is data whose change frequency during the operation of the second operating system is less than a preset threshold; and refreshing dynamic data from the database to the cache after re-establishing a local connection between the second operating system and the database, wherein the dynamic data is data whose change frequency during the operation of the second operating system is not less than a preset threshold.

[0090] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: before obtaining the real-time operating status of the first operating system and the second operating system, the method further includes: constructing a system disaster recovery flag table in the database, wherein the system disaster recovery flag table includes a master system identifier; configuring the master system identifier as a first identifier; adding an application disaster recovery flag to the application configuration files of the first operating system and the second operating system; configuring the application disaster recovery flag corresponding to the first operating system as the first identifier; configuring the application disaster recovery flag corresponding to the second operating system as a second identifier; establishing a local connection between the first operating system and the database based on the application disaster recovery flag corresponding to the first operating system; and establishing a remote connection between the second operating system and the database based on the application disaster recovery flag corresponding to the second operating system.

[0091] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: re-establishing a local connection between the second operating system and the database based on the modified master system identifier, including: obtaining the application disaster recovery flag corresponding to the second operating system; and establishing a local connection between the second operating system and the database if the application disaster recovery flag corresponding to the second operating system matches the modified master system identifier.

[0092] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: when the real-time operating state of the first operating system changes from normal operation to disaster occurrence, and the real-time operating state of the second operating system remains normal operation, the method further includes: changing the access state of the second operating system in the database from read-only to read-write; and modifying the domain name system resolution rules to resolve the domain name to the load balancing address of the second operating system.

[0093] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: when the real-time operating state of the first operating system switches from disaster-stricken to normal operation and the real-time operating state of the second operating system remains normal operation, modify the domain name system resolution rules to resolve the domain name to the load balancing address of the first operating system or the load balancing address of the second operating system.

[0094] Embodiments of the present invention also provide a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can: acquire the real-time operating status of a first operating system and a second operating system, wherein the first operating system is a master system and the second operating system is a slave system, and the real-time operating status includes normal operation or disaster occurrence; when the real-time operating status of the first operating system switches from normal operation to disaster occurrence, while the real-time operating status of the second operating system remains normal operation, modify the preset master system identifier in the database from the first identifier corresponding to the first operating system to the second identifier corresponding to the second operating system to obtain the modified master system identifier; based on the modified master system identifier, re-establish a local connection between the second operating system and the database, and update the cache of the second operating system to complete the disaster recovery switchover process.

[0095] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0096] In the above embodiments of the present invention, 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.

[0097] 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 can be a logical functional division, and in actual implementation, there may be other division methods. For instance, 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.

[0098] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] Furthermore, the functional units in the various embodiments of the present invention 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.

[0100] 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 non-volatile storage medium. Based on this understanding, the technical solution of the present invention, 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 the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

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

Claims

1. A system failover switching method, characterized by, The application comprises the following steps: acquiring real-time running states of a first running system and a second running system respectively, wherein the first running system is a main system, the second running system is an auxiliary system, and the real-time running states include normal running or disaster occurrence; in the case that the real-time running state of the first running system is switched from the normal running to the disaster occurrence and the real-time running state of the second running system remains the normal running, modifying a preset main system identifier in a database from a first identifier corresponding to the first running system to a second identifier corresponding to the second running system to obtain a modified main system identifier; based on the modified main system identifier, re-establishing a local connection between the second running system and the database and updating a cache of the second running system to complete a disaster recovery switching process.

2. The method of claim 1, wherein, The updating of the cache of the second running system comprises: based on a preset time interval, refreshing static data from the database to the cache at a regular time interval, wherein the static data is data of the second running system whose change frequency is less than a preset threshold during running; after the re-establishment of the local connection between the second running system and the database, refreshing dynamic data from the database to the cache, wherein the dynamic data is data of the second running system whose change frequency is not less than the preset threshold during running.

3. The method of claim 1, wherein, Before the acquisition of the real-time running states of the first running system and the second running system, the application further comprises the following steps: constructing a system disaster recovery flag table in the database, wherein the system disaster recovery flag table includes the main system identifier; configuring the main system identifier as the first identifier; adding an application disaster recovery flag in an application program configuration file of the first running system and the second running system respectively; configuring the application disaster recovery flag corresponding to the first running system as the first identifier; configuring the application disaster recovery flag corresponding to the second running system as the second identifier; based on the application disaster recovery flag corresponding to the first running system, establishing a local connection between the first running system and the database; based on the application disaster recovery flag corresponding to the second running system, establishing a remote connection between the second running system and the database.

4. The method of claim 1, wherein, The re-establishment of the local connection between the second running system and the database based on the modified main system identifier comprises: acquiring the application disaster recovery flag corresponding to the second running system; in the case that the application disaster recovery flag corresponding to the second running system matches the modified main system identifier, establishing a local connection between the second running system and the database.

5. The method of claim 1, wherein, In the case that the real-time running state of the first running system is switched from the normal running to the disaster occurrence and the real-time running state of the second running system remains the normal running, the application further comprises the following steps: modifying an access state of the second running system in the database from read-only to read-write; modifying a domain name system resolution rule to resolve a domain name to a load balancing address of the second running system.

6. The method according to any one of claims 1 to 5, characterized in that, The application further comprises the following steps: In a case that the real-time running state of the first running system is switched from the disaster occurrence to the normal running and the real-time running state of the second running system remains the normal running, a domain name system resolution rule is modified to resolve a domain name to a load balancing address of the first running system or a load balancing address of the second running system.

7. A system disaster recovery switchover apparatus, characterized by comprising: The system comprises: an acquisition module, configured to acquire real-time running states of a first running system and a second running system respectively, wherein the first running system is a main system, the second running system is a secondary system, and the real-time running states include normal running or disaster occurrence; a modification module, configured to, in a case that the real-time running state of the first running system is switched from the normal running to the disaster occurrence and the real-time running state of the second running system remains the normal running, modify a preset main system identifier in a database from a first identifier corresponding to the first running system to a second identifier corresponding to the second running system to obtain a modified main system identifier; a switching module, configured to, based on the modified main system identifier, re-establish a local connection between the second running system and the database, and update a cache of the second running system to complete a disaster recovery switching process.

8. A non-volatile storage medium, comprising: The non-volatile storage medium comprises a stored program, wherein the program controls a device in which the non-volatile storage medium is located to perform the system disaster recovery switching method in any one of claims 1 to 6 when the program is running.

9. A computer device, comprising: The system comprises: a memory and a processor, the memory stores a computer program; the processor is configured to execute the computer program stored in the memory, and the computer program, when running, causes the processor to perform the system disaster recovery switching method in any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the system disaster recovery switching method in any one of claims 1 to 6. The computer program, when executed by the processor, implements the system disaster recovery switching method in any one of claims 1 to 6.

Images