Fault transfer method and device for read-write separation database cluster, equipment and medium

Abstract

The embodiment of the invention provides a failover method and device for a read-write separation database cluster, equipment and a medium, and the method comprises the steps: building a connection pool group according to the node information of a plurality of nodes, the connection pool group comprises a plurality of independent connection pools, and each independent connection pool corresponds to one node; periodically acquiring node state information of each node and connection state information of the physical connection in each independent connection pool; updating an independent connection pool corresponding to each node according to the node state information and the connection state information; and when it is detected that a target node fault exists, determining a target connection pool according to the load state information of the new independent connection pool, the target connection pool being used for responding to the service request. Through a connection pool group architecture, a state timer, idle connection management and a load balancing strategy, rapid fault response, efficient resource utilization, development complexity reduction and dynamic cluster adaptation are realized, so that the stability and service continuity of a database cluster are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of databases, and in particular to a failover method, apparatus, device and medium for a read-write separated database cluster. Background Technology

[0002] In distributed database systems, especially in high-concurrency business scenarios such as financial transactions, e-commerce flash sales, and online games, the stability and availability of the database cluster directly determine business continuity. Such scenarios typically employ a master-slave architecture to improve performance and fault tolerance, with the master node handling write operations and the slave nodes handling read operations. However, node failures in the cluster, such as master node crashes, standby node network outages, or master-slave failover, can lead to database connection interruptions, thereby causing business anomalies.

[0003] Currently, connection pooling technology is used to manage database connections. This involves maintaining a connection pool to directly manage connections from all nodes. When a node fails, connections are attempted from other nodes one by one. This approach requires polling all nodes during each failover, resulting in time-consuming connection attempts. Furthermore, a large number of invalid connections in the connection pool leads to high memory usage and wasted resources. Summary of the Invention

[0004] This application provides a method, apparatus, device, and medium for failover of a read-write separated database cluster, in order to achieve a rapid failover effect.

[0005] In a first aspect, embodiments of this application provide a failover method for a read-write split database cluster, the database cluster comprising multiple nodes; the method includes:

[0006] A connection pool group is created based on the node information of multiple nodes. The connection pool group includes multiple independent connection pools, and each independent connection pool corresponds to one node.

[0007] Periodically obtain the node status information of each node and the connection status information of the physical connections in each independent connection pool;

[0008] Update the independent connection pool corresponding to each node based on node status information and connection status information.

[0009] If a target node failure is detected, a target connection pool is determined based on the load status information of the new independent connection pool. The target connection pool is used to respond to business requests.

[0010] In one possible implementation, the node status information of each node is periodically acquired, including:

[0011] Send a detection request to each node according to the preset detection cycle;

[0012] Based on the response to the detection request, determine the availability status of each node, and generate corresponding node status information based on the availability status of each node.

[0013] In one possible implementation, the method further includes:

[0014] If a target node failure is detected, the availability status of the target node is stored so that all independent connection pools in the connection pool group can obtain the availability status of the target node.

[0015] In one possible implementation, the independent connection pool corresponding to each node is updated based on node status information and connection status information, including:

[0016] If the node status information indicates that the target node is faulty, clear all physical connections in the independent connection pool corresponding to the target node.

[0017] In one possible implementation, the method further includes:

[0018] The recovery time is predicted based on the historical failure modes of the target node, and a physical connection to the backup connection pool corresponding to the target node is established before the recovery time.

[0019] In one possible implementation, the independent connection pool corresponding to each node is updated based on node status information and connection status information, including:

[0020] If the connection status information indicates that there are idle physical connections in the independent connection pool, the idle physical connections in the independent connection pool are reclaimed; the judgment conditions for idle physical connections include a preset idle timeout threshold.

[0021] In one possible implementation, determining the target connection pool based on the load status information of the new independent connection pool includes:

[0022] Based on the load status information of the new independent connection pools, determine the total number of connections, the number of idle connections, and the connection response time for each independent connection pool;

[0023] The target connection pool is determined based on the total number of connections, the number of idle connections, and the connection response time. The preset conditions include the minimum total number of connections, the maximum number of idle connections, and the shortest connection response time.

[0024] Secondly, embodiments of this application provide a failover device for a read-write separation database cluster, the database cluster comprising multiple nodes; the device includes:

[0025] The creation module is used to create a connection pool group based on the node information of multiple nodes. The connection pool group includes multiple independent connection pools, and each independent connection pool corresponds to one node.

[0026] The detection module is used to periodically obtain the node status information of each node and the connection status information of the physical connections in each independent connection pool.

[0027] The update module is used to update the independent connection pool corresponding to each node based on the node status information and connection status information.

[0028] The filtering module is used to determine the target connection pool based on the load status information of the new independent connection pool when a target node failure is detected. The target connection pool is used to respond to business requests.

[0029] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0030] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0031] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0032] The failure transfer method, apparatus, device, and medium for a read / write split database cluster provided in this application embodiment include: creating a connection pool group based on node information of multiple nodes, wherein the connection pool group includes multiple independent connection pools, and each independent connection pool corresponds to one node; periodically acquiring node status information of each node and connection status information of physical connections in each independent connection pool; updating the independent connection pool corresponding to each node based on the node status information and connection status information; and determining the target connection pool based on the load status information of the new independent connection pool when a target node failure is detected, wherein the target connection pool is used to respond to business requests. Through the connection pool group architecture, state timer, idle connection management, and load balancing strategy, rapid fault response, efficient resource utilization, reduced development complexity, and dynamic cluster adaptation are achieved, thereby significantly improving the stability and business continuity of the database cluster. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0034] Figure 1 Flowchart of the failover method for the read / write split database cluster provided in this application Figure 1 ;

[0035] Figure 2 Flowchart of the failover method for the read / write split database cluster provided in this application Figure 2 ;

[0036] Figure 3 Flowchart of the failover method for the read / write split database cluster provided in this application Figure 3 ;

[0037] Figure 4 A schematic diagram of the failover device for the read / write separation database cluster provided in this application;

[0038] Figure 5 A schematic diagram of the structure of the computer device provided in this application.

[0039] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0040] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0041] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0042] In distributed database systems, especially in high-concurrency business scenarios such as financial transactions, e-commerce flash sales, and online games, the stability and availability of the database cluster directly determine business continuity. Such scenarios typically employ a master-slave architecture (read-write separation) to improve performance and fault tolerance, with the master node handling write operations and the slave nodes handling read operations. However, node failures in the cluster, such as master node crashes, standby node network interruptions, or master-slave failover, can lead to database connection interruptions, thereby causing business anomalies.

[0043] To address this problem, existing technologies mainly offer the following three types of solutions:

[0044] (1) Single connection pool scheme: This scheme manages all node connections directly by maintaining a connection pool. When a node fails, it attempts to connect to other nodes one by one. This scheme is simple to implement, but it has significant drawbacks:

[0045] Performance bottleneck: Each failover requires polling all nodes, and the connection attempt takes a long time (e.g., when the master fails, it needs to attempt 5 backup connection attempts, each with a timeout of 2 seconds, for a total of up to 10 seconds).

[0046] Resource waste: The connection pool may contain a large number of invalid connections (such as connections from faulty nodes that are not cleared in time), resulting in high memory consumption and high maintenance costs.

[0047] The development is complex, and the business side needs to handle the read / write separation logic and failover process on its own, resulting in complex and error-prone code.

[0048] (2) Logical connection mapping to physical connection scheme: This scheme abstracts multiple physical connections through logical connections and dynamically allocates physical connections based on node status. For example, when a logical connection is mapped to the primary node, it automatically switches to the backup node in case of failure. Although this scheme simplifies some logic, it has the following problems:

[0049] State synchronization delay: The states of logical and physical connections need to be synchronized frequently. If the synchronization is not timely (such as the failure to detect the master-slave switch in time), it may still lead to connection failure.

[0050] Insufficient load balancing: The load status of the connection pool (such as the number of idle / busy connections) is not considered, which can easily lead to some nodes being overloaded while other nodes are idle.

[0051] (3) Custom failover scheme on the business side: The read / write separation and failover logic are implemented by the application layer. For example, the business code explicitly checks the node status and reconnects. The drawbacks of this scheme include:

[0052] High development costs: Failover logic needs to be implemented separately for each business module, resulting in extremely high maintenance costs.

[0053] Consistency risk: Failover strategies for different business modules may be inconsistent, leading to chaotic connection management.

[0054] Unable to handle dynamic cluster changes: Insufficient support for dynamic adjustment scenarios such as cluster expansion / shrinkage, requiring manual code updates.

[0055] In summary, existing technologies struggle to balance performance, reliability, and development efficiency in high-concurrency scenarios, necessitating a failover method based on connection pools to address these technical challenges.

[0056] To address the aforementioned technical issues, this application provides a failover method for read-write split database clusters, applicable to high-concurrency, distributed database cluster failover scenarios, such as financial transaction systems, e-commerce flash sale platforms, and online game servers. In these scenarios, database clusters typically employ a master-slave architecture (read-write splitting), with the master node handling write operations and the slave node handling read operations. Cluster nodes may fail due to hardware failures, network interruptions, or master-slave failover, leading to interrupted business connections. Traditional solutions require the business side to implement read-write splitting and failover logic independently, or rely on a single connection pool to attempt connections one by one, resulting in slow response times and resource waste. This solution, through a connection pool group architecture and a dynamic state awareness mechanism, achieves rapid isolation of faulty nodes, efficient resource reuse, and transparent operations on the business side, significantly improving system stability and development efficiency.

[0057] In one embodiment, such as Figure 1 As shown, the failover methods for read / write split database clusters include:

[0058] Step 101: Create a connection pool group based on the node information of multiple nodes. The connection pool group includes multiple independent connection pools, and each independent connection pool corresponds to one node.

[0059] Step 102: Periodically obtain the node status information of each node and the connection status information of the physical connections in each independent connection pool;

[0060] Step 103: Update the independent connection pool corresponding to each node based on the node status information and connection status information.

[0061] Step 104: If a target node failure is detected, determine the target connection pool based on the load status information of the new independent connection pool. The target connection pool is used to respond to service requests.

[0062] A connection pool group refers to a collection of multiple independent connection pools. These multiple independent connection pools correspond to multiple nodes in a database cluster. The relationship between an independent connection pool and a node can be one-to-one or one-to-many, but for the database cluster as a whole, its multiple nodes have multiple independent connection pools.

[0063] In one embodiment, each node corresponds to an independent connection pool, forming a mapping relationship between logical connections and multiple physical connection pools. For example, the primary node corresponds to the primary connection pool, standby node 1 corresponds to the standby node 1 connection pool, and standby node 2 corresponds to the standby node 2 connection pool. When a node fails, it is not necessary to poll all standby nodes; instead, the available connection pool is located directly, significantly shortening the response time.

[0064] Node status information is used to describe the fault status of a node, and is determined by real-time detection and judgment of the node status.

[0065] A physical connection refers to the actual communication link between a database client and a database node, including protocol stack status and resource usage information. Physical connections include TCP connections, SSL sessions, and database sessions.

[0066] In one embodiment, updating the independent connection pool corresponding to each node based on node status information and connection status information includes:

[0067] If the node status information indicates that the target node is faulty, clear all physical connections in the independent connection pool corresponding to the target node.

[0068] Specifically, based on database node information, such as the primary node IP and standby node IP lists, an independent connection pool is created for each node, forming a connection pool group. For example, the primary node corresponds to the primary connection pool, standby node 1 corresponds to the standby node 1 connection pool, and standby node 2 corresponds to the standby node 2 connection pool. The availability of each node is periodically checked, such as every 5 seconds, by attempting to establish a physical connection or sending heartbeat packets to determine if the node is faulty. If a node is detected as unavailable, such as due to connection timeout, corresponding node status information is generated. Based on the node status information, all physical connections in the independent connection pool corresponding to the faulty node are cleared. For example, if standby node 1 fails, it is marked as unavailable, and all physical connections (such as TCP connections and SSL sessions) in its connection pool are cleared to ensure that subsequent connection requests do not reuse invalid connections.

[0069] By employing a hierarchical connection pool management and dynamic status detection mechanism, the problems of low fault response efficiency and resource waste in existing technologies are solved. Specifically, hierarchical connection pool management replaces the traditional polling mechanism of connection pools with direct location of available connection pools, avoiding the time-consuming operation of trying all nodes one by one. For example, when the primary node fails, it is unnecessary to try all standby connections; instead, it directly locates the available standby connection pool, significantly shortening fault recovery time. Dynamic status detection: The real-time detection mechanism of the status detection module ensures that the connection pool of the failed node is cleared in a timely manner, preventing invalid connections from consuming memory resources. For example, after a standby node fails, the status detection module immediately clears all physical connections in its connection pool, preventing invalid connections from residing for a long time and reducing memory waste. Fault tolerance and compatibility: During failover, the independent architecture of the connection pool group allows business requests to directly switch to the available connection pool without requiring business-side logical processing, thus achieving transparent fault recovery. For example, when the primary node fails, business requests automatically switch to the standby connection pool without modifying the business code.

[0070] Load status information is a dataset that characterizes the resource usage of a connection pool, including the total number of connections and the number of idle connections. For example, if a connection pool has a total of 10 connections and 2 idle connections, then the load status information is (10, 2).

[0071] Specifically, upon receiving a business request, the system retrieves load status information based on the independent connection pool corresponding to each node; that is, it reads the total number of connections and the number of idle connections for each connection pool from the connection pool group. A target connection pool is dynamically selected based on the load status information for subsequent connection allocation. The processing result is a connection allocation strategy driven by the load status of the connection pool group, optimizing resource utilization.

[0072] Furthermore, the problem of unreasonable resource allocation is solved by using a load-state-driven connection allocation strategy. For example, the connection pool with the lowest load is selected first to avoid overloading individual nodes; and the number of idle connections is optimized to reduce resource waste and improve the overall system performance.

[0073] In one embodiment, such as Figure 2 As shown, the node status information of each node is periodically obtained, including:

[0074] Step 201: Send a detection request to each node according to the preset detection cycle;

[0075] Step 202: Based on the response results of the detection request, determine the availability status of each node, and generate corresponding node status information based on the availability status of each node.

[0076] The detection request is a communication request used to verify the availability of a database node, such as a TCP connection request or a database session establishment request. For example, a detection request could send an empty query to verify whether the database node is responding.

[0077] Availability status is an indicator that represents whether a database node can communicate normally, such as "available" or "unavailable". If a detection request does not receive a response within the timeout period, the node is marked as "unavailable".

[0078] Specifically, a detection request, such as a TCP connection request or an empty query, is sent to each node at a preset period (e.g., every 5 seconds). If the detection request receives a response within the timeout period, such as a successful TCP connection or a returned result for the empty query, the node is marked as "available"; otherwise, it is marked as "unavailable". The judgment result is updated in the node status information for use in subsequent steps.

[0079] The method provided in the above embodiments further improves the real-time performance and accuracy of fault detection through a dynamic detection request and status recording mechanism. For example, by periodically sending detection requests, timely updates of node status information are ensured; and by judging the response results, misjudgments of node status due to network fluctuations are avoided, thereby reducing the possibility of erroneously clearing the connection pool.

[0080] In one embodiment, the method further includes:

[0081] If a target node failure is detected, the availability status of the target node is stored so that all independent connection pools in the connection pool group can obtain the availability status of the target node.

[0082] Shared storage module: A storage unit shared by multiple connection pool modules for synchronizing node status information. This shared storage module can be an in-memory hash table or a distributed cache (such as Redis). After updating node status information, it is written to the shared storage module, especially the status information of failed target nodes, ensuring that all connection pool modules can access the latest status in real time.

[0083] Shared access: When clearing physical connections, the independent connection pool directly reads the availability status of the target node from the shared storage module, avoiding inconsistencies in status information. The processing result is the persistence of node status information in the shared storage module, ensuring the consistency of the connection pool group's status.

[0084] The method provided in the above embodiments further solves the problem of asynchronous state information among multiple connection pool modules by introducing a shared storage module. For example, all independent connection pools can access the latest state information in the shared storage module in real time, avoiding connection pools not being cleared in time due to state delays, thereby improving the system's fault tolerance.

[0085] In one embodiment, the method further includes:

[0086] The recovery time is predicted based on the historical failure modes of the target node, and a physical connection to the backup connection pool corresponding to the target node is established before the recovery time.

[0087] Among them, historical failure modes characterize the statistical regularity of recovery time after a target database node failure. For example, if the average recovery time of standby 2 after standby 1 fails is 5 seconds, then the historical failure mode is (5 seconds, standby 2).

[0088] By analyzing historical failure patterns (such as the average recovery time of standby node 2), the recovery time of the target node is predicted. Before predicting the recovery time, physical connections to the backup connection pool are established in advance to shorten the subsequent recovery time.

[0089] The method provided in the above embodiments further addresses the problem of excessively long fault recovery time through a pre-connection mechanism. For example, based on historical pattern predictions, backup connections are established in advance to reduce connection reconstruction time; to avoid resource waste, pre-connection is triggered only for high-risk nodes, improving resource utilization efficiency.

[0090] In one embodiment, updating the independent connection pool corresponding to each node based on node status information and connection status information includes:

[0091] If the connection status information indicates that there are idle physical connections in the independent connection pool, the idle physical connections in the independent connection pool are reclaimed; the judgment conditions for idle physical connections include a preset idle timeout threshold.

[0092] The idle timeout threshold represents the maximum idle time a physical connection can be reclaimed. If the preset idle timeout threshold is 10 minutes, connections idle for more than 10 minutes will be reclaimed. The physical connections in the connection pool are periodically scanned to check if their idle time exceeds the threshold. If a connection's idle time exceeds the threshold (e.g., 10 minutes), it is removed from the connection pool and its resources are released.

[0093] The method provided in the above embodiments further addresses the resource waste problem through an idle connection recycling mechanism. For example, it periodically cleans up connections that have not been used for a long time to avoid excessive memory resource consumption; and it retains recently active connections to reduce reconstruction overhead and improve system stability.

[0094] In one embodiment, such as Figure 3 As shown, based on the load status information of the new independent connection pool, the target connection pool is determined, including:

[0095] Step 301: Based on the load status information of the new independent connection pools, determine the total number of connections, the number of idle connections, and the connection response time for each independent connection pool.

[0096] Step 302: Determine the target connection pool based on the total number of connections, the number of idle connections, and the connection response time; the preset conditions include the minimum total number of connections, the maximum number of idle connections, and the shortest connection response time.

[0097] Load status information is a data set representing the resource usage of the connection pool, including the total number of connections and the number of idle connections. For example, if a connection pool has a total of 10 connections and 2 idle connections, then the load status information is (10, 2).

[0098] The system reads the total number of connections and the number of idle connections for each connection pool in the connection pool group. It dynamically selects a target connection pool based on load status information for subsequent connection allocation, prioritizing pools with the fewest total connections, the most idle connections, or the shortest response time. The target connection pool is dynamically selected based on at least one metric: total connections, idle connections, or response time. If multiple metrics conflict, such as having the fewest total connections but a longer response time, a decision can be made using weighted or priority rules.

[0099] The method provided in the above embodiments further addresses the limitations of a single metric by employing a multi-dimensional load balancing strategy. For example, by comprehensively considering the total number of connections, the number of idle connections, and response time, resource allocation deviations caused by a single metric are avoided, thereby improving the overall system performance.

[0100] In conjunction with the above embodiments, a failover method for a read-write separation database cluster based on a connection pool group is provided, including:

[0101] Step 1: Connection pool group initialization and node status detection

[0102] The object being processed is the node information of the database cluster (including a list of primary and standby nodes).

[0103] Processing procedure:

[0104] Based on the node information, a connection pool is created independently for each node (master node, backup node), forming a connection pool group.

[0105] Start a node status timer to periodically check the availability of each node (e.g., every 5 seconds). If a node failure is detected, immediately clear all connections in the connection pool corresponding to that node and mark the node as unavailable.

[0106] For example: Suppose the cluster contains 1 primary node and 2 standby nodes. During initialization, 3 connection pools are created (primary connection pool, standby 1 connection pool, and standby 2 connection pool). The node status timer checks every 5 seconds. If standby 1 fails, all connections in standby 1's connection pool are immediately cleared, and standby 1 is marked as unavailable.

[0107] Step 2: Connection Allocation and Load Balancing in Failover

[0108] Processing objects: connection requirements of business requests and the current load status of the connection pool group (total number of connections, number of idle connections).

[0109] Processing procedure:

[0110] When a business request needs to acquire a connection, a target connection pool is selected based on the current load status of the connection pool group. The selection logic is as follows: the connection pool with the lowest load (the connection pool with the fewest total connections) is selected first; if the loads are the same, the connection pool with the most idle connections is selected; if the target connection pool is unavailable (e.g., due to node failure), a new connection pool is selected from the available connection pools.

[0111] In failover scenarios (such as primary failure), if all standby connection pools are unavailable, connections will be temporarily assigned to the primary connection pool (even if the primary is a write node).

[0112] For example: Assume the primary connection pool has a total of 10 connections and 2 idle connections; the backup 1 connection pool has a total of 5 connections and 3 idle connections; and the backup 2 connection pool has a total of 5 connections and 1 idle connection. According to load balancing logic, the backup 1 connection pool is selected first (fewest total connections and most idle connections). If backup 1 fails, the backup 2 connection pool is selected.

[0113] The method provided in the above embodiments significantly improves the performance and reliability of database cluster failover by combining a connection pool group architecture with a dynamic state awareness mechanism.

[0114] Improved fault response efficiency: By implementing hierarchical management of connection pool groups, the time-consuming operation of polling all nodes in traditional connection pools is avoided, significantly shortening fault response time. For example, in the event of a host failure, instead of trying to connect to backup machines one by one, the available connection pool is located directly, enabling rapid recovery.

[0115] Resource utilization optimization: The real-time detection mechanism of the node status timer ensures that the connection pool of the faulty node can be cleared in time to avoid invalid connections occupying memory; at the same time, the dynamic allocation strategy based on the load status (such as prioritizing the connection pool with the lowest load) prevents resource waste or overload.

[0116] Reduced development and maintenance complexity: Business side does not need to implement read / write separation and failover logic on its own. All operations are automatically completed by the connection pool group, which significantly reduces development difficulty and maintenance costs.

[0117] Enhanced fault tolerance and compatibility: For extreme scenarios such as primary / standby switchover and full standby machine failure, fault tolerance logic is designed (such as temporarily using a host connection pool) to ensure business continuity.

[0118] The following is a specific example. Faults during failover mainly include the following four categories: primary machine failure, failure of standby machine 1 if there are multiple standby machines, failure of all standby machines, and primary / standby switchover.

[0119] When the host fails, if the connection pool group has no connections:

[0120] The driver attempts to connect to the primary node but finds it to be faulty. The driver then creates a connection to the backup node, but the backup node also fails. After five attempts, the driver throws an exception. At this point, the cluster is unavailable, and this information is reported to the application side.

[0121] If there are connections in the connection pool: A timer in the connection pool checks the connection status of each node in the cluster every 5 seconds. If a connection anomaly is detected on a node, all physical connections in the connection pool corresponding to that node are cleared, ensuring that that node will not be considered for connection acquisition, saving time spent on connection availability verification. When retrieving a physical connection to a host node from the connection pool, a new connection is created, attempting 5 times. If all 5 attempts fail, a physical connection to a writable standby node is found and returned. This ensures available connections on the business side. The timeframe for ensuring available connections during a failure is as follows:

[0122] ;

[0123] Where 2 indicates that each connection attempt lasts 2 seconds; Indicates whether the event occurred before or after the trigger check; 5 indicates the number of attempts. This indicates that a standby node is randomly selected from the standby connections; 0.01 indicates the time taken to verify the availability of the standby connection.

[0124] If one standby unit fails, and the connection pool group has no connections:

[0125] The cluster status is queried in the connection pool group. If a master node already exists in the cluster, a physical connection to the next standby node is created immediately after a failed attempt to connect to a standby node. If no physical connection to the master node has been created yet, five connection attempts are made, all of which fail. Connections to other standby nodes are then attempted; a successful connection returns the physical connection information for that node. After waiting for a response from the standby node, the trigger creates the physical connection for the standby node and stores it in the standby connection pool for unread nodes. The connection latency calculation formula is as follows:

[0126] Assuming the connection establishment order in the connection pool group uses 0 and 1 to indicate whether there is a host node P in the current connection pool:

[0127] ;

[0128] Where 2 indicates that each connection attempt lasts 2 seconds; 5 indicates the number of attempts. This indicates whether a primary connection exists in the connection pool group when a standby machine is connected. Indicates the number of standby nodes; 0.1 indicates that a standby node is randomly selected from the standby connections; 0.1 indicates the time taken for a normal physical connection.

[0129] If there are connections in the connection pool group, a standby machine failure occurs. The timer, upon detecting this, will clear all connections from the connection pool corresponding to the failed standby machine. When acquiring a connection, this node will no longer be considered. Connections from other standby machines will be obtained directly from the connection pool, with negligible time complexity. The application side is unaware of this.

[0130] When all standby nodes fail, if there are no connections in the connection pool, the cluster status in the connection pool is queried. If a master node already exists in the cluster, a physical connection to the next standby node is created immediately after one failed attempt to connect. If no physical connection to the master node has been created in the cluster, five connection attempts are made. If all five attempts fail, other standby nodes are tried, and if all connections fail, the master node is temporarily used as the read / write node. After the standby nodes recover, the trigger creates a physical connection to the standby node and stores it in the standby connection pool for read node backup. The connection latency calculation formula is as follows:

[0131] Assuming the connection establishment order in the connection pool group uses 0 and 1 to indicate whether there is a host node P in the current connection pool:

[0132] ;

[0133] Where 2 indicates that each connection attempt lasts 2 seconds; 5 indicates the number of attempts. This indicates whether a primary connection exists in the connection pool group when a standby machine is connected. Indicates the number of standby nodes; 0.1 indicates that a standby node is randomly selected from the standby connections; 0.1 indicates the time taken for a normal physical connection.

[0134] If a connection already exists in the connection pool group, and a standby machine failure occurs, the timer will detect this and clear all connections in the connection pool corresponding to the failed standby machine. When acquiring a connection, this node will no longer be considered. Connections from other standby machines will be obtained directly from the connection pool, with negligible time complexity. The application side is unaware of this.

[0135] When a primary / standby switchover occurs, if there are no connections in the connection pool, all nodes will be tried, waiting for the primary / standby machine to complete the switchover. The primary / standby switchover recovers within 10 seconds, ensuring that the service obtains a usable cluster connection after the driver tries all nodes, guaranteeing service recovery.

[0136] If there are connections in the connection pool, after the timer detects a primary / standby switch in the cluster, it will clear all connections in the connection pools corresponding to the two switched nodes. Once the primary / standby switch is complete, it will return available connections and then send the business operations to the database. The time consumption is the same as in a scenario where there are no connections in the connection pool. If there are other standby machines, when a business query occurs, the query operation can be performed using the connection of the normal standby machine. If the read / write separation database implements authorized dual writes, it can operate normally on the normal standby machine, with negligible time consumption, and the business-side sending function can be executed directly.

[0137] In one embodiment, an adaptive detection interval mechanism is introduced into the node state timer to dynamically adjust the detection cycle based on the node's historical failure frequency. For example, for nodes that are stable for a long period (e.g., no failures for 30 consecutive days), the detection interval is extended to 10 seconds; while for nodes with frequent failures (e.g., multiple failures within 1 hour), the detection interval is shortened to 1 second. The adjustment of the detection interval is achieved through a machine learning model, which takes as input the node's historical state data (e.g., number of failures, recovery time) and outputs the optimal detection cycle.

[0138] By dynamically adjusting the detection interval, the number of invalid detections (such as low-frequency detection of stable nodes) and the latency of emergency detections (such as high-frequency detection of faulty nodes) are reduced, thereby lowering system resource consumption (such as CPU and network load) and improving the real-time performance of fault detection. For example, low-frequency detection of stable nodes avoids resource waste, while high-frequency detection of faulty nodes can quickly isolate problems and reduce service interruption time.

[0139] In one embodiment, a multi-dimensional load balancing strategy is introduced into the connection allocation logic, comprehensively considering the number of idle connections, total connections, historical response time, and node performance metrics (such as CPU utilization and memory usage) of the connection pool. For example, the connection pool with the most idle connections and the shortest historical response time is given priority. If multiple connection pools meet the conditions, the CPU utilization of the nodes is further compared, and the node with the lower load is selected.

[0140] By introducing multi-dimensional metrics, the limitations of a single metric (such as the number of idle connections) can be avoided, thus enabling more precise connection allocation. For example, when the number of idle connections is the same, selecting a connection pool with a shorter response time can reduce the waiting time for business requests; and combining node performance metrics can prevent connections from being allocated to resource-constrained nodes, thereby improving overall system stability.

[0141] In one embodiment, a priority queue mechanism is introduced into the connection allocation logic. The connection allocation strategy is dynamically adjusted based on the priority of business requests, such as financial transaction requests having a higher priority than ordinary query requests. For example, high-priority requests preferentially obtain connections from the connection pool with the lowest load, while low-priority requests use the default load balancing strategy. Priority information is transmitted through the metadata of the business request, such as the request type identifier, and is parsed in real time by the scheduling module of the connection pool group.

[0142] Priority queuing mechanisms ensure the real-time requirements of critical business operations. For example, in high-concurrency scenarios, financial transaction requests can prioritize acquiring available connections, avoiding transaction delays caused by connection resource contention; while ordinary query requests have a higher latency tolerance and can be scheduled using default strategies, thereby achieving differentiated resource allocation and optimization of overall system efficiency.

[0143] In one embodiment, a dynamic capacity adjustment mechanism is introduced into the connection pool group to automatically adjust the capacity (e.g., maximum number of connections) of the connection pool based on real-time business load (e.g., number of connection requests, average response time). For example, when the number of connection requests exceeds a threshold and the average response time increases, the capacity of the connection pool is dynamically expanded; when the number of requests decreases and the proportion of idle connections is too high, the capacity of the connection pool is shrunk to release resources. The capacity adjustment decision is predicted by the monitoring module in conjunction with historical load trends.

[0144] By dynamically adjusting the connection pool capacity, resource over-allocation (such as insufficient connections under high load) or resource idleness (such as excessive connections under low load) can be avoided. For example, expanding the connection pool during peak business periods can reduce connection waiting time, while shrinking the connection pool during off-peak business periods can reduce memory usage, thereby improving resource utilization and reducing operation and maintenance costs.

[0145] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0146] Based on the same inventive concept, this application also provides a failover device for a read-write separation database cluster. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more failover device embodiments for read-write separation database clusters provided below can be found in the limitations of the failover method for read-write separation database clusters described above, and will not be repeated here.

[0147] In one embodiment, such as Figure 4 As shown, the failover device for a read / write split database cluster includes a creation module 401, a detection module 402, a detection module 403, and a filtering module 404, wherein:

[0148] The creation module 401 is used to create a connection pool group based on the node information of multiple nodes. The connection pool group includes multiple independent connection pools, and each independent connection pool corresponds to one node.

[0149] The detection module 402 is used to periodically obtain the node status information of each node and the connection status information of the physical connections in each independent connection pool.

[0150] The update module 403 is used to update the independent connection pool corresponding to each node based on the node status information and connection status information.

[0151] The filtering module 404 is used to determine the target connection pool based on the load status information of the new independent connection pool when a target node failure is detected. The target connection pool is used to respond to business requests.

[0152] In one possible implementation, the detection module 402 is specifically used for:

[0153] Send a detection request to each node according to the preset detection cycle;

[0154] Based on the response to the detection request, determine the availability status of each node, and generate corresponding node status information based on the availability status of each node.

[0155] In one possible implementation, the detection module 402 is specifically used for:

[0156] If a target node failure is detected, the availability status of the target node is stored so that all independent connection pools in the connection pool group can obtain the availability status of the target node.

[0157] In one possible implementation, update module 403 is specifically used for:

[0158] If the node status information indicates that the target node is faulty, clear all physical connections in the independent connection pool corresponding to the target node.

[0159] In one possible implementation, update module 403 is specifically used for:

[0160] The recovery time is predicted based on the historical failure modes of the target node, and a physical connection to the backup connection pool corresponding to the target node is established before the recovery time.

[0161] In one possible implementation, update module 403 is specifically used for:

[0162] If the connection status information indicates that there are idle physical connections in the independent connection pool, the idle physical connections in the independent connection pool are reclaimed; the judgment conditions for idle physical connections include a preset idle timeout threshold.

[0163] In one possible implementation, the filtering module 404 is specifically used for:

[0164] Based on the load status information of the new independent connection pools, determine the total number of connections, the number of idle connections, and the connection response time for each independent connection pool;

[0165] The target connection pool is determined based on the total number of connections, the number of idle connections, and the connection response time. The preset conditions include the minimum total number of connections, the maximum number of idle connections, and the shortest connection response time.

[0166] The various modules in the failover device of the aforementioned read-write separation database cluster can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0167] Figure 5 A schematic diagram of the structure of the computer device provided in this application. Figure 5 As shown, the computer device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0168] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0169] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0170] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0171] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0172] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0173] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0174] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0175] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0176] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0177] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0179] In addition, 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.

[0180] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a 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 of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0181] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0182] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A failover method for a read-write split database cluster, characterized in that, The database cluster comprises multiple nodes; the method includes: A connection pool group is created based on the node information of the multiple nodes. The connection pool group includes multiple independent connection pools, and each independent connection pool corresponds to one node. Periodically obtain the node status information of each node and the connection status information of the physical connections in each independent connection pool; Update the independent connection pool corresponding to each node based on the node status information and the connection status information; If a target node failure is detected, a target connection pool is determined based on the load status information of the new independent connection pool. This target connection pool is used to respond to service requests.

2. The method according to claim 1, characterized in that, The periodic acquisition of node status information for each node includes: Send a detection request to each node according to the preset detection cycle; Based on the response to the detection request, the availability status of each node is determined, and corresponding node status information is generated based on the availability status of each node.

3. The method according to claim 2, characterized in that, The method further includes: If a target node failure is detected, the availability status of the target node is stored so that all independent connection pools in the connection pool group can obtain the availability status of the target node.

4. The method according to claim 1, characterized in that, The step of updating the independent connection pool corresponding to each node based on the node status information and the connection status information includes: If the node status information indicates a target node failure, clear all physical connections in the independent connection pool corresponding to the target node.

5. The method according to claim 4, characterized in that, The method further includes: The recovery time is predicted based on the historical failure modes of the target node, and a physical connection to the backup connection pool corresponding to the target node is established before the recovery time.

6. The method according to claim 1, characterized in that, The step of updating the independent connection pool corresponding to each node based on the node status information and the connection status information includes: If the connection status information indicates that there are idle physical connections in an independent connection pool, the idle physical connections in the independent connection pool are reclaimed; the criteria for determining the idle physical connections include a preset idle timeout threshold.

7. The method according to claim 1, characterized in that, The step of determining the target connection pool based on the load status information of the new independent connection pool includes: Based on the load status information of the new independent connection pools, determine the total number of connections, the number of idle connections, and the connection response time for each independent connection pool; A target connection pool with preset conditions is determined based on the total number of connections, the number of idle connections, and the connection response time; the preset conditions include the minimum total number of connections, the maximum number of idle connections, and the shortest connection response time.

8. A failover device for a read-write split database cluster, characterized in that, The database cluster includes multiple nodes; the device includes: A creation module is used to create a connection pool group based on the node information of the multiple nodes. The connection pool group includes multiple independent connection pools, and each independent connection pool corresponds to one node. The detection module is used to periodically obtain the node status information of each node and the connection status information of the physical connections in each independent connection pool. The update module is used to update the independent connection pool corresponding to each node based on the node status information and the connection status information. The filtering module is used to determine the target connection pool based on the load status information of the new independent connection pool when a target node failure is detected. The target connection pool is used to respond to service requests.

9. A computer device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

Images