Database cluster management method, device, equipment and computer program product

Abstract

The invention discloses a database cluster management method, device and equipment and a computer program product, and relates to the technical field of basic setting and IT supporting, and the method comprises the steps: monitoring the operation state of a first main server node; when the operation state of the first master server node has an operation fault, acquiring a node state of a slave server node cluster; and based on the node state of the slave server node cluster, determining a second master server node from the slave server node cluster through a pushing algorithm. The new master server node is determined between the slave server nodes through the pushing algorithm, automatic switching between the master server node and the slave server nodes is achieved, and the technical problem that a database deployed in a single-point mode cannot be used when having a fault is solved.

Description

Technical Field

[0001] This application relates to the field of infrastructure and IT support technologies, and particularly to a method, apparatus, device, and computer program product for database cluster management. Background Art

[0002] In the field of database technology, PostgreSQL (referred to as Postgres for short), as a powerful and highly scalable open-source relational database system, is widely used in various business scenarios. However, with the growth of business scale and the increase in data volume, the high availability and performance optimization of databases have become important considerations in enterprise IT architectures. Currently, the high-availability solutions for Postgres databases are mainly divided into two types: single-node deployment and cluster deployment:

[0003] 1. Single-node deployment, where the database runs in the form of a single node. After a single-node database fails, the data is backed up and restored to a new node, or a new database node is started through streaming replication to continue providing services. Restoring data through backup requires manual intervention and takes several minutes to restore the data and services, during which the database service is unavailable. Through the method of streaming replication, due to the reason of the original database failure, data loss may occur, and the database service is also unavailable during repair.

[0004] 2. Cluster deployment, by introducing virtual IP and load balancing mechanisms, the requests of database clients are distributed to the primary node in the cluster. The requests of database clients are distributed to the database primary node through virtual IP. When the database primary node fails, it drifts to the server where the newly generated primary node is located through virtual IP, so as to continue to provide highly available services. In fact, the database node that can actually process business is still in a single-node mode, unable to handle the scenario of large data and high concurrency, and the performance bottleneck still cannot be broken through.

[0005] The above content is only used to assist in understanding the technical solution of this application, and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a method, apparatus, device, and computer program product for database cluster management, aiming to solve the technical problem that the database cannot be used when switching databases due to a failure in a single-point mode deployment.

[0007] To achieve the above object, this application proposes a method for database cluster management, and the method includes:

[0008] Monitoring the running status of the first primary server node;

[0009] When the operating status of the first primary server node experiences an operating disconnection, obtain the node status of the slave server node cluster;

[0010] Based on the node status of the slave server node cluster, determine a second primary server node from the slave server node cluster through an election algorithm.

[0011] In one embodiment, the step of determining a second primary server node from the slave server node cluster based on the node status of the slave server node cluster through an election algorithm includes:

[0012] Perform an active status detection on the slave server node cluster to obtain a list of active nodes;

[0013] Based on the list of active nodes, perform node liveness detection on the slave server node cluster to obtain the data replication progress of the slave server node cluster that synchronously replicates data from the first primary server node, and obtain a replication progress sorting table of the slave server node cluster;

[0014] Sort the preset weights of the slave server node cluster to obtain a weight sorting table of the slave server node cluster;

[0015] Based on the replication progress sorting table and the weight sorting table, determine the second primary server node.

[0016] In one embodiment, the step of performing node liveness detection on the slave server node cluster based on the list of active nodes includes:

[0017] If the number of slave server nodes in the list of active nodes is equal to a first threshold, use the slave server nodes in the list of active nodes as the second primary server node;

[0018] If the number of slave server nodes in the list of active nodes is greater than the first threshold, perform node liveness detection on the slave server node cluster based on the list of active nodes.

[0019] In one embodiment, the step of determining the second primary server node based on the replication progress sorting table and the weight sorting table includes:

[0020] Based on the replication progress sorting table, obtain a first slave server node in the slave server node cluster;

[0021] If the number of nodes of the first slave server node is equal to the first threshold, use the first slave server node as the second primary server node;

[0022] If the number of nodes of the first slave server node is greater than the first threshold, determine the second master server node from the first slave server nodes based on the weight sorting table.

[0023] In one embodiment, after the step of determining the second master server node based on the replication progress sorting table and the weight sorting table, the following steps are further included:

[0024] Detect the active state of the first master server node to obtain the state detection result of the first master server node;

[0025] When the state detection result is that the node is alive, abandon the second master server node and wait for the first master server node to recover;

[0026] When the state detection result is that the node is offline, perform node liveness detection on the second master server node through the slave server node cluster to obtain the node liveness detection result of the second master server node;

[0027] Based on the node liveness detection result, determine the election result of the second master server node.

[0028] In one embodiment, the step of determining the election result of the second master server node based on the node liveness detection result includes:

[0029] When the node liveness detection result is less than half of the number of nodes in the slave server node cluster, the election of the second master server node fails;

[0030] When the node liveness detection result is greater than or equal to half of the number of nodes in the slave server node cluster, determine that the election of the second master server node is successful, and switch the data synchronization target of the slave server node cluster from the first master server node to the second master server node.

[0031] In one embodiment, after the step of determining that the election of the second master server node is successful and switching the data synchronization target of the slave server node cluster from the first master server node to the second master server node, the following steps are further included:

[0032] Perform node state detection on the second master server node and the slave server node cluster to obtain the node states of the second master server node and the nodes in the slave server node cluster;

[0033] According to the node states, distribute the scheduling requests facing the second master server node to the second master server node and the slave server node cluster based on the dynamic adjustment load distribution strategy;

[0034] The scheduling request is executed based on a read-write separation strategy through the second master server node and the slave server node cluster.

[0035] In one embodiment, the method further comprises:

[0036] Performing binding detection on the virtual addresses between the first master server node and the slave server node cluster to obtain a virtual address binding result;

[0037] When the virtual address binding result is that the virtual address is already bound, releasing the server virtual address binding between the first master server node and the slave server node cluster;

[0038] When the virtual address binding result is that the virtual address is not bound, server virtual address binding is performed based on the address binding request sequence of the servers between the first master server node and the slave server node cluster.

[0039] In addition, to achieve the above-mentioned purpose, the present application also proposes a database cluster management device, which includes:

[0040] A status monitoring module, used to monitor the operating status of the first master server node;

[0041] A status acquisition module is used to acquire the node status of the slave server node cluster when the running status of the first master server node is offline;

[0042] The node determination module is used to determine the second master server node from the slave server node cluster through a recommendation algorithm based on the node status of the slave server node cluster.

[0043] In addition, to achieve the above-mentioned purpose, the present application also proposes a database cluster management device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the database cluster management method described above.

[0044] In addition, to achieve the above objectives, the present application also proposes a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, the steps of the database cluster management method described above are implemented.

[0045] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps of the database cluster management method as described above.

[0046] One or more technical solutions proposed in this application have at least the following technical effects:

[0047] A database cluster management method, device, equipment, and computer program product proposed in an embodiment of this application monitor the operating status of a first master server node; when a running failure occurs in the operating status of the first master server node, obtain the node status of a slave server node cluster; based on the node status of the slave server node cluster, determine a second master server node from the slave server node cluster through a promotion algorithm. By determining a new master server node through a promotion algorithm between slave server nodes, automatic switching between the master and slave server nodes is realized, solving the technical problem that the database cannot be used when a single-point mode deployment fails. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with this application, and are used together with the specification to explain the principles of this application.

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings required for use in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0050] Figure 1 It is a schematic flowchart provided for Embodiment 1 of the database cluster management method of this application;

[0051] Figure 2 It is a schematic diagram of deployment on the servers of the master node and the slave node provided for the embodiment of the database cluster management method of this application;

[0052] Figure 3 It is a schematic flowchart of the promotion algorithm provided for the embodiment of this application;

[0053] Figure 4 It is a schematic diagram of the module structure of the database cluster management device for the embodiment of this application;

[0054] Figure 5 It is a schematic diagram of the device structure of the hardware operating environment involved in the database cluster management method for the embodiment of this application.

[0055] The implementation, functional features, and advantages of the purpose of this application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0056] It should be understood that the specific embodiments described here are only used to explain the technical solutions of this application and are not used to limit this application.

[0057] To better understand the technical solution of this application, the following will be described in detail in conjunction with the accompanying drawings of the specification and specific implementation manners.

[0058] The main solution of the embodiment of this application is: monitor the running status of the first master server node; when the running status of the first master server node has a running disconnection, obtain the node status of the slave server node cluster; based on the node status of the slave server node cluster, determine a second master server node from the slave server node cluster through a promotion algorithm.

[0059] In this embodiment, for the convenience of description, the following will be elaborated with the identification database cluster management device as the execution subject.

[0060] In the field of database technology, PostgreSQL (abbreviated as Postgres), as a powerful and highly scalable open-source relational database system, is widely used in various business scenarios. However, with the growth of the business scale and the increase in the amount of data, the high availability and performance optimization of the database have become important considerations in the enterprise IT architecture. Currently, the high-availability solutions for the Postgres database are mainly divided into two types: single-node deployment and cluster deployment:

[0061] 1. Single-node deployment, the database runs in the form of a single node. After a single-node database fails, the data backup is restored to a new node or a new database node is started through streaming replication to continue providing services. Restoring data through backup requires manual intervention and takes several minutes to restore the data and services. During this period, the database service is unavailable. Through the method of streaming replication, problems such as data loss may occur due to the reason of the original database failure, and the database service is also unavailable during the repair.

[0062] 2. Cluster deployment, by introducing a virtual IP (Internet Protocol) and a load balancing mechanism, the requests of the database client are distributed to the master node in the cluster. The database client requests are distributed to the database master node through the virtual IP. When the database master node fails, it drifts to the server where the newly generated master node is located through the virtual IP, so as to continue to provide a highly available service. In fact, the database node that can actually process business is still in a single-node mode, unable to handle the scenario of large data and high concurrency, and the performance bottleneck still cannot be broken through.

[0063] This application provides a solution. By determining a new master server node through a promotion algorithm between the slave server nodes, automatic switching between the master and slave server nodes is realized, and the technical problem that the database cannot be used when a single-point mode deployment fails is solved.

[0064] It should be noted that the execution entity of this embodiment can be a computing service device with data processing, network communication, and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a database cluster management device, etc. that can implement the above functions. Hereinafter, a database cluster management device will be taken as an example to describe this embodiment and the following embodiments.

[0065] Based on this, an embodiment of the present application provides a database cluster management method. Refer to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the database cluster management method of the present application.

[0066] Before the solution of this embodiment is described, it should be clear that the database cluster of the present application is based on the Postgres database, the full name of which is PostgreSQL, and it is a powerful and highly extensible open-source object-relational database system ORDBMS (Open Source Object-Relational Database Management System). The Postgres database supports multiple data types, including integer, floating-point, date, text, array, etc., as well as custom data types. The Postgres database ensures the integrity and durability of transactions through technologies such as multi-version concurrency control MVCC (Multi-Version Concurrency Control) and write-ahead logging WAL (Write-Ahead Logging). It supports multiple isolation levels, including read committed and serializable, etc., allowing users to select appropriate concurrent access strategies according to actual needs. The Postgres database provides multiple security functions, including user authentication, permission control, SSL (Secure Sockets Layer) encryption, etc., to protect the security of data.

[0067] Furthermore, a database cluster includes a master node and several slave nodes. Generally speaking, the master node is the leader, responsible for handling data write operations, while the slave nodes are followers, replicating the data of the master node and handling read operations. The master node is responsible for handling data write operations. When a client sends a write request, the master node will write these requests into its local storage engine; record data changes in the binary log (Binlog), and these logs will then be read by the slave nodes and applied to their own data copies to ensure data consistency; when there is a master-slave switch, it is responsible for notifying other nodes of the information of the new master node. The slave nodes are responsible for handling data read operations. The slave nodes obtain data changes from the master node and apply them to the local storage engine, thus ensuring that the data of the slave nodes is consistent with that of the master node; by reading the binary log of the master node and writing it into the relay log of the slave library, and then replaying the events in the relay log to reflect its own data changes; when the master node fails, the slave node can take over the role of the master node and continue to handle client requests, thus ensuring the high availability of the system.

[0068] In the embodiment of the present application, the server IPs where the master node and the slave nodes in the database cluster are located are in the same network segment, and a virtual IP in the same network segment is set for the database cluster. The virtual IP is the IP provided by the entire Postgres cluster for external services. When deploying the Postgres cluster, please refer to Figure 2 , Figure 2 which is a schematic diagram for deployment on the servers of the master node and the slave nodes. When deploying, install the cluster management service, install the virtual IP detection tool, install the tool for periodically probing the liveness of the Postgres node, install the master-slave switch tool, and install the master-slave synchronization tool on the server where the master node is located. Install the cluster management service, install the virtual IP detection and binding tool, install the tool for periodically probing the liveness of the Postgres node, install the master-slave switch tool, and install the master-slave synchronization tool on the server where the slave node is located; start the tool for periodically probing the liveness of the Postgres tool and start the master-slave synchronization tool. The slave nodes synchronize the data of the master node through the master-slave synchronization tool. Generate SSH (Secure Shell) key pairs on the servers where the master node and the slave nodes are located respectively, and distribute the public key of each server to other servers to achieve passwordless SSH login. For example, distribute the public key of each server to the ~ / .ssh / authorized_keys file of other servers to achieve passwordless SSH login.

[0069] In this embodiment, the database cluster management method includes steps S11 to S13:

[0070] Step S11, monitor the running status of the first master server node.

[0071] It should be noted that the first master server node refers to the initial master node in the database cluster. All data write operations (such as INSERT, UPDATE, DELETE) and scheduling requests from clients are first sent to the master node. The running status of the first master server node

[0072] Specifically, a database monitoring tool or plugin is used to continuously monitor the running status of the master node in the database cluster, such as monitoring whether the server node is online.

[0073] Step S12: When the running status of the first master server node shows a running disconnection, obtain the node status of the slave server node cluster.

[0074] It should be noted that the slave server node cluster refers to a number of slave nodes in the database cluster. It receives change records of data from the master node and stores these changes in the database. If the master node fails, the slave node can take over the role of the master node and continue to process client requests.

[0075] Specifically, when the monitoring tool detects that the first master server node has a running disconnection, the nodes in the slave server node cluster will attempt to reconnect to the master node's server. When the connection times out or fails, the status and configuration information of the node databases in the slave server node cluster are detected.

[0076] Step S13: Based on the node status of the slave server node cluster, determine the second master server node from the slave server node cluster through a promotion algorithm.

[0077] It should be noted that the promotion algorithm means that when the first master server node has a disconnection during operation, the device will re-elect a new master node according to the status and configuration information of the servers where the slave nodes in the slave server node cluster are located. During the election process, each node will participate in the election according to its own status and configuration, and finally determine the new master node.

[0078] In addition, it should be noted that the second master server node refers to the new master node promoted from the slave server node cluster through the promotion algorithm after the first master server node is disconnected.

[0079] Specifically, perform an active state detection on the slave server node cluster to obtain a list of active nodes; based on the list of active nodes, perform node probing on the slave server node cluster to obtain the data replication progress of the slave server node cluster replicating data synchronously from the first master server node, and obtain a replication progress sorting table of the slave server node cluster; sort the preset weights of the slave server node cluster to obtain a weight sorting table of the slave server node cluster; based on the replication progress sorting table and the weight sorting table, determine the second master server node.

[0080] Through the above solution in this embodiment, by determining a new master server node through a voting algorithm among the slave server nodes, automatic switching between the master and slave server nodes is realized, and the technical problem that the database deployed in the single-point mode cannot be used during a failure is solved.

[0081] Based on the above implementation solution, in a feasible implementation manner, the step of determining the second master server node from the slave server node cluster through a voting algorithm based on the node state of the slave server node cluster includes S21 to S24:

[0082] Step S21, perform an active state detection on the slave server node cluster to obtain a list of active nodes.

[0083] It should be noted that the list of active nodes is used to store the slave nodes that are currently active and available in the slave server node cluster.

[0084] Specifically, initialize an empty list to store the active nodes in the slave server node cluster, traverse the nodes in the slave server node cluster through the installed tool for probing the active Postgres nodes, detect the active state of the slave nodes, and obtain a list of active nodes.

[0085] Step S22, based on the list of active nodes, perform node probing on the slave server node cluster to obtain the data replication progress of the slave server node cluster replicating data synchronously from the first master server node, and obtain a replication progress sorting table of the slave server node cluster.

[0086] It should be noted that the replication progress sorting table refers to a sorting table obtained by calculating the difference between the current latest log sequence numbers recorded in the log records of the slave nodes and the first master server node in the slave server node cluster and sorting according to the size of the difference, which is used to measure the data synchronization progress of the slave nodes. The larger the difference, the slower the data synchronization rate; the smaller the difference, the faster the data synchronization rate.

[0087] Specifically, the slave nodes in the active node list are probed for liveness by a tool for probing the liveness of Postgres nodes, and the current latest log sequence number for synchronously updating data is obtained from the log records stored in the slave nodes. The current latest log sequence number of the slave nodes is compared with the latest log sequence number in the log records of the first master server node to obtain the difference in log sequence numbers between the two. The difference in log sequence numbers can reflect the data replication progress of the slave nodes replicating data from the first master server node. The larger the difference, the slower the data replication progress; the smaller the difference, the faster the data replication progress. A replication progress sorting table is obtained by sorting according to the difference.

[0088] Step S23: Sort the preset weights of the slave server node cluster to obtain a weight sorting table of the slave server node cluster.

[0089] It should be noted that the preset weight of the slave server node cluster refers to weight allocation based on the performance of the slave node servers. The better the performance, the higher the allocated weight value. For example, when the server performance of slave node B is better than that of slave node C, the preset weight of slave node B is greater than that of slave node C.

[0090] Specifically, weights are assigned to the slave nodes according to the performance of the slave nodes in the slave server node cluster, and the nodes in the slave server node cluster are sorted according to the preset weights to obtain a weight sorting table of the slave server node cluster.

[0091] Step S24: Determine the second master server node based on the replication progress sorting table and the weight sorting table.

[0092] Specifically, based on the replication progress sorting table, the first slave server node in the slave server node cluster is obtained; if the number of nodes of the first slave server node is equal to the first threshold, the first slave server node is used as the second master server node; if the number of nodes of the first slave server node is greater than the first threshold, the second master server node is determined from the first slave server nodes based on the weight sorting table.

[0093] Through the above solution in this embodiment, by obtaining the data replication progress and selecting the slave nodes with a higher data synchronization progress as candidate master nodes, the consistency and integrity of data are ensured to the greatest extent when switching the master server; by sorting the preset weights of the slave server node cluster and considering factors such as node performance and load, multiple dimensions can be comprehensively considered when selecting the second master server node to achieve load balancing.

[0094] Based on the above implementation solutions, in a feasible implementation manner, the step of probing the slave server node cluster based on the active node list includes S31 to S32:

[0095] Step S31, if the number of slave server nodes in the active node list is equal to the first threshold, then use the slave server nodes in the active node list as the second master server nodes.

[0096] It should be noted that the first threshold is the numerical value 1.

[0097] Specifically, when the number of slave server nodes in the active node list is equal to 1, it means that only one slave node is active and connectable at this time. Then, this unique slave node is used as the second master server node. For example, if there is only slave node B in the active node list, it means that only slave node B is active and connectable at this time, and slave node B is used as the new master node.

[0098] Step S32, if the number of slave server nodes in the active node list is greater than the first threshold, then probe the slave server node cluster based on the active node list.

[0099] Specifically, when the number of slave server nodes in the active node list is greater than or equal to 1, it means that more than one slave node is active and connectable at this time. It is necessary to elect a new master node from several slave nodes through an election algorithm, probe the slave nodes in the active node list, and obtain the data replication progress between the slave nodes and the first master server node.

[0100] Based on the above implementation solutions, in a feasible implementation manner, the step of determining the second master server node based on the replication progress sorting table and the weight sorting table includes S41 to S43:

[0101] Step S41, based on the replication progress sorting table, obtain the first slave server node in the slave server node cluster.

[0102] Specifically, after generating the replication progress sorting table, select the slave node with the smallest difference in the replication progress sorting table as the first slave server node.

[0103] Step S42, if the number of nodes of the first slave server node is equal to the first threshold, then use the first slave server node as the second master server node.

[0104] Specifically, when the number of nodes of the first slave server node is equal to 1, it indicates that there is only one slave node with the fastest replication progress at this time. Then, this slave node is used as the second master server node.

[0105] Step S43, if the number of nodes of the first slave server node is greater than the first threshold, determine the second master server node from the first slave server nodes based on the weight sorting table.

[0106] Specifically, when the number of nodes of the first slave server node is greater than 1, it indicates that there is more than one slave node with the fastest replication progress at this time. Select the slave node with a larger weight value as the new master node according to the weight sorting table. When the replication progress and weight value of the slave node with the smallest difference are equal, randomly select a slave node as the new master node, that is, the second master server node.

[0107] For example, assume there is a first master server node A, and there are three slave nodes B, C, and D in the slave server node cluster. If the current latest log sequence number in the first master server node A is 100. In one case, the data replication progress of the three slave nodes is different. Assume the current latest log sequence numbers of the three slave nodes B, C, and D in the slave server node cluster are 98, 97, and 96 respectively. Then at this time, the data replication progress of the slave node B is the most, so the slave node B is selected as the new master node, that is, the second master server node. In another case, there is more than one slave node with the fastest replication progress among the data replication progress of the three slave nodes. Assume the current latest log sequence numbers of the three slave nodes B, C, and D in the slave server node cluster are 98, 98, and 96 respectively. Then the data replication progress of the slave nodes B and C is the highest and the same. Continue to compare the weights of the slave nodes B and C. Assume the weight of the slave node B is 110 and the weight of the slave node C is 100. Then the weight of B is greater than that of C, and the slave node B is selected as the new master node, that is, the slave node B is determined as the second master server node; assume the weight assignments of the slave nodes B and C are also equal, then randomly select one of the slave nodes B and C as the second master server node.

[0108] Based on the above implementation solutions, in a feasible implementation manner, after the step of determining the second master server node based on the replication progress sorting table and the weight sorting table, steps S51 to S54 are further included:

[0109] Step S51, perform an active state detection on the first master server node to obtain a state detection result of the first master server node.

[0110] Specifically, the active state of the first primary server node is detected by the tool installed on the probing Postgres node to check whether the current disconnection of the first primary server node has been restored to normal. For example, a detection request (such as a heartbeat packet, a ping command, or other custom detection packets) is sent to the first primary server node; a timeout timer is set and waiting for the response from the first primary server node; based on whether a response is received and the content of the response (such as a status code, a timestamp, etc.), the state of the first primary server node is judged, and the result of the state detection is recorded.

[0111] Furthermore, a detection for preventing network split-brain is performed on the server where the first primary server node is located to check whether there are still surviving nodes. If there are, it is regarded as a network split-brain, and then the second primary server node is abandoned.

[0112] Step S52, when the state detection result indicates that the node is alive, abandon the second primary server node and wait for the first primary server node to recover.

[0113] Specifically, if the state detection result of the first primary server node is "node alive" (i.e., a normal response is received), it indicates that the first primary server node is currently alive. Then, further operations on the second primary server node are abandoned, and wait for the first primary server node to return to normal.

[0114] Step S53, when the state detection result indicates that the node is down, perform node probing on the second primary server node through the slave server node cluster to obtain the node probing result of the second primary server node.

[0115] Specifically, if the state detection result of the first primary server node is "node down" (i.e., no response is received or the response is abnormal), it indicates that the current first primary server node is still in a down state. Then, the slave nodes in the slave server node cluster will probe the second primary server node to judge whether most of the slave nodes are alive, and obtain the node probing result of the second primary server node.

[0116] For example, there are slave nodes B, C, and D in the slave server node cluster. It is determined that C is the second primary server node, and it is determined that slave nodes B and D are alive nodes. They need to probe C to ensure that C can normally receive requests from nodes B and D. Nodes B and D will respectively send detection requests to node C. These requests may contain specific data or instructions for checking the response ability of node C; nodes B and D will wait for the response from node C. This waiting time usually has a preset threshold. If no response is received within this time, it is considered that node C may be unavailable; according to the response situation of node C, nodes B and D will judge whether node C is alive. If node C responds to the detection request within the specified time, then it is considered alive; otherwise, it may be considered unavailable.

[0117] Step S54 determines the election result of the second primary server node based on the node liveness detection result.

[0118] Specifically, when the node liveness detection result is less than half of the number of nodes in the slave server node cluster, the election of the second primary server node fails; when the node liveness detection result is greater than or equal to half of the number of nodes in the slave server node cluster, it is determined that the election of the second primary server node is successful, and the data synchronization target of the slave server node cluster is switched from the first primary server node to the second primary server node.

[0119] Based on the above implementation solutions, in a feasible implementation manner, the step of determining the election result of the second primary server node based on the node liveness detection result includes S61 - S62:

[0120] Step S61, when the node liveness detection result is less than half of the number of nodes in the slave server node cluster, the election of the second primary server node fails.

[0121] It should be noted that if there are a total of 4 nodes in the system (primary node A and slave nodes B, C, D), and the primary node A goes offline, then at least half of the remaining 3 nodes need to survive and reach an agreement to elect a new primary node. When there are 3 surviving slave nodes, half of the number of nodes is 3 / 2 = 1.5. Then, when the number of surviving nodes is less than half of the number of slave nodes, that is, less than 1.5, the election of the second primary server node fails.

[0122] Specifically, the nodes in the slave server node cluster other than the second primary server node detect the liveness of the second primary server node. When the number of surviving nodes is less than half of the number of nodes in the slave server node cluster, the election of the second primary server node fails. For example, when there are 3 slave nodes in the slave server node cluster, when slave nodes B and D detect the liveness of C, when the number of surviving nodes is less than 1.5, the election of the second primary server node fails because there is no majority of surviving nodes.

[0123] Step S62, when the node liveness detection result is greater than or equal to half of the number of nodes in the slave server node cluster, it is determined that the election of the second primary server node is successful, and the data synchronization target of the slave server node cluster is switched from the first primary server node to the second primary server node.

[0124] Specifically, the second master server node is probed for liveness from the nodes in the server node cluster other than the second master server node. When the number of surviving nodes is greater than or equal to half of the number of nodes in the slave server node cluster, the election of the second master server node is successful. The second master server node becomes the new master node, and the data synchronization target of the slave server node cluster is switched from the first master server node to the second master server node. For example, when there are 3 slave nodes in the slave server node cluster, when slave nodes B and D probe the liveness of C, and the number of survivors is greater than or equal to 1.5, the election of the second master server node is successful.

[0125] Based on the above implementation solutions, in a feasible implementation manner, after the step of determining that the election of the second master server node is successful and switching the data synchronization target of the slave server node cluster from the first master server node to the second master server node, the following steps S71 to S73 are further included:

[0126] Step S71: Probe the node status of the second master server node and the slave server node cluster, and obtain the node status of the nodes in the second master server node and the slave server node cluster.

[0127] It should be noted that the node status of the master node and the slave nodes will be continuously probed, and the node probing process will continuously probe for liveness. The essence of probing for liveness is to connect to all Postgres nodes and execute simple sql statements to verify whether the nodes are connectable and available, and obtain the health status of the Postgres cluster nodes, and maintain the node information according to the health status.

[0128] Specifically, probe the node status of the second master server node and the slave nodes in the slave server node cluster, and obtain the health status of the second master server node and the slave nodes in the slave server node cluster. The health status of the node server includes, but is not limited to, performance status (response time, throughput, etc.), resource utilization status, and the current load capacity of the server, etc.

[0129] Step S72: Based on the node status, distribute the scheduling requests for the second master server node to the second master server node and the slave server node cluster according to the dynamic load distribution adjustment strategy.

[0130] It should be noted that the dynamic load distribution adjustment strategy refers to distributing the scheduling requests for the master node to the master node and the slave nodes according to the current load capacity and performance of the servers of the master node and the slave nodes.

[0131] Specifically, according to the detected health status of the nodes, the scheduling requests sent by the client to the master node are dynamically adjusted and distributed to each node for scheduling execution based on the health status. Nodes with better health status are distributed more scheduling requests; nodes with relatively poor health status are distributed fewer scheduling requests. The server performance can be determined by the assigned weights.

[0132] Step S73, through the second master server node and the slave server node cluster, execute the scheduling request based on the read-write separation strategy.

[0133] It should be noted that the read-write separation strategy means that write operations are performed on the master node, and both the master node and the slave nodes can accept read operations sent by the client.

[0134] Specifically, the write requests in the scheduling request are only sent to the second master server node for execution, and the read requests in the scheduling request are distributed to any node in the second master server node and the slave server node cluster for execution.

[0135] Through the above solution in this embodiment, through node status detection, it is possible to understand the health status and load conditions of the nodes, dynamically adjust the load distribution strategy according to the node status, and intelligently distribute the scheduling requests to different nodes according to the current load capacity and health status of the nodes. This helps to prevent nodes from crashing due to overloading, and at the same time ensures that other nodes can make full use of their resources, achieving load balancing and improving the performance and efficiency of the overall system; through the execution of the read-write separation strategy, the read operations and write operations can be distributed to different nodes respectively, which helps to reduce the burden on the master server, improve the performance of write operations, and at the same time ensure that the slave servers can obtain the latest data in a timely manner, improving the consistency and reliability of read operations; the read-write separation also helps to prevent data loss or service interruption caused by a single point of failure.

[0136] Based on the above implementation scheme, in a feasible implementation manner, the method further includes S81 to S83:

[0137] Step S81, perform binding detection on the virtual address between the first master server node and the slave server node cluster to obtain the virtual address binding result.

[0138] It should be noted that the virtual address refers to the virtual IP, and the virtual IP is the IP provided by the entire Postgres cluster for external services. The virtual IP can automatically migrate. When the server where the virtual IP is located has an abnormal situation resulting in the virtual IP being inaccessible, the virtual IP will drift to the remaining nodes in the cluster to continue providing services, ensuring the high availability of the database cluster.

[0139] Specifically, there is a virtual IP between the first master server node and the slave server node cluster. The IP can be bound to any node. Generally, it is bound to the master node during initial deployment. In the same network segment, when a virtual IP needs to be bound, a binding detection is performed on the same virtual IP to detect whether the virtual IP has been bound to a node and obtain the virtual IP binding result.

[0140] Step S82: When the virtual address binding result is that the virtual address is already bound, the server virtual address binding between the first master server node and the slave server node cluster is released.

[0141] Specifically, when the virtual IP has been bound to the first master server node or a node in the slave server node cluster, the node that is currently binding the virtual IP will stop and abandon the binding to prevent virtual IP contention in the same network segment.

[0142] Step S83: When the virtual address binding result is that the virtual address is not bound, server virtual address binding is performed based on the address binding request sequence of the servers between the first master server node and the slave server node cluster.

[0143] Specifically, if the virtual IP is not bound to the primary server node or a node in the slave server node cluster, it means that the virtual IP is currently available for binding. This is because each node periodically detects the virtual IP to see if it can be bound. When it detects that it can be bound, it sends an address binding request to request virtual IP binding. Therefore, if the virtual IP is not currently bound, it is bound according to the order in which the virtual IP receives address binding requests, and is bound to the node that receives the request earliest.

[0144] This embodiment, through the above solution, detects the virtual IP address and checks whether it is already occupied by another server before attempting to bind the virtual IP address. This effectively avoids multiple servers in the same network segment competing for the same virtual IP address, thereby preventing IP conflicts. IP conflicts can cause serious problems such as network communication interruption and service unavailability. Therefore, avoiding IP conflicts is key to ensuring network stability and service continuity.

[0145] For better understanding, please refer to Figure 3 , Figure 3 Flowchart of the recommendation algorithm provided for the database cluster management method embodiment:

[0146] After the election starts, first, the active status of the nodes in the slave server node cluster is detected to obtain a list of active nodes. It is judged whether there is only one node in the list of active nodes. If there is only one node, then this node wins the election and becomes the new master node. If there is more than one node, then the subsequent election is carried out. When there is more than one node, it is judged whether the slave nodes in the list of active nodes have elected a new master node at this time (for example, there are three nodes B, C, and D. At this time, B and D have voted for C to become the new master node, and the number of voting nodes is more than half, then C has become the new master node at this time). If a new master node has been elected, the election ends. If there is no new master node, then the slave nodes in the list of active nodes are probed for liveness. The slave nodes are probed for liveness to obtain information about the slave nodes, view the log sequence number (LSN) in the write-ahead log (WAL) of the slave nodes, and judge the latest sequence number among the log sequence numbers of all slave nodes. The slave nodes without the latest sequence number exit the election, and the slave nodes with the latest sequence number proceed with the subsequent election. It is judged whether the write-ahead log of the slave nodes with the latest sequence number has stopped. When the log stops, it means that the slave node has stopped synchronizing with the terminal, so it exits the election. If the write-ahead log of this slave node has not stopped, it means that this slave node is still synchronizing data. If there are more than one slave nodes with the latest log sequence number, the new master node is determined according to the assigned weights. The larger the weight value, the better the performance of the node server. When more than one slave node is updated to the latest log sequence number, the slave node with the largest weight is selected as the new master node. After the new master node is elected, the original master node is probed for liveness to check whether there is a process for the original master node. If there is a process, it means that the original master node is still alive, so the new master node is abandoned and the election fails. If there is no process, it means that the original master node has dropped off the line, the election is completed, and the new master node replaces the original master node.

[0147] It should be noted that the above examples are only for understanding the present application and do not constitute a limitation on the database cluster management method of the present application. Based on this technical concept, more forms of simple transformation are within the protection scope of the present application.

[0148] The present application also provides a database cluster management device. Please refer to Figure 4 , the database cluster management device includes:

[0149] A status monitoring module 401, configured to monitor the running status of the first master server node;

[0150] A status acquisition module 402, configured to obtain the node status of the slave server node cluster when the running status of the first master server node has a running disconnection;

[0151] A node determination module 403, configured to determine a second primary server node from the slave server node cluster based on the node status of the slave server node cluster through an election algorithm.

[0152] The database cluster management device provided by this application adopts the database cluster management method in the above embodiment, and can solve the technical problem that the database deployed in the single-point mode cannot be used when switching the database due to a failure. Compared with the prior art, the beneficial effects of the database cluster management device provided by this application are the same as those of the database cluster management method provided by the above embodiment, and other technical features in the database cluster management device are the same as those disclosed in the method of the above embodiment, and will not be elaborated here.

[0153] This application provides a database cluster management device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the database cluster management method in the first embodiment above.

[0154] Next, refer to Figure 5 , which shows a schematic structural diagram of a database cluster management device suitable for implementing the embodiments of this application. The database cluster management device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistant), PADs (Portable Application Description: tablet computers), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The database cluster management device shown is only an example, and should not impose any limitation on the functions and usage scope of the embodiments of this application.

[0155] As Figure 5As shown in the figure, the database cluster management device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the database cluster management device are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the database cluster management device to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a database cluster management device with various systems, it should be understood that it is not required to implement or have all the systems shown. Instead, more or fewer systems can be implemented or had.

[0156] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above functions defined in the methods of the embodiments disclosed in the present application are executed.

[0157] The database cluster management device provided by the present application adopts the database cluster management method in the above embodiments, and can solve the technical problem that the database deployed in the single-point mode cannot be used when switching the database in case of a failure. Compared with the prior art, the beneficial effects of the database cluster management device provided by the present application are the same as those of the database cluster management method provided by the above embodiments, and other technical features in this database cluster management device are the same as those disclosed in the method of the previous embodiment, and will not be elaborated here.

[0158] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0159] As described above, the above are only specific embodiments of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application, and all of them should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

[0160] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the database cluster management method in the above embodiments.

[0161] The computer-readable storage medium provided by this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or combined with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0162] The above computer-readable storage medium can be included in the database cluster management device; or it can exist separately without being assembled into the database cluster management device.

[0163] The above computer-readable storage medium carries one or more programs, which, when executed by the database cluster management device, cause the database cluster management device to: monitor the operating status of the first master server node; when the operating status of the first master server node experiences an operating disconnection, obtain the node status of the slave server node cluster; and based on the node status of the slave server node cluster, determine a second master server node from the slave server node cluster through an election algorithm.

[0164] Computer program code for performing the operations of the present application may be written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0165] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

[0166] The modules described in the embodiments of the present application may be implemented in software or in hardware. In some cases, the name of the module does not constitute a limitation on the unit itself.

[0167] The readable storage medium provided by this application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for executing the above database cluster management method, and can solve the technical problem that the database deployed in the single-point mode cannot be used when switching the database due to a failure. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by this application are the same as those of the database cluster management method provided by the above embodiments, and will not be elaborated here.

[0168] This application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the steps of the database cluster management method as described above.

[0169] The computer program product provided by this application can solve the technical problem that the database deployed in the single-point mode cannot be used when switching the database due to a failure. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as those of the database cluster management method provided by the above embodiments, and will not be elaborated here.

[0170] The above are only some embodiments of this application, and thus do not limit the patent scope of this application. Any equivalent structural transformation made by using the content of the specification and drawings of this application under the technical concept of this application, or any direct / indirect application in other related technical fields, is included in the patent protection scope of this application.

Claims

1. A method for managing a database cluster, characterized in that, The method includes: Monitoring the running status of the first master server node; When the running status of the first master server node shows a running disconnection, obtaining the node status of the slave server node cluster; Based on the node status of the slave server node cluster, determining a second master server node from the slave server node cluster through a promotion algorithm.

2. The method according to claim 1, wherein The step of determining a second master server node from the slave server node cluster based on the node status of the slave server node cluster through a promotion algorithm includes: Performing an active status detection on the slave server node cluster to obtain an active node list; Based on the active node list, performing node liveness detection on the slave server node cluster, obtaining the data replication progress of the slave server node cluster that synchronously replicates data from the first master server node, and obtaining a replication progress sorting table of the slave server node cluster; Sorting the preset weights of the slave server node cluster to obtain a weight sorting table of the slave server node cluster; Based on the replication progress sorting table and the weight sorting table, determining the second master server node.

3. The method according to claim 2, wherein The step of performing node liveness detection on the slave server node cluster based on the active node list includes: If the number of slave server nodes in the active node list is equal to the first threshold, using the slave server nodes in the active node list as the second master server node; If the number of slave server nodes in the active node list is greater than the first threshold, performing node liveness detection on the slave server node cluster based on the active node list.

4. The method according to claim 3, wherein The step of determining the second master server node based on the replication progress sorting table and the weight sorting table includes: Based on the replication progress sorting table, obtaining the first slave server node in the slave server node cluster; If the number of nodes of the first slave server node is equal to the first threshold, using the first slave server node as the second master server node; If the number of nodes of the first slave server node is greater than the first threshold, determining the second master server node from the first slave server nodes based on the weight sorting table.

5. The method according to claim 2, wherein After the step of determining the second master server node based on the replication progress sorting table and the weight sorting table, it further includes: Performing an active status detection on the first master server node to obtain a status detection result of the first master server node; When the status detection result is that the node is alive, abandoning the second master server node and waiting for the first master server node to recover; When the status detection result is that the node is disconnected, performing node liveness detection on the second master server node through the slave server node cluster to obtain a node liveness detection result of the second master server node; Based on the node liveness detection result, determining the election result of the second master server node.

6. The method according to claim 5, wherein The step of determining the election result of the second master server node based on the node liveness detection result includes: When the node liveness detection result is less than half of the number of nodes in the slave server node cluster, the election of the second master server node fails; When the node detection result is greater than or equal to half of the number of nodes in the slave server node cluster, it is determined that the second master server node is elected successfully, and the data synchronization target of the slave server node cluster is switched from the first master server node to the second master server node.

7. The method according to claim 6, wherein After determining that the election of the second master server node is successful and switching the data synchronization target of the slave server node cluster from the first master server node to the second master server node, the following steps may also be performed: Performing node status detection on the second master server node and the slave server node cluster to obtain node status of the second master server node and nodes in the slave server node cluster; Distributing the scheduling request for the second master server node to the second master server node and the slave server node cluster based on a dynamically adjusted load distribution strategy according to the node status; The scheduling request is executed based on a read-write separation strategy through the second master server node and the slave server node cluster.

8. The method according to claim 1, characterized in that, The method further comprises: Performing binding detection on the virtual addresses between the first master server node and the slave server node cluster to obtain a virtual address binding result; When the virtual address binding result is that the virtual address is already bound, releasing the server virtual address binding between the first master server node and the slave server node cluster; When the virtual address binding result is that the virtual address is not bound, server virtual address binding is performed based on the address binding request sequence of the servers between the first master server node and the slave server node cluster.

9. A database cluster management device, characterized in that, The device comprises: A status monitoring module, used to monitor the operating status of the first master server node; A status acquisition module is used to acquire the node status of the slave server node cluster when the running status of the first master server node is offline; The node determination module is used to determine the second master server node from the slave server node cluster through a recommendation algorithm based on the node status of the slave server node cluster.

10. A database cluster management device, characterized in that The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the database cluster management method according to any one of claims 1 to 8.

11. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the database cluster management method according to any one of claims 1 to 8 are implemented.

Images