Database node switching method, electronic equipment and readable storage medium

Abstract

The invention relates to the technical field of databases, and provides a node switching method of a database. According to the method provided by the embodiment of the invention, the physical connection pool is created for the main node in advance, and the physical connection pool is created for the standby node in advance. According to the invention, after disaster recovery switching is carried out on the database disaster recovery networking, that is, after the original main node is inverted into the standby node and the original standby node is inverted into the new main node, the client can be connected with the database of the new main node through the physical connection pool of the main node, and the physical connection pool does not need to be created for the new main node again. In this way, the database service can be quickly recovered after disaster recovery switching is carried out on the database disaster recovery networking, and the fault recovery speed is increased.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a database node switching method, an electronic device, and a readable storage medium. Background Art

[0002] In order to improve the disaster recovery capability of the database disaster recovery network, Figure 1 As shown, the database disaster recovery network includes a master node and at least one standby node. Among them, the node is a database server or a database server cluster. The master node can synchronize data to the standby node in real time, so that the data of the standby node is consistent with that of the master node. When there is no abnormality in the master node, the database of the master node provides database services to the client. When an abnormality occurs in the master node, the database disaster recovery network can perform disaster recovery switching (or "master-standby node switching") processing, switching the master node to the standby node, and switching any standby node in the database disaster recovery network to the master node. Then the database of the new master node provides database services to the client to avoid termination of database services.

[0003] like Figure 1 As shown, the database of the master node can provide database services for multiple clients, and each client can connect to the database of the master node through a physical connection (or "database connection") in the physical connection pool (or "database connection pool") of the master node. The physical connection pool of the master node is created in advance, and the physical connection pool includes at least one physical connection. The physical connection can be understood as a network link for connecting the database and the client. Since the standby node is in a standby state, the physical connection pool of the standby node is not created in advance in the prior art. In this case, Figure 2 As shown in the figure, when an exception occurs in the master node, the original master node is switched to the standby node, and the original standby node is switched to the new master node, a physical connection pool needs to be recreated for the new master node so that the client can connect to the database of the new master node through the physical connection in the recreated physical connection pool. In the process of creating the physical connection pool, the client needs to wait for the corresponding physical connection to be created before it can resume access to the database, resulting in the database disaster recovery network being unable to quickly restore the database service to the client after the disaster recovery switch, reducing the fault recovery speed of the database disaster recovery network. Summary of the invention

[0004] Some embodiments of the present application provide a database node switching method, an electronic device, and a readable storage medium. The present application is introduced from multiple aspects below, and the implementation methods and beneficial effects of the following aspects can be referenced to each other.

[0005] In a first aspect, the present application provides a database node switching method, wherein the database is stored in multiple nodes, wherein a first node among the multiple nodes provides database services to a client through a first physical connection pool corresponding to the first node; the method includes: determining that the first node does not meet operating conditions; obtaining physical connection pool information of a second node among the multiple nodes; and replacing the first node with a second node based on the physical connection pool information of the second node, wherein the second node provides database services to the client through a second physical connection pool corresponding to the second node.

[0006] Wherein, the first node may be the master node mentioned in this application. The second node may be the standby node mentioned in this application. The physical connection pool information includes the Internet Protocol (IP) address of the node. The first physical connection pool may be the physical connection pool corresponding to the master node. The client may be an application, such as a Java application. Wherein, the second physical connection pool may be the physical connection pool corresponding to the standby node.

[0007] For example, a database disaster recovery network includes a master node and N standby nodes, each node includes a database, and the data of each node is kept consistent, and the master node can synchronize its own data to each standby node in real time, so that the data of the master and standby nodes are consistent. Among them, each node corresponds to a physical connection pool, for example, the master node corresponds to physical connection pool 1, standby node 1 corresponds to physical connection pool 2, ..., standby node N corresponds to physical connection pool N-1. The master node can provide database services to clients (for example, client 1, client 2, client 3, ..., client N) through the physical connection in physical connection pool 1. In other words, the physical connection pool includes physical connections, and the client can connect to the database of the corresponding node through the physical connection in the physical connection pool, so that the client can access the database of the node.

[0008] When the client is connected to the database of the first node through the first physical connection pool of the first node, the client can perform anomaly detection on the first node in real time. When the client detects that the first node is abnormal, it is determined that the first node does not meet the operating conditions. For example, the client can perform anomaly detection on the first node through the Java database connection (java dataBaseconnectivity) JDBC driver, and when it is detected that the network communication of the first node is abnormal or the first node is down, it can be determined that the first node does not meet the operating conditions.

[0009] The management system of the database disaster recovery network may also perform an abnormality detection on the first node and provide the detection result to the client. When the detection result indicates that the first node is abnormal, it can be determined that the first node does not meet the operating conditions.

[0010] When the first node does not meet the operating conditions, the client may obtain physical connection pool information of a second node among the multiple nodes, and replace the first node with the second node through the physical connection pool information.

[0011] After the client determines that the first node does not meet the operating conditions and obtains the physical connection pool information of the second node, the client can disconnect from the database of the first node, and determine the second physical connection pool corresponding to the second node based on the physical connection pool information of the second node, and then connect to the database of the second node through the physical connection in the second physical connection pool.

[0012] For example, when the master node of the database disaster recovery network is abnormal, the client disconnects from the database of the master node and obtains the IP address of the standby node 1. Then, based on the IP address, the physical connection pool 2 corresponding to the standby node is determined, and the database of the standby node 1 is connected through the physical connection in the physical connection pool 2.

[0013] It should be noted that in the embodiment of the present application, each node corresponds to a physical connection pool, and each physical connection pool is pre-created.

[0014] In the embodiment of the present application, since the physical connection pool of each node is pre-created, when the first node providing database services to the client through the first physical connection pool does not meet the operating conditions, it can directly switch to the second node to provide database services to the client through the second physical connection pool. There is no need to wait for the creation of the physical connection pool, which shortens the switching time of the database node, thereby shortening the recovery time of the database service, improving the speed of database service recovery, and improving the speed of fault recovery.

[0015] In some implementations, obtaining physical connection pool information of a second node among multiple nodes includes: obtaining a first table including physical connection pool information of multiple nodes; and querying the physical connection pool information of the second node in the first table.

[0016] The first table may be the node list mentioned in this application, wherein the node list includes the IP address of each node.

[0017] After the client obtains the node list, it can obtain the IP address of the standby node from the node list.

[0018] In some embodiments, querying the physical connection pool information of the second node in the first table includes: querying the first tag information in the first table, wherein the first tag information represents providing database services for the client; and obtaining the physical connection pool information of the second node from the candidate physical connection pool information in the first table based on the first tag information.

[0019] Among them, the first marking information can be the main identification (such as master) in the main and backup role information (role) mentioned in this application. Each main and backup role information corresponds to an IP address. When the main and backup role information of the node is the main identification (such as master), it means that the node is the main node and the node provides database services to the client. When the main and backup role information of the node is the backup identification (such as slave), it means that the node is a backup node and does not provide database services to the client.

[0020] In a specific implementation, after the client obtains the node list, it can query the primary identifier in the node list, and then obtain the physical connection pool information corresponding to the primary identifier to obtain the physical connection pool information of the standby node.

[0021] In some implementations, determining that the first node does not meet the operating conditions includes: performing anomaly detection on the first node; and determining that the first node does not meet the operating conditions when detecting that the communication connection of the first node is abnormal or the first node is down.

[0022] In a specific implementation, the client may perform anomaly detection on the first node through a JDBC driver, and determine that the first node does not meet the operating conditions when detecting that the communication connection of the first node is abnormal or the first node is down.

[0023] In a second aspect, the present application provides a node switching method for a database, wherein the database is stored in multiple nodes, wherein a first node among the multiple nodes provides database services to a client through a logical connection pool bound to a first physical connection pool corresponding to the first node; the method includes: determining that the first node does not meet the operating conditions, and unbinding the logical connection pool from the first physical connection pool; obtaining physical connection pool information of a second node among the multiple nodes; and based on the physical connection pool information of the second node, binding the logical connection pool to a second physical connection pool corresponding to the second node to replace the first node with the second node, wherein the second node provides database services to the client through the logical connection pool bound to the second physical connection pool.

[0024] The first node may be the master node mentioned in the present application. The second node may be the standby node mentioned in the present application. The physical connection pool information includes the IP address of the node. The first physical connection pool may be the physical connection pool corresponding to the master node. The client may be an application, such as a Java application. The second physical connection pool may be the physical connection pool corresponding to the standby node.

[0025] For example, a database disaster recovery network includes a master node and N standby nodes, each node includes a database, and the database of each node is kept consistent, and the master node can synchronize its own data to each standby node in real time, so that the data of the master and standby nodes are consistent. Among them, each node corresponds to a physical connection pool, for example, the master node corresponds to physical connection pool 1, standby node 1 corresponds to physical connection pool 2, ..., standby node N corresponds to physical connection pool N-1. The master node can provide database services to clients (for example, client 1, client 2, client 3, ..., client N) through the logical connection in the logical connection pool bound to the physical connection pool 1. Among them, the logical connection in the logical connection pool encapsulates the physical connection in the physical connection pool 1 bound to it, so the client can connect to the database of the master node through the logical connection in the logical connection pool.

[0026] When the client is connected to the database of the first node through the first physical connection pool of the first node, the client can perform anomaly detection on the first node in real time. When the client detects that the first node is abnormal, it is determined that the first node does not meet the operating conditions. For example, the client can perform anomaly detection on the first node through the JDBC driver, and when it is detected that the network communication of the first node is abnormal or the first node is down, it can be determined that the first node does not meet the operating conditions.

[0027] The management system of the database disaster recovery network may also perform an abnormality detection on the first node and provide the detection result to the client. When the detection result indicates that the first node is abnormal, it can be determined that the first node does not meet the operating conditions.

[0028] When the first node does not meet the operating conditions, the client can obtain the physical connection pool information of the second node among the multiple nodes, and based on the physical connection pool information of the second node, unbind the logical connection pool from the first physical connection pool, and bind the logical connection pool to the second physical connection pool corresponding to the second node to replace the first node with the second node.

[0029] For example, when the client determines that the master node (as the first node) does not meet the operating conditions, the IP address of the standby node 1 (as the second node) can be obtained to replace the master node with the standby node 1 through the IP address of the standby node.

[0030] After the client determines that the first node does not meet the operating conditions and obtains the physical connection pool information of the second node, the client can unbind the logical connection pool from the physical connection pool of the first node, so that the client is disconnected from the physical connection pool of the first node, and then bind the logical connection pool to the logical connection pool of the second node, so that the client is connected to the physical connection pool of the second node, and the second node provides database services for the client.

[0031] For example, when the master node of the database disaster recovery network is abnormal, the client unbinds the logical connection pool from the physical connection pool 1 corresponding to the master node (as the first node), and then binds the logical connection pool to the physical connection pool of the standby node (as the second node), so that the client switches from the master node to the standby node.

[0032] In the embodiment of the present application, since the physical connection pool and the logical connection pool of each node are pre-created, when the first node providing database services to the client does not meet the operating conditions, the logical connection pool can be directly unbound from the first physical connection pool, and the logical connection pool can be bound to the second physical connection pool to replace the first node with the second node. There is no need to recreate the physical connection pool, which shortens the switching time of the database node, thereby shortening the recovery time of the database service, improving the speed of database service recovery, and improving the speed of fault recovery.

[0033] In some implementations, unbinding the logical connection pool from the first physical connection pool includes: releasing the mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the first node, so that the logical connection pool is unbound from the physical connection pool of the first node.

[0034] The logical connection pool information includes a virtual internet protocol (VIP).

[0035] It can be understood that when the first node provides database services for the client, a mapping relationship is established between the logical connection pool information of the logical connection pool and the physical connection pool information of the first node, so that the logical connection pool is bound to the physical connection pool of the first node. When the first node does not meet the operating conditions, the client can release the mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the first node, so that the logical connection pool is unbound from the physical connection pool of the first node.

[0036] For example, when the master node (as the first node) does not meet the operating conditions, the client can release the mapping relationship between the VIP address provided by the logical connection pool and the IP address of the master node, so that the logical connection pool is unbound from the physical connection pool of the master node.

[0037] In some embodiments, based on the physical connection pool information of the second node, the logical connection pool is bound to the second physical connection pool corresponding to the second node, including: establishing a mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the second node, so that the logical connection pool is bound to the physical connection pool of the second node.

[0038] After the client obtains the physical connection pool information of the second node, the client can establish a mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the second node, so that the logical connection pool is bound to the physical connection pool of the second node to switch the first node to the second node.

[0039] For example, after the logical connection pool is unbound from the physical connection pool 1 corresponding to the primary node, the client can establish a mapping relationship between the VIP address provided by the logical connection pool and the IP address of the standby node 1, so that the logical connection pool is bound to the physical connection pool 2 of the standby node. After the logical connection pool is bound to the physical connection pool 2 of the standby node, the standby node can provide database services to the client through the logical connection pool bound to the physical connection pool 2.

[0040] In some implementations, obtaining physical connection pool information of a second node among multiple nodes includes: obtaining a first table including physical connection pool information of multiple nodes; and querying the physical connection pool information of the second node in the first table.

[0041] The first table may be the node list mentioned in this application, wherein the node list includes the IP address of each node.

[0042] After the client obtains the node list, it can obtain the IP address of the standby node from the node list.

[0043] In some embodiments, querying the physical connection pool information of the second node in the first table includes: querying the first tag information in the first table, wherein the first tag information represents providing database services for the client; and obtaining the physical connection pool information of the second node from the candidate physical connection pool information in the first table based on the first tag information.

[0044] Among them, the first marking information can be the main identification (such as master) in the main and backup role information (role) mentioned in this application. Each main and backup role information corresponds to an IP address. When the main and backup role information of the node is the main identification (such as master), it means that the node is the main node and the node provides database services to the client. When the main and backup role information of the node is the backup identification (such as slave), it means that the node is a backup node and does not provide database services to the client.

[0045] In a specific implementation, after the client obtains the node list, it can query the primary identifier in the node list, and then obtain the physical connection pool information corresponding to the primary identifier to obtain the physical connection pool information of the standby node.

[0046] In some implementations, determining that the first node does not meet the operating conditions includes: performing anomaly detection on the first node; and determining that the first node does not meet the operating conditions when detecting that the communication connection of the first node is abnormal or the first node is down.

[0047] In a specific implementation, the client may perform anomaly detection on the first node through a JDBC driver, and determine that the first node does not meet the operating conditions when detecting that the communication connection of the first node is abnormal or the first node is down.

[0048] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a memory for storing instructions executed by one or more processors of the electronic device; and a processor, when the processor executes the instructions in the memory, the electronic device can execute the method described in any embodiment of the first aspect of the present application. The beneficial effects that can be achieved in the third aspect can refer to the beneficial effects of the method provided in any embodiment of the first aspect, and will not be repeated here.

[0049] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which instructions are stored, and when the instructions are executed on a computer, the computer can execute the method described in any of the embodiments of the first aspect or the second aspect. The beneficial effects that can be achieved in the fourth aspect can refer to the beneficial effects of the method provided in any of the embodiments of the first aspect or the second aspect, and will not be repeated here.

[0050] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program / instruction, which, when executed, causes a computer to execute the method described in any embodiment of the first aspect. The beneficial effects that can be achieved in the fifth aspect can refer to the beneficial effects of the method provided in any embodiment of the first aspect or the second aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 An example of a connection between a client and a database node provided in an embodiment of the present application Figure 1 ;

[0052] Figure 2 An example of client switching database node connection pool provided in the embodiment of the present application Figure 1 ;

[0053] Figure 3 An example of a connection between a client and a database node provided in an embodiment of the present application Figure 2 ;

[0054] Figure 4 An example of client switching database node connection pool provided in the embodiment of the present application Figure 2 ;

[0055] Figure 5 Provides an example of the connection between the client and the database node for the embodiment of the present application Figure 3 ;

[0056] Figure 6 An example of client switching database node connection pool provided in the embodiment of the present application Figure 3 ;

[0057] Figure 7 An example diagram of the connection between the application and the database node provided in the embodiment of the present application;

[0058] Figure 8 An example diagram of an application switching database node connection provided in an embodiment of the present application;

[0059] Fig. 9 An example diagram of the connection redirection process provided in an embodiment of the present application;

[0060] Fig. 10A An example of a process for switching a database node provided in an embodiment of the present application Figure 1 ;

[0061] Fig. 10B An example flow chart of a method for switching the master and standby nodes of a database provided in an embodiment of the present application;

[0062] Fig.11 An example diagram of binding a logical connection pool to a physical connection pool of a master node provided in an embodiment of the present application;

[0063] Fig.12 An example diagram of a logical connection pool provided in an embodiment of the present application switching to be bound to a physical connection pool of a standby node;

[0064] Fig.13 A schematic diagram of the principle of quickly restoring database connections after disaster recovery switching in the database disaster recovery network provided in an embodiment of the present application;

[0065] Fig.14A An example of a process for switching a database node provided in an embodiment of the present application Figure 2 ;

[0066] Fig. 14B An example flow chart of a method for implementing fast node switching by pre-establishing a logical connection pool and a physical connection pool provided in an embodiment of the present application;

[0067] Fig.15 A schematic diagram showing the principle of switching and binding a physical connection pool to a logical connection pool according to an embodiment of the present application;

[0068] Fig.16An example diagram of a process for an application program to access a database of a master node provided in an embodiment of the application;

[0069] Fig.17 An example diagram of the process of abnormal switching of a database node provided in an embodiment of the present application;

[0070] Fig.18 A business recovery sequence diagram of a database disaster recovery network when a physical connection pool is pre-created in an embodiment of the present application;

[0071] Fig.19 A business recovery sequence diagram of a database disaster recovery network when a physical connection pool is not pre-created provided in an embodiment of the present application;

[0072] Fig. 20 A block diagram of an electronic device provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0073] The embodiment of the present application is used to provide a database node switching method. The method provided by the present application allows the client to directly re-access the database by switching the physical connection pool after the database disaster recovery network switches the master node due to the abnormality of the master node, without the need to re-create the physical connection pool, thereby improving the speed of restoring data access in the database disaster recovery network.

[0074] As mentioned above, after the database disaster recovery network performs disaster recovery switching, there is a problem that the database disaster recovery network cannot quickly restore the database service and the fault recovery speed is slow. In order to solve this technical problem, the method of the embodiment of the present application not only creates a physical connection pool for the master node in advance, but also creates a physical connection pool for the standby node in advance. After the database disaster recovery network performs disaster recovery switching, that is, the original master node is switched to the standby node, and the original standby node is switched to the new master node, the client can connect to the database of the new master node through the physical connection pool of the master node, without having to re-create a physical connection pool for the new master node. In this way, the database disaster recovery network can quickly restore the database service after the disaster recovery switching, thereby improving the speed of fault recovery.

[0075] For example, Figure 3 As shown, the physical connection pool of each node in the database disaster recovery network can be created in advance. The physical connection pool of each node corresponds to the IP address of the node. For example, the IP address of the master node corresponds to physical connection pool 1, the IP address of the backup node 1 corresponds to physical connection pool 2, ..., the IP address of the backup node N corresponds to physical connection pool N-1. When there is no abnormality in the master node in the database disaster recovery network, client 1, client 2, client 3, ..., client N are all connected to the database of the master node through physical connection pool 1. After the master and backup nodes are switched in the database disaster recovery network, the client can switch the physical connection pool based on the IP address of the node. As shown Figure 4 As shown, when the master node in the database disaster recovery network is abnormal, the database disaster recovery network switches the original master node to the standby node, and after the standby node 1 is switched to the new master node, client 1, client 2, client 3, ..., client N can switch to physical connection pool 2 based on the IP address of the new master node to connect to the database of the new master node.

[0076] In order to achieve fast switching of the physical connection pool, in addition to pre-creating a corresponding physical connection pool for each node in the database disaster recovery network, a logical connection pool can also be created to achieve fast switching of the physical connection pool through the logical connection pool. Among them, the logical connection pool includes at least one logical connection, and each logical connection corresponds to a VIP address. The VIP address is an IP address of an unassigned real host (node) and can point to the IP addresses of different nodes, so that the logical connection pool is bound to the corresponding physical connection pool. For example, when the VIP address corresponding to the logical connection in the logical connection pool points to the IP address of the master node, the logical connection pool is bound to the physical connection pool of the master node.

[0077] For example, Figure 5 As shown in the figure, when the master node in the database disaster recovery network does not have any abnormality, clients 1, 2, 3, ..., and N are all connected to the logical connection pool, and the logical connection pool is bound to the physical connection pool 1, so that clients 1, 2, 3, ..., and N are connected to the database of the master node. Figure 6 As shown, when the master node in the database disaster recovery network is abnormal, the database disaster recovery network switches the original master node to the standby node. After the standby node 1 is switched to the new master node, the logical connection pool can be unbound from the physical connection pool 1 and then bound to the physical connection pool 2, so that client 1, client 2, client 3, ..., client N are connected to the database of the new master node.

[0078] In this way, after the active and standby nodes are switched, there is no need for clients to switch physical connection pools one by one. Only the binding of the logical connection pool switch and the physical connection pool is required to implement the physical connection pool switching of all clients. This is simple and efficient, and improves the switching speed.

[0079] It is understandable that in the above Figure 1 and Figure 2 In the solution shown, after the backup node of the database disaster recovery network is switched to the new primary node, if multiple clients access the new primary node at the same time, that is, in a high-concurrency scenario, the database disaster recovery network needs to create a large number of physical connections in a short period of time, which will increase the CPU load of the new primary node and may even cause CPU overload, increasing the risk of downtime of the new primary node. Figure 3 and Figure 4 as well as Figure 5 and Figure 6 In the scheme shown, since the physical connection pool of the new master node is pre-created, the physical connection pool includes a large number of physical connections. In a high-concurrency scenario, the client can directly access the new master node through the pre-created physical connection without re-creating a large number of physical connections, thereby avoiding the CPU overload of the new master node in a high-concurrency scenario and reducing the risk of downtime of the new master node.

[0080] For ease of understanding, in the above-mentioned implementation of database node switching by pre-creating physical pool connections (i.e. Figure 3 and Figure 4 Before introducing the technical solution of the present invention, the principle of database node switching is first explained.

[0081] In the embodiment of the present application, the client may be an application, such as an Ava application.

[0082] In some embodiments, Figure 7 As shown in the figure, the application can connect to the database of the master node through the physical connection created by the JDBC driver. The JDBC driver supports exception handling for database node connections. Figure 8 As shown in the figure, when the primary node fails, the JDBC driver can automatically redirect (reconnect) the physical connection to the standby node. Redirection refers to redirecting the network request to another location, that is, controlling the application to access other nodes.

[0083] Specifically, when the JDBC driver determines that the application is disconnected from the primary node, the primary node is switched to the standby node, and the standby node is switched to the new primary node. At this time, the JDBC driver can destroy the physical connection between the application and the primary node, and recreate the physical connection of the standby node, so that the application can access the database of the standby node through the recreated physical connection.

[0084] In some embodiments, the JDBC driver can use the VIP mechanism to switch the primary and standby nodes, that is, switch the primary node to the standby node, and the standby node to the primary node. For example, the JDBC driver can provide a VIP address for the application, such as 172.168.1.1. Assuming that the IP address of the primary node is 192.168.1.2 and the IP address of the standby node is 192.168.1.3, Figure 7 As shown in the figure, when the application program requests to connect to the master node, the VIP address 172.168.1.1 is bound to the IP address 192.168.1.2 of the master node, so that the application program is connected to the master node. Figure 8As shown, when the application requests to switch to the connection with the standby node, the VIP address 172.168.1.1 is bound to the IP address 192.168.1.3 of the standby node, so that the application switches to the connection with the standby node.

[0085] The following describes the connection redirection process.

[0086] Fig. 9 An example diagram of the connection redirection process provided in an embodiment of the present application.

[0087] like Fig. 9 As shown, the connection redirection process includes the following steps:

[0088] S110: The JDBC driver detects that an exception occurs when the application accesses the database of the primary node.

[0089] In some embodiments, Figure 7 As shown, after the application is connected to the master node, a standard database programming language (structured query language, SQL) instruction can be sent to the database of the master node to access the database of the master node through the SQL instruction, for example, to add, delete, modify, and query the data in the database of the master node. In the case that the application can normally access the database of the master node, the database of the master node can return the execution result of the SQL instruction to the JDBC driver of the application. When the JDBC driver does not receive the execution result returned by the database of the master node, it can be determined that the application's access to the database of the master node is abnormal, that is, the application cannot access the database of the master node.

[0090] S120: The JDBC driver determines whether the network communication is abnormal. If not, execute step S130. If yes, execute step S140.

[0091] When the JDBC driver determines that an exception occurs when the application accesses the database of the master node, it can determine whether the exception is a network communication exception, that is, whether the network communication connection between the application and the master node is abnormal. If not, step S130 is executed. If yes, step S140 is executed.

[0092] S130: The JDBC driver determines whether it is a SQL exception and the error code starts with "08". If so, execute step S140. If not, execute step S150.

[0093] Among them, SQL exceptions and error codes starting with "08" indicate that the master node is abnormal, such as the master node is down.

[0094] When the JDBC driver determines that there is no exception in the network communication between the application and the master node, it can be determined whether the exception is a SQL exception and the error code starts with "08", that is, whether the exception is a master node exception.

[0095] S140: The JDBC driver destroys the physical connection of the primary node and creates a physical connection of the standby node.

[0096] When the JDBC driver determines that the network communication between the application and the master node is abnormal, or when the JDBC driver determines that the network communication between the application and the master node is normal, but determines that the master node is abnormal, such as Figure 8 As shown in the figure, the JDBC driver can destroy the physical connection of the primary node and create a physical connection of the standby node. After the JDBC driver creates the physical connection of the standby node, the application can switch to the standby node through the physical connection of the standby node. After the application switches to the standby node, it can access the database of the standby node normally, and access the database of the standby node normally to avoid interrupting the database service of the application.

[0097] S150: The JDBC driver does not process this, and the decision is made by the application layer.

[0098] When the JDBC driver determines that there is no abnormality in the network communication between the application and the host node, and there is no abnormality in the primary node, the JDBC driver does not do anything. In this case, it may be an SQL request abnormality, such as the SQL request does not meet the database request requirements, or other types of abnormalities. At this time, the application layer (such as the application) can decide the exception handling method and make corresponding processing, such as the application re-sends the SQL request that meets the database requirements to the database of the primary node.

[0099] According to the above embodiments, when the JDBC driver determines that a communication anomaly occurs between the application and the primary node, or determines that an anomaly occurs in the primary node, the application can switch to connect to the database of the standby node, that is, redirect to the standby node, so that the application's data access anomaly can be avoided. However, before the application switches from the primary node to connect to the standby node, it is necessary to create a physical connection pool of the standby node to connect to the database of the standby node through the physical connection pool of the primary node. In the process of creating the physical connection pool, the application needs to wait, which slows down the speed of restoring the database connection of the application.

[0100] Based on this, an embodiment of the present application provides a database node switching method. The method can create a physical connection pool for each node in advance, so that when the primary and standby nodes are switched, the application can directly use the already created physical connection pool to connect to the database of the new primary node without creating a physical connection pool for the new primary node. In this way, the switching speed of the database node can be improved.

[0101] Fig. 10A An example of a process for switching a database node provided in an embodiment of the present application Figure 1 .

[0102] refer to Fig. 10A , the node switching method of the database includes the following steps:

[0103] S101: The client determines that the first node does not meet the operating conditions.

[0104] In an embodiment of the present application, a database can be stored in multiple nodes, and the database of each node remains consistent. The first node among the multiple nodes provides database services to the client through the first physical connection pool corresponding to the first node. The first node can be a master node, and the first physical connection pool can be a physical connection pool corresponding to the master node. The client can be an application, such as a Java application.

[0105] For example, Figure 3 As shown, the database disaster recovery network includes a master node and N standby nodes, each node includes a database, and the database of each node is kept consistent, and the master node can synchronize its own data to each standby node in real time, so that the data of the master and standby nodes are consistent. Among them, each node corresponds to a physical connection pool, for example, the master node corresponds to physical connection pool 1, the standby node 1 corresponds to physical connection pool 2, ..., and the standby node N corresponds to physical connection pool N-1. The master node can provide database services to clients (for example, client 1, client 2, client 3, ..., client N) through the physical connection in the physical connection pool 1. In other words, the physical connection pool includes physical connections, and the client can connect to the database of the corresponding node through the physical connection in the physical connection pool, so that the client can access the database of the node.

[0106] In some embodiments, when the client is connected to the database of the first node through the first physical connection pool of the first node, the client can perform anomaly detection on the first node in real time. When the client detects that the first node is abnormal, it is determined that the first node does not meet the operating conditions. For example, the client can perform anomaly detection on the first node through the JDBC driver, and when it is detected that the network communication of the first node is abnormal or the first node is down, it can be determined that the first node does not meet the operating conditions.

[0107] In other embodiments, the management system of the database disaster recovery network may also perform abnormality detection on the first node and provide the detection result to the client. When the detection result indicates that the first node is abnormal, it can be determined that the first node does not meet the operating conditions.

[0108] S102: The client obtains physical connection pool information of a second node among the multiple nodes.

[0109] The second node may be a standby node. The physical connection pool information may include an IP address of the node.

[0110] In some embodiments, when the first node does not meet the operating conditions, the client may obtain physical connection pool information of a second node among the multiple nodes, and replace the first node with the second node through the physical connection pool information.

[0111] For example, Figure 4 As shown, when the client determines that the master node (as an example of the first node) does not meet the operating conditions, the IP address of the standby node 1 (as an example of the second node) can be obtained to replace the master node with the standby node 1 through the IP address of the standby node.

[0112] In some embodiments, the client may obtain a first table including physical connection pool information of a plurality of nodes, and query the first table for physical connection pool information of a second node.

[0113] Among them, the first table can be a node list. The node list is used to record the IP addresses and active and standby role information of all nodes. When a disaster recovery switch occurs in the data disaster recovery network (i.e., the active node is switched to the standby node, and the standby node is switched to the new active node), the active and standby role information in the node list will be updated.

[0114] Specifically, the client can query the first tag information in the first table, and then obtain the physical connection pool information of the second node from the candidate physical connection pool information in the first table based on the first tag information, wherein the first tag information indicates that the database service is provided to the client.

[0115] Among them, the candidate physical connection pool information is the physical connection pool information of each node in the first table, such as the IP address of each node in the node list. The first tag information is the master identifier (such as master) in the master-slave role information (role). Each master-slave role information corresponds to an IP address. When the master-slave role information of the node is the master identifier (such as master), it means that the node is the master node, and the node provides database services to the client. When the master-slave role information of the node is the standby identifier (such as slave), it means that the node is a standby node and does not provide database services to the client.

[0116] After the client obtains the node list, it can query the primary identifier in the node list, and then obtain the physical connection pool information corresponding to the primary identifier to obtain the physical connection pool information of the standby node.

[0117] S103: The client replaces the first node with the second node based on the physical connection pool information of the second node, wherein the second node provides a database service to the client through a second physical connection pool corresponding to the second node.

[0118] The second physical connection pool may be a physical connection pool corresponding to the standby node.

[0119] In some embodiments, after the client determines that the first node does not meet the operating conditions and obtains the physical connection pool information of the second node, the client can disconnect from the database of the first node, and determine the second physical connection pool corresponding to the second node based on the physical connection pool information of the second node, and then connect to the database of the second node through the physical connection in the second physical connection pool.

[0120] For example, Figure 4 As shown, when the master node of the database disaster recovery network is abnormal, the client disconnects from the database of the master node, obtains the IP address of the standby node 1, and then determines the physical connection pool 2 corresponding to the standby node based on the IP address, and connects to the database of the standby node 1 through the physical connection in the physical connection pool 2.

[0121] It should be noted that in the embodiment of the present application, each node corresponds to a physical connection pool, and each physical connection pool is pre-created.

[0122] In the embodiment of the present application, since the physical connection pool of each node is pre-created, when the first node providing database services to the client through the first physical connection pool does not meet the operating conditions, it can directly switch to the second node to provide database services to the client through the second physical connection pool. There is no need to wait for the creation of the physical connection pool, which shortens the switching time of the database node, thereby shortening the recovery time of the database service, improving the speed of database service recovery, and improving the speed of fault recovery.

[0123] Fig. 10B An example flowchart of a method for switching the master and standby nodes of a database provided in an embodiment of the present application.

[0124] refer to Fig. 10B , the node switching method of the database includes the following steps:

[0125] S201: The application obtains a node list, wherein the node list includes active and standby role information and the IP address of each node.

[0126] The node list is used to record the IP addresses and primary and backup role information of all nodes. When a disaster recovery switch occurs in the data disaster recovery network (i.e., the primary node is switched to the backup node, and the backup node is switched to the new primary node), the primary and backup role information in the node list will be updated. In some embodiments, the node list can be stored in the database of the primary node. Among them, the primary node can synchronize the node list to the backup node in real time, so that the backup node also stores the node list and keeps it consistent with the node list in the primary node for use after the primary and backup nodes are switched.

[0127] Exemplarily, when the node with IP address "192.168.1.2" is the master node and the node with IP address "192.168.1.3" is the standby node, the node list is as shown in Table 1 below: The master and standby role information of the node with IP address "192.168.1.2" is a master identifier such as master, indicating that the node with IP address "192.168.1.2" is the master node. The role information of the node with IP address "192.168.1.3" is a standby identifier such as slave, indicating that the node with IP address "192.168.1.2" is a standby node.

[0128] It should be noted that the primary identifier and the backup identifier may also be other types of identifiers. For example, the primary identifier may be represented by true, and the backup identifier may be false. There is no limitation on this.

[0129] Table 1

[0130] IP address role 192.168.1.2 master 192.168.1.3 slave

[0131] When the master node with the IP address "192.168.1.2" is switched to the standby node, and the standby node with the IP address "192.168.1.3" is switched to the master node, the node list can be updated to the following Table 2.

[0132] Table 2

[0133] IP address role 192.168.1.2 slave 192.168.1.3 master

[0134] The embodiment of the present application provides a software development kit (SDK). SDK is a collection of development tools used by software engineers to create application software for specific software packages, software frameworks, hardware platforms, operating systems, etc. The SDK can be integrated into an application program to create a physical connection pool for each node in advance, so that when the application program switches nodes, it does not need to recreate the physical connection pool, but directly uses the pre-created physical connection pool to connect to the switched node.

[0135] In some embodiments, the SDK of the application may start a monitoring thread, and the monitoring thread obtains a node list from a default master node or any node, and returns the node list to the SDK of the application.

[0136] S202: The application creates a physical connection pool for each node based on the IP address of each node.

[0137] After the application SDK obtains the node list, it can obtain the IP address of each node, and then create a physical connection pool for each node based on the IP address of each node. It can be understood that each IP address corresponds to a physical connection pool.

[0138] S203: The application determines the master node based on the master-slave role information, and connects to the database of the master node through the physical connection pool of the master node.

[0139] After the application SDK obtains the node list, it can determine the master node according to the master and standby role information in the node list, and connect to the database of the master node through the physical connection pool of the master node.

[0140] For example, when the node list obtained by the SDK of the application is the above Table 1, the node with the IP address "192.168.1.2" can be determined as the master node. In this case, the application can connect to the database of the node with the IP address "192.168.1.2" through the physical connection pool of the node, that is, to the database of the master node.

[0141] S204: The application obtains a node list.

[0142] The application connects to the database of the master node through the physical connection pool of the master node and can obtain the node list.

[0143] In some embodiments, after the SDK of the application program starts the monitoring thread, the monitoring thread may query the node list at a set time interval (eg, 2 seconds, etc.), and return the node list to the SDK of the application program.

[0144] S205: The application determines whether the master and backup nodes have switched based on the master and backup role information in the acquired node list. If yes, execute step S206. If no, execute step S204.

[0145] After receiving the node list, the SDK of the application can determine whether the master node has switched based on the master and backup role information in the node list. For example, when the role information of a node in the currently acquired node list is inconsistent with the role information of the node in the last acquired node list, it is determined that the master and backup roles of the node have changed, that is, the master and backup nodes have switched.

[0146] Exemplarily, if the node list is updated from Table 1 to Table 2, it is determined that the database disaster recovery network has performed a switchover of the primary and standby nodes. At this time, the application SDK can execute the following step S206 to switch to the database of the primary node after the primary and standby node switchover for connection. On the contrary, if the node list is not updated, it means that the database disaster recovery network has not performed a switchover of the primary and standby nodes, and the application SDK can continue to execute the above step S204.

[0147] S206: The application determines the physical connection pool of the new master node, and connects to the new master node through the physical connection pool of the new master node.

[0148] When the application's SDK determines that the master and standby nodes have switched based on the master and standby role information in the node list, that is, when the original master node is switched to the standby node, and the original standby node is switched to the new master node, the application's SDK can determine the physical connection pool of the new master node based on the IP address of the new master node in the node list, and then connect to the database of the new master node through the physical connection pool.

[0149] For example, when the application's SDK determines that the master node with IP address 192.168.1.2 is switched to the backup node, and the backup node with IP address 192.168.1.3 is switched to the new master node, the application's SDK can connect to the database of the node with IP address 192.168.1.3 (i.e., the new master node) through the physical connection pool corresponding to IP address 192.168.1.3, that is, the application is connected to the database of the new master node.

[0150] In the embodiment of the present application, the physical connection pool of each node is pre-created. When the primary and backup nodes are switched in the database disaster recovery network, the application (i.e., the client) can directly connect to the database of the new primary node after the primary and backup nodes are switched through the pre-created physical connection pool without re-creating the corresponding physical connection pool. In this way, the time for the application to switch connections can be reduced, and the speed of the application to switch connections can be increased, thereby quickly restoring the database service to the application and improving the speed of fault recovery.

[0151] In the above Fig. 10BIn the described embodiment, when the application switches the physical connection pool, the IP address needs to be changed. For example, when the application switches from the physical connection pool corresponding to the IP address 192.168.1.2 to the physical connection pool corresponding to the IP address 192.168.1.3, the application needs to change the IP address of the connection object from 192.168.1.2 to 192.168.1.3, so as to connect to the database of the node with the IP address 192.168.1.3 through the physical connection pool corresponding to the IP address 192.168.1.3. It can be understood that the change of the IP address will also take a certain amount of time. In order to realize the rapid switching of the physical connection pool and improve the high availability of the database disaster recovery network, on the basis of pre-establishing the physical connection pool of each node, a logical connection pool can also be established to realize the rapid switching of the physical connection pool through the logical connection pool.

[0152] For example, reference Fig.11 , the VIP address provided by the logical connection pool for the application is 172.168.1.1, the IP address corresponding to the physical connection pool of the master node is 192.168.1.2, and the IP address of the physical connection pool of the standby node is 192.168.1.3. Among them, the VIP address 172.168.1.1 points to the IP address 192.168.1.2, so that the logical connection pool is bound to the physical connection pool of the master node. At this time, the application can set the IP address of the connection object to the VIP address 172.168.1.1. When the application obtains a connection, the logical connection pool can return a logical connection that encapsulates the physical connection in the physical connection pool of the master node, so that the application can connect to the database of the master node.

[0153] In the above Fig.11 Based on the reference Fig.12 When the database of the primary node is unavailable and the application needs to switch to the database of the standby node, the VIP address 172.168.1.1 can point to the IP address 192.168.1.3 of the standby node, so that the logical connection pool is unbound from the physical connection pool of the primary node and bound to the physical connection pool of the standby node. After the logical connection pool is bound to the physical connection pool of the primary node, the application connects to the database of the standby node. In this way, the application can switch the physical connection pool without changing the IP address of the connection object, and the switching speed of the physical connection pool is improved.

[0154] Fig.13 A schematic diagram of the principle of quickly restoring database connections after disaster recovery switching in the database disaster recovery network provided in an embodiment of the present application.

[0155] like Fig.13As shown, the application can connect to the database of the master node through the logical connection pool and physical connection pool created by the SDK and the database driver (such as the JDBC driver). The application can send requests to the database through the logical connection pool, the physical connection pool, and the database driver in turn, such as data query requests, and then the database can return results to the application through the database driver, the physical connection pool, and the logical connection pool in turn, such as data query results. In the process of the application accessing the database, the SDK can start the monitoring thread through the logical connection pool. After the monitoring thread is started, the node list list can be queried from the database of the master node through the VIP address at a set time interval (such as 2 seconds, etc.), and the master node switchover can be determined based on the node list list. If so, the logical connection pool is modified, specifically, the binding relationship between the logical connection pool and the physical connection pool is modified, for example, the binding relationship with the physical connection pool corresponding to the original master node is released, and the physical connection pool corresponding to the new master node is re-bound. If not, it is determined whether the IP address has changed, that is, whether the IP address corresponding to the physical connection pool has changed. If yes, modify the physical connection pool, specifically modify the IP address corresponding to the physical connection pool; if no, continue to query the node list through the VIP address.

[0156] Fig.14A An example of a process for switching a database node provided in an embodiment of the present application Figure 2 .

[0157] like Fig.14A As shown, the method comprises the following steps:

[0158] S210: The client determines that the first node does not meet the operating condition, and unbinds the logical connection pool from the first physical connection pool.

[0159] In an embodiment of the present application, a database can be stored in multiple nodes, and the database of each node remains consistent. The first node among the multiple nodes provides database services to the client through a logical connection pool bound to a first physical connection pool corresponding to the first node. The first node can be a master node, and the first physical connection pool can be a physical connection pool corresponding to the master node. The client can be an application, such as a Java application.

[0160] For example, Figure 5As shown, the database disaster recovery network includes a master node and N standby nodes, each node includes a database, and the database of each node is consistent, and the master node can synchronize its own data to each standby node in real time, so that the data of the master and standby nodes are consistent. Among them, each node corresponds to a physical connection pool, for example, the master node corresponds to physical connection pool 1, the standby node 1 corresponds to physical connection pool 2, ..., and the standby node N corresponds to physical connection pool N-1. The master node can provide database services to clients (for example, client 1, client 2, client 3, ..., client N) through the logical connection in the logical connection pool bound to the physical connection pool 1. Among them, the logical connection in the logical connection pool encapsulates the physical connection in the physical connection pool 1 bound to it, so the client can connect to the database of the master node through the logical connection in the logical connection pool.

[0161] In some embodiments, when the client is connected to the database of the first node through the first physical connection pool of the first node, the client can perform anomaly detection on the first node in real time. When the client detects that the first node is abnormal, it is determined that the first node does not meet the operating conditions. For example, the client can perform anomaly detection on the first node through the JDBC driver, and when it is detected that the network communication of the first node is abnormal or the first node is down, it can be determined that the first node does not meet the operating conditions.

[0162] In other embodiments, the management system of the database disaster recovery network may also perform abnormality detection on the first node and provide the detection result to the client. When the detection result indicates that the first node is abnormal, it can be determined that the first node does not meet the operating conditions.

[0163] It can be understood that when the first node provides database services for the client, a mapping relationship is established between the logical connection pool information of the logical connection pool and the physical connection pool information of the first node, so that the logical connection pool is bound to the physical connection pool of the first node. The logical connection pool information can be a VIP address, and the physical connection pool information can be an IP address.

[0164] In some embodiments, after the client determines that the first node does not meet the operating conditions, it can release the mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the first node, so that the logical connection pool is unbound from the physical connection pool of the first node.

[0165] For example, Figure 6 As shown, when the original master node does not meet the operating conditions, the client can release the mapping relationship between the VIP address provided by the logical connection pool and the IP address of the original master node, so that the logical connection pool is unbound from the physical connection pool 1 of the original master node.

[0166] S220: The client obtains physical connection pool information of a second node among the multiple nodes.

[0167] Step S220 is substantially the same as the above-mentioned step S102 and will not be described again here.

[0168] S230: The client binds the logical connection pool to the second physical connection pool corresponding to the second node based on the physical connection pool information of the second node to replace the first node with the second node, wherein the second node provides database services to the client through the logical connection pool bound to the second physical connection pool.

[0169] In some embodiments, after the client obtains the physical connection pool information of the second node, it can establish a mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the second node, so that the logical connection pool is bound to the physical connection pool of the second node to switch the first node to the second node.

[0170] For example, Figure 6 As shown, after the logical connection pool is unbound from the physical connection pool 1 corresponding to the original master node, the client can establish a mapping relationship between the VIP address provided by the logical connection pool and the IP address of the new master node (standby node 1), so that the logical connection pool is bound to the physical connection pool 2 of the new master node. After the logical connection pool is bound to the physical connection pool 2 of the new master node, the new master node can provide database services to the client through the logical connection pool bound to the physical connection pool 2.

[0171] In the embodiment of the present application, since the physical connection pool and the logical connection pool of each node are pre-created, when the first node providing database services to the client does not meet the operating conditions, the logical connection pool can be directly unbound from the first physical connection pool, and the logical connection pool can be bound to the second physical connection pool to replace the first node with the second node. There is no need to recreate the physical connection pool, which shortens the switching time of the database node, thereby shortening the recovery time of the database service, improving the speed of database service recovery, and improving the speed of fault recovery.

[0172] Fig. 14B An example flow chart of a method for implementing fast node switching by pre-establishing a logical connection pool and a physical connection pool provided in an embodiment of the present application.

[0173] like Fig. 14B As shown, the process includes the following steps:

[0174] S301: The application program connects to the database of the master node through a logical connection pool, wherein the logical connection pool is bound to the physical connection pool of the master node.

[0175] In some embodiments, a logical connection pool and a physical connection pool for each node may be created in advance. The logical connection pool is then bound to the physical connection pool of the master node by the SDK of the application. In this case, when the application is connected to the physical connection pool of the master node, the application may be connected to the database of the master node.

[0176] S302: The application obtains a node list.

[0177] After the application is connected to the database of the master node, the SDK of the application can start the monitoring thread. The monitoring thread can query the node list at a set time interval (such as 2 seconds) and return the node list to the application.

[0178] S303: The application determines whether the master and backup nodes have switched based on the master and backup role information in the acquired node list. If yes, execute step S304. If no, execute step S302.

[0179] After receiving the node list, the SDK of the application can determine whether the master node should be switched based on the master and backup role information in the node list.

[0180] Exemplarily, if the node list is updated from Table 1 to Table 2, the application SDK can determine that the database disaster recovery network has performed a switchover of the primary and standby nodes. At this time, the application can execute the following step S304 to switch to the database of the primary node after the primary and standby node switchover for connection. On the contrary, if the node list is not updated, it means that the database disaster recovery network has not performed a switchover of the primary and standby nodes, and the application SDK can continue to execute the above step S302.

[0181] S304: The application program unbinds the logical connection pool from the physical connection pool of the original master node, and binds it to the physical connection pool of the new master node, so that the application program is connected to the database of the new master node.

[0182] In some embodiments, when the database disaster recovery network switches the primary and backup nodes, the application's SDK can unbind the logical connection pool from the physical connection pool of the original primary node and bind it to the physical connection pool of the new primary node, so that the application can connect to the database of the new primary node.

[0183] Exemplarily, the IP address of the master node is 192.168.1.2, the IP address of the standby node is 192.168.1.3, and the logical connection pool is currently bound to the physical connection pool corresponding to the IP address 192.168.1.2, that is, bound to the physical connection pool of the master node. When the application determines that the master node with the IP address 192.168.1.2 is switched to the standby node, and the standby node with the IP address 192.168.1.3 is switched to the new master node, the logical connection pool can be unbound from the physical connection pool corresponding to the IP address 192.168.1.2, and then bound to the physical connection pool corresponding to the IP address 192.168.1.3, so that the application is connected to the database of the new master node with the IP address 192.168.1.3.

[0184] In the embodiment of the present application, the application switches the physical connection pool through the logical connection pool, which can realize the fast switching of the physical connection pool, improve the switching speed of the physical connection pool, and thus improve the recovery speed of the application connection to the database.

[0185] Fig.15 An example diagram of the principle of switching the logical connection pool to bind the physical connection pool provided in an embodiment of the present application.

[0186] like Fig.15 As shown, the database instance includes a VIP address, a master node, a standby node and a data function virtualization (DFV) module. Among them, the database instance is an instance of the database running. The database instance is an independent operating environment in a database management system that allows multiple users or applications to access and manage data at the same time. The VIP address points to the master node. The DFV module is used to decouple data operations and functions from the underlying data storage to provide a more flexible, scalable and efficient data management and processing method. The main goal of DFV is to separate the logical layer of data operations from the physical storage layer of data, so that data can be moved between different storage systems without modifying the application or data operation code. In an embodiment of the present application, the DFV module can decouple the data operations of the master node and the standby node.

[0187] After the application is started, the application SDK can connect to the database instance through the VIP address to obtain the node list of the master node. In addition to the master and slave role information and the IP addresses of each node, the node list can also include node status information, master and slave synchronization delay, and other information. After the SDK obtains the node list, it can use the IP address in the node list to create a corresponding physical connection pool for each node and point the logical connection pool to the physical connection pool of the master node.

[0188] like Fig.15As shown, the SDK can pre-create a logical connection pool, as well as a physical connection pool 1 for the master node, a physical connection pool 2 for the standby node, and a physical connection pool 3 for the disaster recovery node. Among them, the disaster recovery node is a backup node of the standby node, and the standby node synchronizes data to the disaster recovery node in real time, so that the data of the disaster recovery node is consistent with that of the master node and the standby node. The logical connection pool points to the physical connection pool 1, that is, it is bound to the physical connection pool 1, so that the application is connected to the database of the master node. After the application is connected to the database of the master node, the SDK can start the monitoring thread. After the monitoring thread is started, the node list can be queried through the VIP address at the set time interval, and then the queried node list is returned to the logical connection pool of the SDK. The logical connection pool determines whether the master and standby nodes are switched according to the node list, so as to switch the binding object when the master and standby nodes are switched.

[0189] For example, when the primary node switches to the standby node and the standby node switches to the new primary node, the application SDK can unbind the logical connection pool from the physical connection pool 1. Then the application SDK can bind the logical connection pool to the physical connection pool 2, so that the application switches to the data connection with the standby node. In this case, the recovery time objectives (RTO) 1 is usually less than or equal to 10 seconds.

[0190] For another example, when the primary node is switched to the backup node and the disaster recovery node is switched to the new primary node, the application's SDK can unbind the logical connection pool from the physical connection pool 1. Then the application's SDK can bind the logical connection pool to the physical connection pool 3, so that the application switches to the database connection with the disaster recovery node. In this case, RTO2 is usually less than or equal to 1 minute. It can be understood that the primary node and the backup node are close to each other, such as being in the same computer room, while the disaster recovery node is far from the primary node, such as being in a different computer room. Therefore, the resource scheduling when switching to the backup node is faster than the resource scheduling when switching to the disaster recovery node, which makes RTO1 less than RTO2.

[0191] Fig.16 An example diagram of the interactive process of an application program accessing a database of a master node provided in an application embodiment.

[0192] like Fig.16 As shown, the process includes the following steps:

[0193] S401: The business process requests a logical connection from the SDK.

[0194] When an application accesses the database of the master node, the business process of the application can call the SDK connection interface provided by the SDK to send a request to the SDK to request a logical connection from the SDK.

[0195] S402: The SDK requests a logical connection from the logical connection pool.

[0196] Among them, the logical connection pool is pre-created.

[0197] After receiving the request sent by the business process, the SDK may send a request to the logical connection pool to request a logical connection from the logical connection pool.

[0198] S403: The logical connection pool requests a physical connection from the physical connection pool.

[0199] Among them, the physical connection pool is created in advance, and each node corresponds to a physical connection pool.

[0200] After receiving the request sent by the SDK, the logical connection pool can send a request to the physical connection pool to request a physical connection.

[0201] S404: The physical connection pool returns the physical connection of the master node to the logical connection pool.

[0202] After receiving the request from the logical connection pool, the physical connection pool may return the physical connection of the primary node to the logical connection pool.

[0203] S405: The logical connection pool returns the logical connection encapsulating the physical connection of the master node to the SDK.

[0204] After receiving the physical connection returned by the physical connection pool, the logical connection pool may return the logical connection encapsulating the physical connection to the SDK.

[0205] S406: The SDK returns a logical connection encapsulating the physical connection of the master node to the business process.

[0206] After the SDK receives the logical connection encapsulating the physical connection of the master node returned by the logical connection pool, it can return the logical connection to the business process.

[0207] S407: The business process sends an SQL request to the SDK.

[0208] After the business process of the application receives the logical connection encapsulating the physical connection of the master node returned by the SDK, the application can connect to the database of the master node through the logical connection. After the application connects to the database of the master node, the application can access the database of the master node. When the application accesses the database of the master node, the business process of the application can call the SDK connection interface provided by the SDK to make an SQL request. Among them, the SQL request can be a request for data query, data writing, data definition, etc., which is not limited to this.

[0209] S408: The SDK sends an SQL request to the master node.

[0210] After the SDK receives the SQL request sent by the business process, it can send the SQL request to the master node.

[0211] S409: The master node returns the execution result to the SDK.

[0212] After the master node receives the SQL request sent by the SDK, the database of the master node can execute the task corresponding to the SQL request, such as querying data, writing data, defining data, etc. After the database of the master node completes the task, the master node can return the execution result to the SDK.

[0213] S410: The SDK returns the execution result to the business process.

[0214] After receiving the execution result returned by the master node, the SDK can return the result to the business process of the application. In this way, the application can access the database of the master node.

[0215] In the embodiment of the present application, the logical connection in the logical connection pool encapsulates the physical connection of the master node, and the application can connect to the database of the master node through the logical connection provided by the logical connection pool, so that the application can access the database of the master node. Since the application connects to the node through the logical connection, when the master and standby nodes are switched, the application can quickly switch to connect to the new master node. In this way, the switching speed of the node can be improved, thereby improving the speed of restoring the database service by the database disaster recovery network after the master and standby nodes are switched.

[0216] Fig.17 This is an example diagram of the process of abnormal switching of database nodes provided in an embodiment of the present application.

[0217] like Fig.17 As shown, the process includes the following steps:

[0218] S501: The business process sends an SQL request to the SDK.

[0219] Before the active and standby nodes switch, the logical connection pool is bound to the physical connection pool of the active node, so that the application can connect to the database of the active node. In this case, when the application accesses the database of the active node, the business process of the application can send SQL requests to the SDK. Among them, the SQL request can be a request for data query, data writing, data definition, etc., which is not limited to this.

[0220] S502: SDK sends a SQL request to the master node.

[0221] After the SDK receives the SQL request sent by the business process, it can send the SQL request to the master node.

[0222] S503: The master node returns the execution result to the SDK.

[0223] After the master node receives the SQL request sent by the SDK, the database of the master node can execute the task corresponding to the SQL request, such as querying data, writing data, defining data, etc. After the database of the master node completes the task, the master node can return the execution result to the SDK.

[0224] S504: The SDK returns the execution result to the business process.

[0225] After receiving the execution result returned by the master node, the SDK can return the result to the business process of the application. In this way, the application can access the database of the master node.

[0226] S505: SDK starts the monitoring thread.

[0227] Before the active and standby nodes are switched, the SDK can start a monitoring thread, which queries the node list through the VIP address.

[0228] It should be noted that the execution order of step S505 and steps S501 to S504 is not specific. Step S505 can be executed before steps S501 to S504, or after steps S501 to S504, or in parallel with steps S501 to S504.

[0229] S506: The monitoring thread queries the node list through the VIP address.

[0230] In some embodiments, after the monitoring thread is started, the node list can be queried through the VIP address at a set time interval (e.g., 2 seconds). When the VIP address points to the IP address of the master node, the monitoring thread can query the node list of the database disaster recovery network from the master node. It can be understood that when the master and backup nodes are switched and the VIP address points to the IP address of the backup node, the monitoring thread can query the node list of the database disaster recovery network from the backup node.

[0231] S507: The monitoring thread sends a node list to the SDK.

[0232] Each time the monitoring thread queries the node list of the database disaster recovery network, it returns the queried node list to the SDK.

[0233] S508: The SDK changes the binding relationship of the logical connection pool based on the change of the active and standby role information in the node list.

[0234] It can be understood that when the original master node is unavailable and becomes a standby node, and the original standby node is upgraded to the master node, that is, when the master and standby nodes are switched, the master and standby role information in the node list will be updated. For example, when the master node with IP address "192.168.1.2" is switched to the standby node, and the standby node with IP address "192.168.1.3" is switched to the master node, the node list will be updated from the above Table 1 to the above Table 2.

[0235] The SDK receives the node list sent by the monitoring thread, and can change the binding relationship of the logical connection pool based on the changes in the master and backup role information in the node list, so that the application can connect to the data of the new master node. For example, when the master node with IP address "192.168.1.2" is switched to the backup node, and the backup node with IP address "192.168.1.3" is switched to the master node, the SDK can unbind the logical connection pool from the physical connection pool of the master node (whose IP address is 192.168.1.2), and then bind the logical connection pool to the physical connection pool of the backup master node (whose IP address is 192.168.1.3).

[0236] S509: The business process sends an SQL request to the SDK.

[0237] After the application is connected to the database of the standby node, when the application accesses the database of the standby node, the business process of the application can send SQL requests to the SDK.

[0238] S510: The SDK sends an SQL request to the standby node.

[0239] After the SDK receives the SQL request sent by the business process, it can send the SQL request to the standby node.

[0240] S511: The standby node returns the execution result to the SDK.

[0241] After the standby node receives the SQL request sent by the SDK, the database of the standby node can execute the task corresponding to the SQL request, such as querying data, writing data, defining data, etc. After the database of the standby node completes the task, the standby node can return the execution result to the SDK.

[0242] S512: The SDK returns the execution result to the application.

[0243] After receiving the execution result returned by the standby node, the SDK can return the execution result to the business process of the application, so that the application can switch from accessing the database of the primary node to accessing the database of the standby node.

[0244] It should be noted that the execution order of the above steps S506 to S507 and the above steps S501 to S505, and the above steps S508 to S512 is not particular. Moreover, the above steps S506 to S507 can be executed not only before the master-slave node switchover, but also after the master-slave node switchover. The monitoring thread can execute the above steps S506 to S507 in a loop, that is, the monitoring thread can not only query the list before the master-slave node switchover, but also return the queried query list list to the SDK. It is also possible to query the list after the master-slave node switchover, and return the queried query list list to the SDK. In an embodiment of the present application, when the master-slave node switchover occurs in the database disaster recovery network, the application only needs to change the binding relationship of the logical connection pool through the SDK to achieve the switching of the master and standby nodes. The switching of database nodes is relatively simple, which improves the switching speed of database nodes, thereby improving the recovery speed of node failures.

[0245] Fig.18 A business recovery timing diagram of database disaster recovery networking when a physical connection pool is pre-created in an embodiment of the present application.

[0246] like Fig.18 As shown in the figure, at time T1, the primary node of the database disaster recovery network fails and the service begins to be interrupted. From time T1 to time T1+10S, the primary node connection is interrupted. From time T1 to time T1+11S, the physical connection pool of the primary node is disconnected. From time T1 to time T1+15S, the logical connection pool is directly switched to the physical connection pool bound to the standby node for rapid recovery. In other words, after the service of the database disaster recovery network is interrupted, by directly switching the logical connection pool to the physical connection pool bound to the standby node, the service of the database disaster recovery network can be fully restored after 15S.

[0247] It can be understood that the logical connection pool and the physical connection pool of each node in the database disaster recovery network are pre-established. When the primary node is not faulty, the logical connection pool is bound to the physical connection pool of the primary node, so that the application connects to the database of the primary node. When the primary node fails, the logical connection pool can be quickly switched to the physical connection pool bound to the standby node, so that the application connects to the database of the standby node. In this way, the data service business of the database disaster recovery network can be restored in a shorter time.

[0248] As a comparison, Fig.19 A business recovery timing diagram for database disaster recovery networking when a physical connection pool is not pre-created provided in an embodiment of the present application.

[0249] like Fig.19As shown, at time T1, the primary node of the database disaster recovery network fails and the service begins to be interrupted. From time T1 to time T1+10S, the primary node connection is interrupted. From time T1 to time T1+11S, the physical connection pool of the primary node is interrupted. From time T1 to time T1+30S, the physical connection pool of the standby node is gradually created and gradually restored. In other words, after the service of the database disaster recovery network is interrupted, the service of the database disaster recovery network can be fully restored after 30S. It can be understood that since the physical connection pool of the standby node is not created in advance, when the primary node fails, it is necessary to re-create the physical connection pool for the standby node, which increases the time for the database disaster recovery network service recovery.

[0250] Compare the above Fig.18 and Fig.19 It can be seen that by creating a physical connection pool for each node in advance, the business recovery time of the database disaster recovery network can be shortened and the speed of business recovery of the database disaster recovery network can be improved, thereby shortening the database disconnection time and reducing the impact of node failures.

[0251] Fig. 20 The schematic diagram of the structure of the electronic device 100 is shown. The electronic device 100 may be an electronic device such as a database server mentioned in this application.

[0252] like Fig. 20 As shown, the electronic device 100 includes: one or more processors 1032, a communication interface 1033, a memory 1031, a bus system 1034, and one or more programs. The communication interface 1033, the processor 1032, and the memory 1031 are interconnected via the bus system 1034; the bus system 1034 can be a peripheral component interconnection standard bus or an extended industrial standard structure bus, etc.

[0253] The processor 1032 is used to enable the electronic device 100 to perform actions such as database connection and physical connection pool switching when executing instructions stored in the memory 1031, such as physical connection pool switching, SQL request, database connection, etc. For example, when the processor 1032 executes an SQL instruction for data query, the electronic device 100 can query data in the database.

[0254] The communication interface 1033 is used to receive instructions sent by the client, such as SQL instructions, and send request execution results, such as queried data, etc. to the client. For example, when the client accesses the database of the electronic device 100, the client can send SQL instructions, such as data query instructions, data definition instructions, data operation instructions, etc. to the electronic device 100 through the communication interface 1033. After the electronic device 100 receives the SQL instruction sent by the client, the database of the electronic device 100 can execute the SQL instruction and return the execution result, such as queried data, etc., to the client through the communication interface 1033.

[0255] The memory 1031 is used to store user data, logical pools, physical connection pools, logical connections, physical connections and other data, as well as physical connection pool switching, SQL requests, database connections and other instructions.

[0256] The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The one or more programs are stored in the memory 1031, and the one or more programs include instructions. When the instructions are executed by the electronic device 100, the electronic device 100 executes Fig. 9 , Fig. 10A , Fig. 10B , Fig. 14B , Fig.16 , Fig.17 The related method in any of the accompanying drawings.

[0257] The present application also provides a computer storage medium storing one or more programs, wherein the one or more programs include instructions, which, when executed by the electronic device 100, cause the electronic device 100 to execute Fig. 9 , Fig. 10A , Fig. 10B , Fig.14A , Fig. 14B , Fig.16 , Fig.17 The related method in any of the accompanying drawings.

[0258] The present application also provides a computer program product including instructions, which, when executed on the electronic device 100, enables the electronic device 100 to execute Fig. 9 , Fig. 10A , Fig. 10B , Fig.14A , Fig. 14B , Fig.16 , Fig.17 The method associated with any of the accompanying drawings.

[0259] Among them, the electronic device, computer storage medium or computer program product provided in this application is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0260] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0261] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0262] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0263] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0265] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0266] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using a software program, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loading and executing a computer program instruction on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, a computer, a database server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, database server or data center. The computer-readable storage medium may be any available medium that a computer can access or may contain one or more data storage devices such as database servers and data centers that can be integrated with a medium. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium, or a semiconductor medium (eg, a solid state disk (SSD)).

[0267] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A database node switching method, characterized in that: The database is stored in a plurality of nodes, wherein a first node among the plurality of nodes provides a database service to a client through a first physical connection pool corresponding to the first node; The method comprises: Determining that the first node does not meet the operating condition; Acquire physical connection pool information of a second node among the multiple nodes; Based on the physical connection pool information of the second node, the first node is replaced with the second node, wherein the second node provides database services for the client through a second physical connection pool corresponding to the second node.

2. The method according to claim 1, characterized in that The obtaining of physical connection pool information of a second node among the multiple nodes includes: Acquire a first table including physical connection pool information of the plurality of nodes; The physical connection pool information of the second node is queried in the first table.

3. The method according to claim 2, characterized in that The querying the physical connection pool information of the second node in the first table includes: Querying first marking information in the first table, wherein the first marking information indicates that a node provides database services for the client; The physical connection pool information of the second node is acquired from the candidate physical connection pool information in the first table based on the first marking information.

4. The method according to claim 1, characterized in that: The determining that the first node does not meet the operating condition includes: When it is detected that the communication connection of the first node is abnormal or the first node is down, it is determined that the first node does not meet the operating condition.

5. The method according to any one of claims 1 to 4, characterized in that: The physical connection pool information includes an Internet Protocol address.

6. A method for switching a database node, characterized in that: The database is stored in a plurality of nodes, wherein a first node among the plurality of nodes provides a database service to a client through a logical connection pool bound to a first physical connection pool corresponding to the first node; The method comprises: Determining that the first node does not meet the operating condition, and unbinding the logical connection pool from the first physical connection pool; Acquire physical connection pool information of a second node among the multiple nodes; Based on the physical connection pool information of the second node, the logical connection pool is bound to the second physical connection pool corresponding to the second node to replace the first node with the second node, wherein the second node provides database services for the client through the logical connection pool bound to the second physical connection pool.

7. The method according to claim 6, characterized in that The unbinding the logical connection pool from the first physical connection pool includes: The mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the first node is released, so that the logical connection pool is unbound from the physical connection pool of the first node.

8. The method according to claim 6, characterized in that The step of binding the logical connection pool to a second physical connection pool corresponding to the second node based on the physical connection pool information of the second node includes: A mapping relationship between the logical connection pool information of the logical connection pool and the physical connection pool information of the second node is established, so that the logical connection pool is bound to the physical connection pool of the second node.

9. The method according to claim 6, characterized in that The obtaining of physical connection pool information of a second node among the multiple nodes includes: Acquire a first table including physical connection pool information of the plurality of nodes; The physical connection pool information of the second node is queried in the first table.

10. The method according to claim 9, characterized in that The querying the physical connection pool information of the second node in the first table includes: Querying first tag information in the first table, wherein the first tag information indicates that a database service is provided for the client; The physical connection pool information of the second node is acquired from the candidate physical connection pool information in the first table based on the first marking information.

11. The method according to claim 6, characterized in that The determining that the first node does not meet the operating condition includes: When it is detected that the communication connection of the first node is abnormal or the first node is down, it is determined that the first node does not meet the operating condition.

12. The method according to any one of claims 6 to 11, characterized in that: The logical connection pool address includes a virtual Internet Protocol address, and the physical connection pool information includes an Internet Protocol address.

13. An electronic device, characterized in that: include: a memory for storing instructions executed by one or more processors of the electronic device; The processor, when executing the instructions in the memory, can enable the electronic device to execute the database node switching method described in any one of claims 1 to 5 or claims 6 to 12.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the database node switching method according to any one of claims 1 to 5 or claims 6 to 12.

Images