Automatic switching device for main and standby faults of distributed database

Abstract

According to the main and standby fault automatic switching device of the distributed database provided by the embodiment of the invention, a database fault and fusing processing service module and database main / standby node services are deployed in the same host, and database fault and fusing processing services are provided; a local remote procedure call technology is used for carrying out state monitoring and fault switching on database services and main and standby nodes of a database, a Zookeeper service module provides Zookeeper services and is responsible for managing state locks of the main and standby nodes of the database, and an Nginx service module carries out health monitoring, high-availability reverse proxy, fault transfer and fault switching on the database services on the main and standby nodes and is responsible for managing state locks of the main and standby nodes of the database. The virtual IP module sets a virtual IP address, and a distributed database formed based on Zookeeper and Nginx high-availability services can perform automatic main-standby fault switching, so that main-standby high availability is realized, the service continuity is ensured, manual intervention is eliminated, and meanwhile, a shutdown window when a main node fails is greatly reduced.

Description

Technical Field

[0001] The present application relates to the technical field of fault switching, and in particular to a method for implementing automatic switching of primary and standby faults of a distributed database based on high-availability services. Background Art

[0002] High availability of database master and standby nodes is a key technology for improving system availability and business recovery capabilities. It ensures business continuity, so that when the primary database fails or is unavailable, the backup database can quickly take over, thereby reducing business interruption time and alleviating various losses caused by catastrophic accidents, which is especially important for critical business applications. In addition, in terms of cost and complexity, maintaining a distributed database system with high availability of master and standby nodes has great advantages, which greatly reduces the personnel costs of monitoring and maintenance, and also reduces software and hardware expenses.

[0003] In the prior art, when the master node fails, the standby node is switched to the active state by manually executing ActivateStandby, and the server address and port in the client connection string are modified to the corresponding standby node on the application side, so as to achieve the purpose of switching. However, there will also be problems with business continuity: when the master node fails, the application side first perceives the problem, and then manual intervention intervenes, which will inevitably greatly extend the downtime and recovery window of the failure, thereby failing to ensure business continuity. At the same time, there is also the problem of complex and costly operations: after manually switching and activating the standby node, the connection between the client and the original master node has actually failed, and the client configuration must be passively modified and reconnected to the activated standby node. This is unacceptable for a considerable part of the business. For example, the information for accessing the original master node is host1:port1. After a failure occurs, the access information on the application side needs to be uniformly modified to the new master node host2:port2 to restore the application.

[0004] Therefore, how to solve the problems generated in the prior art has become one of the research directions of those skilled in the art. Summary of the invention

[0005] The present application provides a distributed database automatic switching device for master and standby failures.

[0006] In order to achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0007] In a first aspect, an embodiment of the present application provides a distributed database master-slave fault automatic switching device, the device comprising a client and a server, the server comprising a database fault and fuse processing service module and a Zookeeper service module, the server comprising a high-availability Nginx service module and a virtual IP module;

[0008] The database fault and fuse processing service module is deployed on the same host as the database master / standby node service to provide database fault and fuse processing services, and uses local remote procedure call technology to monitor the status of database services and database master and standby nodes and perform fault switching;

[0009] Zookeeper service module, which is used to provide Zookeeper services and manage the status locks of the database master / slave nodes;

[0010] Nginx service module, used for health monitoring, high availability reverse proxy, failover and failover of database services on primary and standby nodes;

[0011] Virtual IP module, used to set the virtual IP address.

[0012] In a possible implementation, the database fault and fuse processing service module registers the service to the Zookeeper service module. When the master / backup node fails, the master / backup node that has not failed will provide external services and the master / backup node that has failed will be switched to a standby state.

[0013] In a possible implementation, when the master node service exits due to an error or the master node service is disconnected from the database fault and fuse processing service module, the database fault and fuse processing service module corresponding to the master node releases the status lock of the Zookeeper service module;

[0014] After the database fault and fuse processing service module on the standby node detects that the status lock of the Zookeeper service module has been released, it actively acquires the status lock and activates the standby node service status to complete the active-standby switch.

[0015] In one possible implementation, when the database fault and fuse processing service module on the master node exits due to an error, the master node service triggers the fuse protection mechanism and switches to the standby service mode. The Zookeeper service module releases the status lock. After the database fault and fuse processing service module on the standby node detects that the status lock is released, it actively acquires the status lock and activates the standby node service status to complete the master-standby switching.

[0016] In a possible implementation, the database service status monitored by the database fault and fuse processing service module includes DB_ACTIVE status, DB_STANDBY status, DB_NOT_READY status, DB_NO_CONNCTION status and DB_DOWN status, wherein the DB_ACTIVE status indicates that the status of the master / standby node monitored by the current database fault and fuse processing service is in an externally serviceable state;

[0017] The DB_STANDBY status indicates that the master / standby node status monitored by the current database fault and fuse handling service is in the standby service status;

[0018] The DB_NOT_READY status indicates that the current database fault and fuse handling service has established a connection with the monitored primary / secondary node, but the current database node is temporarily unable to provide external services;

[0019] The DB_NO_CONNCTION status indicates that the current database fault and fuse handling service is disconnected from the network during the startup process or after successfully establishing a connection with the database service;

[0020] The DB_DOWN status indicates the status of the current database fault and fuse handling service after the connection with the database service times out or the database service is shut down normally.

[0021] In a possible implementation, the database fault and fuse processing service module is further used to:

[0022] When the database service status is DB_ACTIVE, the database fault and fuse processing service module continuously detects the heartbeat of the database service. If the heartbeat acquisition times out, the status switches to DB_NO_CONNCTION. If the database status returns to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY.

[0023] When the database service status is DB_STANDBY, if the database service failover condition is triggered and the node is elected as the primary node, the status is changed to DB_ACTIVE; similarly, if the heartbeat acquisition times out, the status is switched to DB_NO_CONNCTION; if the database status is returned to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY.

[0024] When the database service status is DB_NOT_READY, if the database service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; similarly, if the heartbeat acquisition times out, the status is switched to DB_NO_CONNCTION.

[0025] When the database service status is DB_NO_CONNCTION, if the database service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; if the heartbeat detection connection establishment time times out, it is considered that the database service has stopped and the status is set to DB_DOWN.

[0026] When the database service status is DB_DOWN, the process is restored to the process initialization logic, waiting for the database service to establish a connection with the DBFC service.

[0027] In a possible implementation, after the virtual IP module sets the virtual IP address, the Nginx service module monitors the status of the Nginx service module through a heartbeat mechanism, and then configures the access IP address and port of the distributed database master and standby nodes that need to be proxied to quickly complete the failover function.

[0028] In a possible implementation, when a database master node fails, the Nginx service module completes failover according to service availability through a high-availability reverse proxy configuration, so that the client reconnects to the address and port of the available service.

[0029] Compared with the prior art, the embodiment of the present application provides an automatic master-slave fault switching device for a distributed database. The database fault and fuse processing service module and the database master / slave node service are deployed on the same host, providing database fault and fuse processing services, and using local remote procedure call technology to monitor the status and perform fault switching on the database service and the database master / slave nodes. The Zookeeper service module is responsible for managing the status lock of the database master / slave nodes. The Nginx service module performs health monitoring, high-availability reverse proxy, failover and failover of the database service on the master / slave nodes. The virtual IP module sets the virtual IP address. The distributed database composed of Zookeeper and Nginx high-availability services can perform automatic master-slave fault switching, achieves master-slave high availability, ensures business continuity, eliminates manual intervention, and greatly reduces the downtime window when the master node fails. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0031] Figure 1 A schematic diagram of the structure of a distributed database automatic switching device for active / standby failures proposed in an embodiment of the present application is shown.

[0032] Figure 2 A flow chart of the DBFC module working mode proposed in the embodiment of the present application is shown. DETAILED DESCRIPTION

[0033] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0034] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0035] It should be noted that, in the absence of conflict, the features in the embodiments of the present application may be combined with each other.

[0036] In the prior art, when the master node fails, the standby node is switched to the active state by manually executing ActivateStandby, and the server address and port in the client connection string are modified to the corresponding standby node on the application side, so as to achieve the purpose of switching. However, there will also be problems with business continuity: when the master node fails, the application side first perceives the problem, and then manual intervention intervenes, which will inevitably greatly extend the downtime and recovery window of the failure, thereby failing to ensure business continuity. At the same time, there is also the problem of complex and costly operations: after manually switching and activating the standby node, the connection between the client and the original master node has actually failed, and the client configuration must be passively modified and reconnected to the activated standby node. This is unacceptable for a considerable part of the business. For example, the information for accessing the original master node is host1:port1. After a failure occurs, the access information on the application side needs to be uniformly modified to the new master node host2:port2 to restore the application.

[0037] In summary, due to its good performance, low price, good scalability, friendly user interface, and the ability to be deployed and run on general servers, SQL-compatible Massive Parallel Processing (MPP) databases have greatly lowered the threshold for users to use and greatly improved production efficiency. However, traditional MPP databases generally use a master-slave architecture to achieve high availability of the master node. When the master node fails, manual intervention is required, as well as cumbersome and lengthy recovery windows such as modifying the configuration on the application side.

[0038] Therefore, in order to solve the technical problems in the above-mentioned prior art, an embodiment of the present application proposes an automatic master-slave fault switching device for a distributed database. The device is based on high-availability services such as Zookeeper and Nginx, which can not only eliminate manual intervention, but also reduce the downtime window when the master node fails, thereby ensuring the continuity of the application. The automatic master-slave fault switching device in the embodiment of the present application is described in detail below.

[0039] Please refer to Figure 1 , Figure 1 The schematic diagram of the structure of the automatic switching device for the master-slave fault of the distributed database proposed in the embodiment of the present application is shown, the device includes a client and a server, the server includes a database fault and fuse processing service module and a Zookeeper service module, and the server includes a high-availability Nginx service module and a virtual IP module;

[0040] The database fault and fuse processing service module is deployed on the same host as the database master / standby node service to provide database fault and fuse processing services, and uses local remote procedure call technology to monitor the status of database services and database master and standby nodes and perform fault switching;

[0041] Zookeeper service module, which is used to provide Zookeeper services and manage the status locks of the database master / slave nodes;

[0042] Nginx service module, used for health monitoring, high availability reverse proxy, failover and failover of database services on primary and standby nodes;

[0043] Virtual IP module, used to set the virtual IP address.

[0044] The Database Failover Controller (DBFC) is a system component designed to handle database failures and service interruptions. It is deployed on the same server as the primary and standby (or backup) nodes of the database as an independent process, and continuously monitors the status of the database service using local remote procedure call (RPC) technology. It can automatically detect whether the primary or standby database is running normally without human intervention.

[0045] The core responsibility of the database fault and fuse handling service module is to closely monitor the database master and standby nodes and take prompt action when any fault is detected. Once a problem is found in the primary database, the DBFC will immediately activate the standby database to take over. This process is called "failover". In this way, even if the primary database fails, the service can continue to run seamlessly, ensuring business continuity.

[0046] Highly available Nginx service: Nginx is deployed on the primary and standby nodes, which receives requests from clients and transparently forwards the requests to the primary or standby database based on the actual status of the database service (healthy or faulty). This Nginx strategy ensures that client requests can still be processed normally even if the primary database fails.

[0047] Combining the virtual IP (VIP) with Keepalived provides a floating entry address for the Nginx cluster. In this way, even if an Nginx node fails, the VIP will automatically bind to another healthy Nginx node, so that for the client, the access address of the service remains unchanged, improving transparency and availability.

[0048] The Zookeeper service module provides the Zookeeper service, which is a distributed, open source distributed application coordination service. The Nginx service uses a high-performance HTTP and reverse proxy web server.

[0049] In a possible implementation, the database fault and fuse processing service module registers the service to the Zookeeper service module. When the master / backup node fails, the master / backup node that has not failed will provide external services and the master / backup node that has failed will be switched to a standby state.

[0050] The Zookeeper service module provides the Zookeeper service, which is a distributed coordination service used to maintain the consistency of the master and standby states of the database. The database fault and fuse handling service module will register its own service with the Zookeeper cluster. When the database fault and fuse handling service module decides to switch between the master and standby nodes, it will use Zookeeper to ensure the orderly progress of the process. Zookeeper manages state locks to prevent concurrency conflicts during the switching process, ensuring that only one database node is considered the "master" node at any time, thereby maintaining data consistency and service stability.

[0051] The DBFC module is used to automatically detect and handle database failures, and Zookeeper is used to coordinate the switching of the active and standby states to ensure the uninterrupted operation of database services.

[0052] When the master node fails, the DBFC module and the Zookeeper module work together to ensure high availability of the database service. This can lead to two situations:

[0053] The first case is the process in which the DBFC module proactively detects a problem with the primary node and coordinates failover through Zookeeper.

[0054] In a possible implementation, when the master node service exits due to an error or the master node service is disconnected from the database fault and fuse processing service module, the database fault and fuse processing service module corresponding to the master node releases the status lock of the Zookeeper service module;

[0055] After the database fault and fuse processing service module on the standby node detects that the status lock of the Zookeeper service module has been released, it actively acquires the status lock and activates the standby node service status to complete the active-standby switch.

[0056] When the master node service exits due to an error or the master node service is disconnected from the DBFC, the DBFC service corresponding to the master node releases the Zookeeper status lock. After the DBFC on the standby node detects that the status lock is released, it actively acquires the lock and activates the standby node service status to complete the master-standby switch.

[0057] In the second case, even if the DBFC itself encounters a problem, there is a mechanism to trigger the fuse protection and complete the active / standby switch, which reflects the completeness of the system design:

[0058] In one possible implementation, when the database fault and fuse processing service module on the master node exits due to an error, the master node service triggers the fuse protection mechanism and switches to the standby service mode. The Zookeeper service module releases the status lock. After the database fault and fuse processing service module on the standby node detects that the status lock is released, it actively acquires the status lock and activates the standby node service status to complete the master-standby switching.

[0059] When the DBFC service on the master node exits due to an error, after a period of waiting timeout, the master node service triggers the fuse protection mechanism to switch to the standby service mode. At the same time, the Zookeeper module releases the lock. After the DBFC on the standby node detects that the lock is released, it actively acquires the lock and activates the standby node service status to complete the master-standby switch.

[0060] In a possible implementation, the database service status monitored by the database fault and fuse processing service module includes DB_ACTIVE status, DB_STANDBY status, DB_NOT_READY status, DB_NO_CONNCTION status and DB_DOWN status, wherein the DB_ACTIVE status indicates that the status of the master / standby node monitored by the current database fault and fuse processing service is in an externally serviceable state;

[0061] The DB_STANDBY status indicates that the master / standby node status monitored by the current database fault and fuse handling service is in the standby service status;

[0062] The DB_NOT_READY status indicates that the current database fault and fuse handling service has established a connection with the monitored primary / secondary node, but the current database node is temporarily unable to provide external services;

[0063] The DB_NO_CONNCTION status indicates that the current database fault and fuse handling service is disconnected from the network during the startup process or after successfully establishing a connection with the database service;

[0064] The DB_DOWN status indicates the status of the current database fault and fuse handling service after the connection with the database service times out or the database service is shut down normally.

[0065] The database service status monitored by DBFC is a specific classification of the database operation status, which helps to accurately understand the health of the system and take corresponding measures.

[0066] 1.DB_ACTIVE: This means that the database node monitored by the DBFC is in an active working state and can respond to external query requests and data operations. This is the mode in which the database normally serves customers.

[0067] 2.DB_STANDBY: This state indicates that although the DBFC has established a connection with the database, the database currently exists as a standby node and does not directly process client requests. When the primary node fails, the standby node will be automatically or manually promoted to the active state to take over the service.

[0068] 3.DB_NOT_READY: This is a transitional state, which means that although the connection is established, the database cannot process external requests temporarily due to internal maintenance, insufficient resources, or other reasons, and needs to wait until normal service status is restored.

[0069] 4.DB_NO_CONNECTION: This status reflects that the communication between DBFC and the database is interrupted, which may be caused by network problems, DBFC service restart or database abnormality. At this time, the system may need to try to re-establish the connection or adopt a failover strategy.

[0070] 5.DB_DOWN: When the database service is completely unavailable, it will be marked as DB_DOWN. This may be caused by a long connection timeout, abnormal database shutdown, or hardware failure. This state usually requires administrator intervention to check and repair database problems.

[0071] The DBFC module needs to be started before it enters the working mode. First, when the DBFC service is started and initialized, it will connect to the Zookeeper service and the database service of this node at the same time. If both connections are established successfully, the initial database status is DB_NOT_READY. If any connection is not established successfully, it will enter the service waiting stage. The process logic can only be executed after the connection is successful in this stage. If the connection timeout occurs, the process termination is triggered.

[0072] After normal startup, obtain the database service running status. If the status is DB_NOT_READY, enter the waiting stage; if the status acquisition timeout, set the status to DB_NO_CONNCTION and enter the reconnection stage. If the reconnection timeout fails, the process is triggered to terminate and exit. Otherwise, continue to obtain the status until the status is DB_ACTIVE or DB_STANDBY to enter the master or standby state.

[0073] The above logic, from establishing necessary connections at startup, initializing the database status according to the connection status, to continuously monitoring and responding to different database statuses, truly reflects the rapid response and handling mechanism for faults in high-availability system design, ensuring that the system can resume service as quickly as possible from various abnormal conditions.

[0074] In a possible implementation, the database fault and fuse processing service module is further used to:

[0075] When the database service status is DB_ACTIVE, DBFC continuously detects the heartbeat of the database service. If the heartbeat acquisition times out, the status switches to DB_NO_CONNCTION. If the database status returns to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY.

[0076] When the database service status is DB_STANDBY, if the database service failover condition is triggered and the node is elected as the primary node, the status is changed to DB_ACTIVE; similarly, if the heartbeat acquisition times out, the status is switched to DB_NO_CONNCTION; if the database status is returned to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY.

[0077] When the database service status is DB_NOT_READY, if the database service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; similarly, if the heartbeat acquisition times out, the status is switched to DB_NO_CONNCTION.

[0078] When the database service status is DB_NO_CONNCTION, if the database service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; if the heartbeat detection connection establishment time times out, it is considered that the database service has stopped and the status is set to DB_DOWN.

[0079] When the database service status is DB_DOWN, the process is restored to the process initialization logic, waiting for the database service to establish a connection with the DBFC service.

[0080] Please refer to Figure 2 , Figure 2 The flowchart of the DBFC module working mode proposed in the embodiment of the present application is shown, which is divided into five states:

[0081] First, the database status is in DB_ACTIVE state, and DBFC continuously detects the heartbeat of the database service. If the heartbeat is timed out, the status is switched to DB_NO_CONNCTION. If the database status is returned to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY. When the primary node is shut down normally, the status is switched to DB_DOWN.

[0082] Second, the database status is in DB_STANDBY state. If the database service failover condition is triggered and the node is elected as the primary node, the status is switched to DB_ACTIVE. If the heartbeat acquisition times out, the status is switched to DB_NO_CONNCTION. If the database status is returned to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY. The status is switched to DB_DOWN when the standby service is shut down normally.

[0083] Third, the database status is in DB_NOT_READY state. If the database standby service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; if the heartbeat acquisition times out, the status switches to DB_NO_CONNCTION.

[0084] Fourth, the database status is in DB_NO_CONNCTION state. If the database service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; if the heartbeat detection connection establishment time times out, it is considered that the database service has stopped and the status is set to DB_DOWN.

[0085] Fifth, if the database status is in DB_DOWN state, it will be restored to the process initialization logic, waiting for the database service to establish a connection with the DBFC service.

[0086] In a possible implementation, after the virtual IP module sets the virtual IP address, the Nginx service module monitors the status of the Nginx service module through a heartbeat mechanism, and then configures the access IP address and port of the distributed database master and standby nodes that need to be proxied to quickly complete the failover function.

[0087] The Nginx service is combined with the high-availability distributed database service of the virtual IP master-slave architecture to jointly build a multi-layer high-availability architecture. In the Nginx nodes under the high-availability architecture, virtual IP technology is used and the Keepalived mechanism is set. A virtual IP address is set on the server, where the virtual IP address is the entry address for the client to access Nginx. The Nginx service nodes monitor each other's status through the heartbeat mechanism. At the same time, Nginx itself configures the access IP address and port of the distributed database master and standby nodes that need to be proxied to quickly complete the failover function.

[0088] There are heartbeat monitoring mechanisms between Nginx nodes and between Nginx and the backend database to quickly identify the operating status of each component in the system. Once a component is detected to be unreachable, the relevant failover strategy will be immediately activated to achieve seamless switching. Through such a design, the entire system can effectively deal with single point failures and ensure the continuity and stability of services in a complex and changing network environment.

[0089] In a possible implementation, when a database master node fails, the Nginx service module completes failover according to service availability through a high-availability reverse proxy configuration, so that the client reconnects to the address and port of the available service.

[0090] In a high-availability architecture, whether the database master node or the master node corresponding to Nginx fails, the system can respond quickly and ensure that the service is not interrupted. When the database master node fails, Nginx can immediately redirect the traffic to the backup database according to the pre-configured policy. This process is transparent to the client and ensures business continuity. When the Nginx master node fails, with the help of VIP technology and Keepalived, client requests will be rerouted to the new master node. The automatic drift of VIP ensures the stability of the service address and also achieves seamless service recovery.

[0091] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0092] First, the distributed database automatically switches between active and standby faults, achieving true active and standby high availability and ensuring business continuity.

[0093] Second, the client application automatically reconnects, so that the application side can restore the business status without any sense.

[0094] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A distributed database master-slave fault automatic switching device, characterized in that: The device includes a client and a server, wherein the server includes a database fault and fuse processing service module and a Zookeeper service module, and the server includes a high-availability Nginx service module and a virtual IP module; The database fault and fuse processing service module is deployed on the same host as the database master / standby node service to provide database fault and fuse processing services, and uses local remote procedure call technology to monitor the status of database services and database master and standby nodes and perform fault switching; Zookeeper service module, which is used to provide Zookeeper services and manage the status locks of the database master / slave nodes; Nginx service module, used for health monitoring, high availability reverse proxy, failover and failover of database services on primary and standby nodes; Virtual IP module, used to set the virtual IP address.

2. The automatic switching device for primary and standby failures according to claim 1, characterized in that: The database fault and fuse processing service module registers the service to the Zookeeper service module. When the master / backup node fails, the master / backup node that has not failed will provide external services and the master / backup node that has failed will be switched to the standby state.

3. The automatic switching device for primary and standby failures according to claim 2, characterized in that: When the master node service exits due to an error or the master node service is disconnected from the database fault and fuse processing service module, the database fault and fuse processing service module corresponding to the master node releases the status lock of the Zookeeper service module; After the database fault and fuse processing service module on the standby node detects that the status lock of the Zookeeper service module has been released, it actively acquires the status lock and activates the standby node service status to complete the active-standby switch.

4. The automatic switching device for primary and standby failures according to claim 2, characterized in that: When the database fault and fuse processing service module on the master node exits due to an error, the master node service triggers the fuse protection mechanism and switches to the standby service mode. The Zookeeper service module releases the status lock. After the database fault and fuse processing service module on the standby node detects that the status lock is released, it actively acquires the status lock and activates the standby node service status to complete the master-standby switch.

5. The automatic switching device for master and standby failures according to claim 1, characterized in that: The database service status monitored by the database fault and fuse processing service module includes DB_ACTIVE status, DB_STANDBY status, DB_NOT_READY status, DB_NO_CONNCTION status and DB_DOWN status, among which DB_ACTIVE status indicates that the status of the master / standby node monitored by the current database fault and fuse processing service is in an externally serviceable state; The DB_STANDBY status indicates that the master / standby node status monitored by the current database fault and fuse handling service is in the standby service status; The DB_NOT_READY status indicates that the current database fault and fuse handling service has established a connection with the monitored primary / secondary node, but the current database node is temporarily unable to provide external services; The DB_NO_CONNCTION status indicates that the current database fault and fuse handling service is disconnected from the network during the startup process or after successfully establishing a connection with the database service; The DB_DOWN status indicates the status of the current database fault and fuse handling service after the connection with the database service times out or the database service is shut down normally.

6. The automatic switching device for primary and standby failures according to claim 5, characterized in that: The database fault and fuse processing service module is also used to: When the database service status is DB_ACTIVE, the database fault and fuse processing service module continuously detects the heartbeat of the database service. If the heartbeat acquisition times out, the status switches to DB_NO_CONNCTION. If the database status returns to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY. When the database service status is DB_STANDBY, if the database service failover condition is triggered and the node is elected as the primary node, the status will be changed to DB_ACTIVE; Similarly, if the heartbeat acquisition times out, the status switches to DB_NO_CONNCTION; if the database status returns to recovery mode during the heartbeat detection process, the database service status is set to DB_NOT_READY. When the database service status is DB_NOT_READY, if the database service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; similarly, if the heartbeat acquisition times out, the status is switched to DB_NO_CONNCTION. When the database service status is DB_NO_CONNCTION, if the database service returns to normal during the heartbeat detection process, the status is converted to DB_STANDBY; if the heartbeat detection connection establishment time times out, it is considered that the database service has stopped and the status is set to DB_DOWN. When the database service status is DB_DOWN, the process is restored to the process initialization logic, waiting for the database service to establish a connection with the database fault and fuse processing service.

7. The automatic switching device for master and standby failures according to claim 1, characterized in that: After the Nginx service module sets the virtual IP address in the virtual IP module, it monitors the status of the Nginx service module through the heartbeat mechanism, and then configures the access IP address and port of the distributed database master and standby nodes that need to be proxied to quickly complete the failover function.

8. The automatic switching device for primary and standby failures according to claim 1, characterized in that: When the database master node fails, the Nginx service module completes failover based on service availability through the high-availability reverse proxy configuration, allowing the client to reconnect to the address and port of the available service.

Images