A database cluster management method, device and network equipment

Abstract

The application provides a database cluster management method and device and network equipment, and relates to the technical field of databases.The method comprises the following steps: acquiring first information corresponding to a current master node of a database cluster; wherein the first information comprises at least one of the following: a server name, an Internet Protocol (IP) address and a gateway address; and performing a management operation on a node in the database cluster according to resource configuration information of the database cluster and the first information corresponding to the current master node; wherein the resource configuration information comprises the first information corresponding to a preconfigured master node, and the preconfigured master node is a master node configured for the database cluster.The scheme of the application solves the problem that the brain split emergency handling scheme in the prior art has a high cost and cannot meet the brain split emergency handling requirements of a database cluster deployed on a virtual machine or in the cloud.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a database cluster management method, apparatus, and network equipment. Background Technology

[0002] With the rise of open-source projects, open-source databases have gained widespread use. Among them, PostgreSQL is a very powerful and open-source relational database, often referred to as the most advanced open-source relational database. Its powerful features, coupled with the significant improvements in computing power and storage performance of modern computers, and the increasing maturity of cloud computing technology, have led to the widespread adoption of PostgreSQL in various enterprises. It is now common for an enterprise to have dozens or even hundreds of PostgreSQL instances or clusters.

[0003] PostgreSQL provides a native master-slave data replication technology, enabling the database to run on multiple servers in a master-slave mode. The master and slave databases form a database cluster. The master database provides read and write capabilities, while the slave databases provide read-only capabilities. The entire cluster provides database services through a VIP (Virtual IP Address), which must be mounted on the master node for the cluster to provide read and write services. When the master database providing read and write capabilities fails, the slave database needs to be promoted to the new master database, and the VIP needs to be switched to the new master database to ensure high availability. This ensures that applications can continue writing data to the new master node through the VIP, without affecting application operation and maximizing the transparency of the database cluster service to applications. However, since PostgreSQL itself does not provide automatic failover, manual commands are required when a failover is needed. This method is insufficient to meet the high availability requirements of applications, and manual failover is inefficient and has a significant impact on applications. Therefore, PostgreSQL databases require third-party software to achieve high availability. Currently, the most popular open-source software combination is Corosync + Pacemaker, which can implement master-slave data replication and automatic failover for PostgreSQL database clusters.

[0004] Database split-brain occurs when a database cluster experiences multiple master nodes due to network failures or other reasons, with the VIP (Virtual Private Server) simultaneously mounted on multiple master nodes, all providing read and write services. For example, a three-node cluster might split into two smaller clusters: one consisting of one node and the other of the remaining two nodes. After a split-brain event, application data may be arbitrarily written to the split smaller clusters, causing inconsistencies between the two clusters, resulting in corrupted and difficult-to-recover data. Therefore, database clusters must have reliable split-brain prevention solutions.

[0005] Currently, the mainstream anti-split-brain technology is implemented through shared storage and power cut-off of the host. Both of these solutions require hardware support and investment in related hardware equipment. If an enterprise deploys a large number of PostgreSQL database clusters, purchasing anti-split-brain hardware equipment will increase investment and maintenance costs significantly, as well as the difficulty of later maintenance work. Moreover, hardware equipment has a certain service life, and the failure rate and maintenance costs will increase over time.

[0006] In addition, with the prevalence of virtualization and cloud technologies, many enterprises use virtualization technology or cloud servers to deploy database clusters. However, it is difficult to prevent split-brain attacks on database clusters through hardware solutions in virtualization and the cloud.

[0007] In summary, existing solutions for preventing split-brain attacks in database clusters mainly rely on purchasing and deploying hardware, resulting in high investment and maintenance costs, and are insufficient to meet the split-brain attack prevention requirements of database clusters deployed on virtual machines or in the cloud. Summary of the Invention

[0008] The purpose of this invention is to provide a database cluster management method, apparatus, and network equipment, which solves the problems that existing database cluster split-brain emergency response solutions are costly and cannot meet the split-brain emergency response needs of database clusters deployed on virtual machines or in the cloud.

[0009] To achieve the above objectives, embodiments of the present invention provide a database cluster management method, applied to the first node in a database cluster, comprising:

[0010] Obtain the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, IP (Internet Protocol) address, and gateway address;

[0011] Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, management operations are performed on the nodes in the database cluster.

[0012] The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster.

[0013] Optionally, the step of performing management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node includes:

[0014] Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, determine whether the current master node is a pre-configured master node;

[0015] If the current master node is not a pre-configured master node, determine whether the first node is a pre-configured master node based on the resource configuration information;

[0016] Based on the judgment result, management operations are performed on the nodes in the database cluster.

[0017] Optionally, the step of performing management operations on the nodes in the database cluster based on the judgment result includes:

[0018] If the first node is not a pre-configured master node and is not the current master node, determine whether the first node is connected to the pre-configured master node;

[0019] When the first node is connected to the pre-configured master node, determine whether the read / write virtual IP address (VIP) is bound to the pre-configured master node;

[0020] When the read / write VIP is bound to the pre-configured master node, the first management operation is performed on the pre-configured master node;

[0021] The first management operation includes at least one of the following:

[0022] Instruct to shut down the first process on the pre-configured master node;

[0023] The instruction is to unbind the read / write VIP from the pre-configured master node.

[0024] Optionally, after performing the first management operation on the pre-configured master node, the method further includes:

[0025] Determine whether the pre-configured master node is in master node status;

[0026] When the pre-configured master node is in the master node state, the first management operation is performed on the pre-configured master node.

[0027] Optionally, it may also include at least one of the following:

[0028] If the first node is the current master node, a first prompt message is sent, which is used to indicate that the master node of the database cluster has been switched to the first node;

[0029] If the first node is not connected to the pre-configured master node, a second prompt message is sent, which is used to indicate that the pre-configured master node has experienced a network failure.

[0030] If the read / write VIP is not bound to the pre-configured master node, a first status information is recorded in the log, which indicates that the read / write VIP is not bound to the pre-configured master node.

[0031] Optionally, the step of performing management operations on the nodes in the database cluster based on the judgment result includes:

[0032] If the first node is a pre-configured master node, determine whether the first node is a slave node;

[0033] Based on the judgment result, perform management operations on the first node.

[0034] Optionally, performing management operations on the first node based on the judgment result includes:

[0035] When the first node is the master node, the second management operation is performed on the first node;

[0036] The second management operation includes at least one of the following:

[0037] Shut down the first process on the first node;

[0038] Remove the binding between the read / write VIP and the first node.

[0039] Optionally, performing management operations on the first node based on the judgment result includes:

[0040] If the first node is a slave node, determine whether the read / write VIP is bound to the first node;

[0041] If the read / write VIP is bound to the first node, then unbind the read / write VIP from the first node.

[0042] Optionally, the method further includes:

[0043] A third prompt message is sent, which prompts the master node of the database cluster to switch to a node other than the pre-configured master node.

[0044] Optionally, the method further includes:

[0045] If the first node is neither the master node nor the slave node, a fourth prompt message is sent, which is used to indicate that the first node is in an abnormal state.

[0046] To achieve the above objectives, embodiments of the present invention provide a database cluster management device, applied to a first node in a database cluster, comprising:

[0047] The acquisition module is used to acquire the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, Internet Protocol IP address, and gateway address;

[0048] The processing module is used to perform management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node;

[0049] The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster.

[0050] Optionally, the processing module includes:

[0051] The first processing submodule is used to determine whether the current master node is a pre-configured master node based on the resource configuration information of the database cluster and the first information corresponding to the current master node.

[0052] The second processing submodule is used to determine whether the first node is a pre-configured master node based on the resource configuration information when the current master node is not a pre-configured master node.

[0053] The third processing submodule is used to perform management operations on the nodes in the database cluster based on the judgment result.

[0054] Optionally, the third processing submodule includes:

[0055] The first processing unit is configured to determine whether the first node is connected to the pre-configured master node when the first node is not a pre-configured master node and the first node is not the current master node.

[0056] The second processing unit is used to determine whether the read / write virtual IP address (VIP) is bound to the pre-configured master node when the first node is connected to the pre-configured master node.

[0057] The third processing unit is used to perform a first management operation on the pre-configured master node when the read / write VIP is bound to the pre-configured master node;

[0058] The first management operation includes at least one of the following:

[0059] Instruct to shut down the first process on the pre-configured master node;

[0060] The instruction is to unbind the read / write VIP from the pre-configured master node.

[0061] Optionally, the third processing submodule further includes:

[0062] The fourth processing unit is used to determine whether the pre-configured master node is in master node status;

[0063] The fifth processing unit is used to perform the first management operation on the pre-configured master node when the pre-configured master node is in the master node state.

[0064] Optionally, the device further includes:

[0065] The first sending module is used to send a first prompt message when the first node is the current master node, the first prompt message being used to indicate that the master node of the database cluster has been switched to the first node;

[0066] The second sending module is used to send a second prompt message when the first node is not connected to the pre-configured master node. The second prompt message is used to indicate that the pre-configured master node has experienced a network failure.

[0067] The first recording module is used to record first status information in the log when the read / write VIP is not bound to the pre-configured master node. The first status information is used to indicate that the read / write VIP is not bound to the pre-configured master node.

[0068] Optionally, the third processing submodule includes:

[0069] The sixth processing unit is used to determine whether the first node is a slave node when the first node is a pre-configured master node;

[0070] The seventh processing unit is used to perform management operations on the first node based on the judgment result.

[0071] Optionally, the seventh processing unit includes:

[0072] The first processing subunit is configured to perform a second management operation on the first node when the first node is the master node.

[0073] The second management operation includes at least one of the following:

[0074] Shut down the first process on the first node;

[0075] Remove the binding between the read / write VIP and the first node.

[0076] Optionally, the seventh processing unit includes:

[0077] The second processing subunit is used to determine whether the read / write VIP is bound to the first node when the first node is a slave node.

[0078] The unbinding subunit is used to unbind the read / write VIP from the first node when the read / write VIP is bound to the first node.

[0079] Optionally, the device further includes:

[0080] The third sending module is used to send a third prompt message, which prompts the master node of the database cluster to switch to a node other than the pre-configured master node.

[0081] Optionally, the device further includes:

[0082] The fourth sending module is used to send a fourth prompt message when the first node is neither the master node nor the slave node, the fourth prompt message being used to indicate that the first node is in an abnormal state.

[0083] To achieve the above objectives, embodiments of the present invention provide a network device, including a processor and a transceiver, wherein the processor is used for:

[0084] Obtain the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, Internet Protocol IP address, and gateway address;

[0085] Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, management operations are performed on the nodes in the database cluster.

[0086] The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster.

[0087] Optionally, when the processor performs management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node, it is specifically used for:

[0088] Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, determine whether the current master node is a pre-configured master node;

[0089] If the current master node is not a pre-configured master node, determine whether the first node is a pre-configured master node based on the resource configuration information;

[0090] Based on the judgment result, management operations are performed on the nodes in the database cluster.

[0091] Optionally, when the processor performs management operations on the nodes in the database cluster based on the judgment result, it is specifically used for:

[0092] If the first node is not a pre-configured master node and is not the current master node, determine whether the first node is connected to the pre-configured master node;

[0093] When the first node is connected to the pre-configured master node, determine whether the read / write virtual IP address (VIP) is bound to the pre-configured master node;

[0094] When the read / write VIP is bound to the pre-configured master node, the first management operation is performed on the pre-configured master node;

[0095] The first management operation includes at least one of the following:

[0096] Instruct to shut down the first process on the pre-configured master node;

[0097] The instruction is to unbind the read / write VIP from the pre-configured master node.

[0098] Optionally, the processor is further configured to:

[0099] Determine whether the pre-configured master node is in master node status;

[0100] When the pre-configured master node is in the master node state, the first management operation is performed on the pre-configured master node.

[0101] Optionally, the processor is further configured to:

[0102] If the first node is the current master node, a first prompt message is sent, which is used to indicate that the master node of the database cluster has been switched to the first node;

[0103] If the first node is not connected to the pre-configured master node, a second prompt message is sent, which is used to indicate that the pre-configured master node has experienced a network failure.

[0104] If the read / write VIP is not bound to the pre-configured master node, a first status information is recorded in the log, which indicates that the read / write VIP is not bound to the pre-configured master node.

[0105] Optionally, when the processor performs management operations on the nodes in the database cluster based on the judgment result, it is specifically used for:

[0106] If the first node is a pre-configured master node, determine whether the first node is a slave node;

[0107] Based on the judgment result, perform management operations on the first node.

[0108] Optionally, when the processor performs management operations on the first node based on the judgment result, it is specifically used for:

[0109] When the first node is the master node, the second management operation is performed on the first node;

[0110] The second management operation includes at least one of the following:

[0111] Shut down the first process on the first node;

[0112] Remove the binding between the read / write VIP and the first node.

[0113] Optionally, when the processor performs management operations on the first node based on the judgment result, it is specifically used for:

[0114] If the first node is a slave node, determine whether the read / write VIP is bound to the first node;

[0115] If the read / write VIP is bound to the first node, then unbind the read / write VIP from the first node.

[0116] Optionally, the processor is further configured to:

[0117] A third prompt message is sent, which prompts the master node of the database cluster to switch to a node other than the pre-configured master node.

[0118] Optionally, the processor is further configured to:

[0119] If the first node is neither the master node nor the slave node, a fourth prompt message is sent, which is used to indicate that the first node is in an abnormal state.

[0120] To achieve the above objectives, embodiments of the present invention provide a network device, including a transceiver, a processor, a memory, and a program or instructions stored in the memory and executable on the processor; when the processor executes the program or instructions, it implements the database cluster management method described above.

[0121] To achieve the above objectives, embodiments of the present invention provide a readable storage medium having a program or instructions stored thereon, which, when executed by a processor, implement the steps in the database cluster management method described above.

[0122] The beneficial effects of the above-described technical solution of the present invention are as follows:

[0123] The method of this invention, by obtaining relevant information of the current master node of the database cluster and combining it with the resource configuration information of the database cluster, can determine the corresponding management operations to manage the nodes of the database cluster, thereby enabling timely detection of database split-brain phenomena and timely implementation of corresponding measures. To a certain extent, it can prevent the occurrence of cluster split-brain situations and ensure data consistency and integrity. It does not require additional hardware to prevent split-brain, requires less investment, reduces operation and maintenance costs, and meets the requirements for preventing split-brain in virtualized or cloud-deployed database clusters. Attached Figure Description

[0124] Figure 1 This is a flowchart of a database cluster management method according to an embodiment of the present invention;

[0125] Figure 2 This is a diagram of the PostgreSQL cluster architecture in an embodiment of the present invention;

[0126] Figure 3 This is a flowchart illustrating the execution of the fence_check code in an embodiment of the present invention.

[0127] Figure 4 This is a structural diagram of the database cluster management device according to an embodiment of the present invention;

[0128] Figure 5 This is a structural diagram of a network device according to an embodiment of the present invention;

[0129] Figure 6 This is a structural diagram of a network device according to another embodiment of the present invention. Detailed Implementation

[0130] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0131] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of the invention. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0132] In various embodiments of the present invention, it should be understood that the sequence number of each process described below does not imply 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 invention.

[0133] In addition, the terms "system" and "network" are often used interchangeably in this article.

[0134] In the embodiments provided in this application, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0135] like Figure 1 As shown, an embodiment of the present invention provides a database cluster management method applied to the first node in a database cluster, comprising:

[0136] Step 101: Obtain the first information corresponding to the current master node of the database cluster; wherein the first information includes at least one of the following: server name, Internet Protocol IP address, and gateway address.

[0137] It should be noted that the server name is the server name of the server where the node resides, the IP address is the IP address of the server where the node resides, and the gateway address is the gateway address of the corresponding gateway for this database cluster. The Internet Protocol (IP) address and gateway address are used to detect the network connectivity status between the node and the gateway in the database cluster.

[0138] Step 102: Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, perform management operations on the nodes in the database cluster;

[0139] The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster.

[0140] In this embodiment, by obtaining relevant information about the current master node of the database cluster and combining it with the resource configuration information of the database cluster, the corresponding management operations can be determined to manage the nodes of the database cluster. This allows for the timely detection of database split-brain phenomena and the implementation of corresponding measures, which can, to a certain extent, prevent the occurrence of cluster split-brain and ensure data consistency and integrity. No additional hardware for preventing split-brain is required, resulting in low investment and reduced operation and maintenance costs. This meets the requirements for preventing split-brain in virtualized or cloud-deployed database clusters.

[0141] As an optional embodiment of the present invention, the database cluster management method provided by the present invention can be implemented by code. For example, the embodiments of the present invention can use the open-source software Pacemaker and Corosync as the basic software for cluster management to implement the basic functions of cluster management, and use the self-developed RA (Resource Agent) fence_check to implement the cluster split-brain prevention function (i.e., timely detection of cluster split-brain phenomena and timely countermeasures to stop the split-brain phenomenon). Specifically, by writing code that conforms to the Resource Agent (RA) specification of the Pacemaker cluster resource management component (i.e., fence_check code), resources are registered in the open-source cluster management component Pacemaker and run automatically as needed.

[0142] In this way, the fence_check code runs as a resource in the database cluster, achieving the split-brain prevention function without relying on distributed arbitration software such as ZooKeeper or ETCD. This allows the split-brain prevention function of the PostgreSQL database cluster to be implemented using code, which is small in size and easy to understand. The split-brain prevention code can also be modified according to different scenario requirements. In addition, it can be deployed and implemented on a database cluster with any number of nodes, and new nodes can be added online in real time without affecting the normal operation of the existing cluster.

[0143] Existing database anti-split-brain mechanisms are primarily implemented through hardware (mainly referring to shared disks and power-off devices). In large-scale deployments, hardware costs are high, as are subsequent hardware maintenance costs. In contrast, the fence_check code in this invention does not require deployment on additional servers or virtual machines, eliminating the need for additional anti-split-brain hardware, resulting in lower deployment costs, less investment, and reduced operational costs.

[0144] It should be noted that cloud and virtualization technologies are currently very popular, and most database clusters are deployed on virtualized or cloud-based servers. In such scenarios, hardware-based split-brain protection devices cannot be used. This invention can be deployed via code on physical machines, virtual machines, and the cloud, solving the problem that hardware-based split-brain protection devices cannot be used on PostgreSQL database clusters deployed in virtualized or cloud environments. It is applicable to PostgreSQL clusters deployed on physical machines, virtual machines, and cloud servers, meeting deployment requirements in multiple scenarios.

[0145] It should also be noted that the embodiments of the present invention can be written using SHELL scripts, which have a small amount of code, are simple and easy to understand, and can be quickly understood and mastered by cluster administrators. They can also be deployed quickly using some automated deployment tools, such as ANSIBLE and PUPPET, and can be modified according to specific needs, making management convenient.

[0146] Optionally, the step of performing management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node includes:

[0147] (i) Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, determine whether the current master node is a pre-configured master node.

[0148] It should be noted that, based on the resource configuration information of the database cluster, the first information corresponding to the pre-configured master node can be obtained. Therefore, by comparing the server name corresponding to the pre-configured master node with the server name corresponding to the current master node, it can be determined whether the current master node is the pre-configured master node. If they match, then the current master node is determined to be the pre-configured master node.

[0149] (ii) If the current master node is not a pre-configured master node, determine whether the first node is a pre-configured master node based on the resource configuration information;

[0150] (iii) Based on the judgment result, perform management operations on the nodes in the database cluster.

[0151] In this embodiment, by determining whether the current master node is a pre-configured master node, it can be determined whether a failover has occurred in the cluster (i.e., the database cluster). For example, if the current master node is not a pre-configured master node, it indicates that a failover may have occurred in the cluster, and it is necessary to further determine whether a cluster partition has occurred, so as to take corresponding measures in a timely manner to avoid cluster split-brain and ensure the consistency and integrity of the entire database cluster data.

[0152] Optionally, the step of performing management operations on the nodes in the database cluster based on the judgment result includes:

[0153] If the first node is not a pre-configured master node and is not the current master node, determine whether the first node is connected to the pre-configured master node;

[0154] When the first node is connected to the pre-configured master node, determine whether the read / write virtual IP address (VIP) is bound to the pre-configured master node;

[0155] When the read / write VIP is bound to the pre-configured master node, the first management operation is performed on the pre-configured master node;

[0156] The first management operation includes at least one of the following:

[0157] Instruct to shut down the first process on the pre-configured master node;

[0158] The instruction is to unbind the read / write VIP from the pre-configured master node.

[0159] In this embodiment, the first node can test its network connection status with the pre-configured master node. If the first node can connect to the pre-configured master node, it further determines whether the read-write VIP is still running on the pre-configured master node, that is, whether the Master VIP (i.e., the read-write VIP) is mounted on the pre-configured master node, in order to determine whether the cluster has experienced a split-brain scenario. If the read-write VIP is still running on the pre-configured master node, that is, if the read-write VIP is bound to the pre-configured master node, a first management operation is performed on the pre-configured master node to prevent the cluster from experiencing a split-brain scenario.

[0160] Optionally, after performing the first management operation on the pre-configured master node, the method further includes:

[0161] Determine whether the pre-configured master node is in master node status;

[0162] When the pre-configured master node is in the master node state, the first management operation is performed on the pre-configured master node.

[0163] In this embodiment, the result of performing the first management operation (i.e., the result of forcibly terminating the relevant processes on the pre-configured master node, etc.) can be reviewed until the read / write VIP of the faulty node is completely removed and the relevant PostgreSQL processes are stopped, thus avoiding cluster split-brain.

[0164] Optionally, the method further includes at least one of the following:

[0165] If the first node is the current master node, a first prompt message is sent, which is used to indicate that the master node of the database cluster has been switched to the first node;

[0166] If the first node is not connected to the pre-configured master node, a second prompt message is sent, which is used to indicate that the pre-configured master node has experienced a network failure.

[0167] If the read / write VIP is not bound to the pre-configured master node, a first status information is recorded in the log, which indicates that the read / write VIP is not bound to the pre-configured master node.

[0168] In this embodiment of the invention, all detections and operations can be recorded in logs, which can then be provided to operations and maintenance personnel for querying and tracing cluster anomaly records.

[0169] The database cluster management method provided in this invention is applicable to database clusters with different numbers of nodes. Cluster administrators can apply this method in different environments and clusters with different numbers of nodes. They can also use the problem diagnosis and logging functions in this method to facilitate the investigation and analysis of cluster master-slave switching or failure causes. This solves the problems of low operation and maintenance efficiency and excessive burden on cluster administrators caused by repetitive operation and maintenance, and greatly improves the management efficiency and system stability of database clusters.

[0170] Optionally, the step of performing management operations on the nodes in the database cluster based on the judgment result includes:

[0171] If the first node is a pre-configured master node, determine whether the first node is a slave node;

[0172] Based on the judgment result, perform management operations on the first node.

[0173] In this embodiment, if the first node is a pre-configured master node, it is necessary to determine whether the first node is a slave node, a master node, or neither a master node nor a slave node, and further determine the service status of the first node based on the determination result, thereby performing corresponding management operations to avoid cluster split-brain.

[0174] Optionally, performing management operations on the first node based on the judgment result includes:

[0175] When the first node is the master node, the second management operation is performed on the first node;

[0176] The second management operation includes at least one of the following:

[0177] Shut down the first process on the first node;

[0178] Remove the binding between the read / write VIP and the first node.

[0179] It should be noted that if the first node is not a slave node, it can be further determined whether the first node is the master node. If the first node is the master node, a second management operation can be performed on the first node to avoid a split-brain scenario in the cluster.

[0180] Optionally, performing management operations on the first node based on the judgment result includes:

[0181] If the first node is a slave node, determine whether the read / write VIP is bound to the first node;

[0182] If the read / write VIP is bound to the first node, then unbind the read / write VIP from the first node.

[0183] In other words, the first node is not the master node, but the Master VIP is still mounted on the first node. In this case, the operations and maintenance personnel can be notified of the abnormal situation and the Master VIP on the first node can be deleted.

[0184] Optionally, the method further includes:

[0185] A third prompt message is sent, which prompts the master node of the database cluster to switch to a node other than the pre-configured master node.

[0186] For example, you can notify the operations and maintenance personnel that the first node is the designated master node, but the master node has been switched to a new node.

[0187] Optionally, the method further includes:

[0188] If the first node is neither the master node nor the slave node, a fourth prompt message is sent, which is used to indicate that the first node is in an abnormal state.

[0189] It should be noted that if the first node is not a slave node, it can be further determined whether the first node is the master node. If the first node is the master node, a fourth notification message can be sent via email or other means to notify the operations and maintenance personnel of the cluster status anomaly.

[0190] Furthermore, some software designed to prevent split-brain scenarios typically requires a database cluster with at least three odd-numbered nodes (3, 5, 7, etc.), with the master node elected through a majority vote. This solution avoids this limitation, as there is no odd-number restriction on the number of database nodes in the cluster. Moreover, the database cluster management method provided in this invention allows the deployment of a PostgreSQL cluster with only two nodes, saving at least one server resource compared to a cluster requiring at least three nodes. Furthermore, this invention eliminates the need to detect the status of slave nodes or use a voting process within the cluster to elect the database master node.

[0191] The application of the embodiments of the present invention will be described below with reference to specific scenarios:

[0192] In an optional embodiment of the present invention, open-source software Pacemaker and Corosync can be used as the basic cluster management software to implement the basic functions of cluster management. Corosync is responsible for cluster communication and membership management, while Pacemaker is responsible for cluster resource management. This enables automatic master-slave failover and VIP migration of database instances within the cluster. The overall architecture diagram is shown below. Figure 2 As shown.

[0193] The Pacemaker pre-configured resources used by the cluster include PostgreSQL, IPaddr2, and ping. The Resource Agent (RA) for PostgreSQL is pgsql, which is responsible for starting, stopping, monitoring, and failover of PostgreSQL.

[0194] During initial cluster startup, PostgreSQL compares the online transaction log positions of all nodes and identifies the node with the latest online transaction log as the master node. Other nodes act as slave nodes, connecting to the master node via read-write VIPs to replicate the transaction log. Read-write VIPs are bound to the master node, while read-only VIPs are bound to slave nodes. Applications only need to access the corresponding VIP without needing to know which specific node to access.

[0195] After the cluster starts, pgsql resources monitor the health of the PostgreSQL service by connecting to the database instance on each node: when pgsql detects a failure in the PostgreSQL service, it reports it to Pacemaker, which then takes appropriate action.

[0196] If the PostgreSQL process fails, try restarting PostgreSQL and incrementing the fail-count on that node. When the fail-count reaches 3, stop allocating PostgreSQL resources to this node.

[0197] If the failure occurs on the master node, the slave node that is synchronously replicating will be promoted to master, i.e., a failover will be initiated.

[0198] PostgreSQL resources continuously monitor the replication health of slave nodes and select one as the real-time synchronization node. Under synchronous replication, only real-time synchronization slave nodes are eligible to become candidate master nodes, ensuring no data loss after failover. When a real-time synchronization slave node fails, to avoid impacting the availability of the database cluster, PostgreSQL resources temporarily switch from synchronous to asynchronous replication to prevent write operations on the master node from hanging. If the failed slave node recovers or another healthy slave node becomes available, it switches back to synchronous replication, maximizing the real-time nature of data replication and the security of multiple data replicas.

[0199] In this cluster management configuration, this embodiment of the invention provides a split-brain prevention function for PostgreSQL database clusters. This prevents split-brain scenarios and double-write operations from occurring when Pacemaker synchronously upgrades slave nodes to new master nodes after cluster partitioning, while the old master node server still has PostgreSQL database processes and VIPs running. Figure 2 As shown, this embodiment of the invention can utilize the fence_check resource for arbitration to implement the database cluster management method provided by this embodiment. Specifically, each node's fence_check in the cluster will arbitrate against its own node. If a master node is determined to be abnormal, it will proactively stop the PostgreSQL, Corosync, and Pacemaker processes, and stop reading and writing the VIP, preventing dual-master scenarios and situations where the VIP is mounted on two database servers.

[0200] like Figure 3 As shown in the flowchart, an optional embodiment of the database cluster management method provided by the present invention is described in detail below:

[0201] S301: Pacemaker automatically calls the fence_check resource (i.e., the fence_check code) at regular intervals;

[0202] This invention can utilize a self-developed Resource Agent (RA) fence_check to implement split-brain prevention, meaning the fence_check resource can be used to implement the database cluster management method of this invention. This allows for timely detection and handling of split-brain situations when they occur, stopping related processes and VIPs, thereby preventing a cluster from having two PostgreSQL Masters and VIPs mounted on two nodes. This approach helps to mitigate the occurrence of split-brain scenarios and ensures data consistency and integrity.

[0203] It should be noted that the fence_check resource can be managed by Pacemaker and automatically invoked on a scheduled basis according to the configuration. As a database split-brain prevention resource, fence_check runs on each node in the database cluster and is automatically invoked in a loop according to the configured time interval.

[0204] The fence_check execution interval can be adjusted according to the parameter value set as needed, and can be as short as once per second.

[0205] S302: Determine if a master node exists in the cluster; here, the master node is the primary node.

[0206] If no, meaning it does not exist, execute S303; if yes, meaning it exists, execute S304.

[0207] Specifically, you can use the Pacemaker management tool to obtain the IP address and server name of the server where the Master node of the current database cluster is located.

[0208] S303: Cluster status is abnormal. Notify operations and maintenance personnel to repair the cluster.

[0209] It should be noted that the absence of a master node in the cluster indicates a cluster failure. The cluster status can be notified to operations and maintenance personnel via methods such as triggering emails.

[0210] S304: Is the current master node the set master node?

[0211] Yes, that is, if the current master node is the set master node, then execute S305;

[0212] No, that is, if the current master node is not the set master node, then execute S308.

[0213] S305: Determine if the current master node can connect to the gateway; if yes, proceed to S306; otherwise, proceed to S307.

[0214] S306: The log records indicate that the cluster status is normal.

[0215] S307: Triggers the fence mechanism, forcibly terminating processes such as PostgreSQL on the current master node and stopping the read / write VIP mounted on the current master node.

[0216] S308: This means that the cluster has a master node. Here, if the current master node is not the set master node, it can determine whether the local machine (i.e., this node) is the set master node.

[0217] Yes, that is, if the local machine is the designated master node, then execute S309;

[0218] No, that is, if the local machine is not the designated master node, then execute S316.

[0219] It should be noted that the designated master node is the pre-configured master node. If the current master node is not the designated master node, it indicates that the cluster may have undergone failover, and further investigation is needed to determine whether a split-brain scenario has occurred.

[0220] S309: This refers to the case where the local machine is the designated master node. Here, we can further determine whether the local machine is a slave node. It should be noted that a slave node is a follower node.

[0221] No, that is, if the local machine is not a slave node, then execute S310;

[0222] Yes, meaning the local machine is a slave node, then execute S313.

[0223] S310: This means that the local machine is not a slave node. In this case, we can further determine whether the local machine is a master node; if yes, execute S311; if no, execute S312.

[0224] S311: This means that the local machine is the master node. At this time, the fence mechanism can be triggered to forcibly terminate processes such as PostgreSQL on the local machine and stop reading and writing VIP.

[0225] In addition, the fence_check resource can also check and confirm the local network connectivity status by connecting to the gateway IP address. If the connectivity test from the local machine to the gateway is not passed within the set time (the length of this time can be set according to needs), it is determined that a network failure or server failure has occurred on the local machine, and the fence_check anti-split-brain script is triggered to terminate the read / write VIP and related PostgreSQL processes on the local node.

[0226] S312: This means that the local machine is neither a master node nor a slave node, indicating that the local machine is in an abnormal state and the maintenance personnel need to be notified of the abnormal state of the local machine.

[0227] In other words, if the VIP is not mounted on the local machine, and the local machine is neither a Master node nor a Slave node, then the operations and maintenance personnel will be notified that the cluster status is abnormal, and the fence_check code will be exited.

[0228] S313: This means that the local machine is a slave node. In this step, it can be further determined whether the Master VIP is mounted on the local machine.

[0229] If yes, execute S314; otherwise, execute S315.

[0230] In this step, since the local machine is the Master node set in the configuration file, but the local machine is currently a Slave node, and the current Master node is not the Master node set in the configuration file (i.e., resource configuration information), it indicates that a failover has occurred, and this cluster failover can be recorded in the log.

[0231] S314: This means the Master VIP is still mounted on the local machine. Forcefully delete the Master VIP and notify the operations and maintenance personnel that the cluster status is abnormal.

[0232] In other words, the local node is not the Master node, but the Master VIP is still mounted on the local machine. In this case, the operations and maintenance personnel can be notified of the abnormal situation and trigger the Pacemaker fence_check script (i.e., the fence_check code) to delete the Master VIP on the local machine.

[0233] S315: This indicates that the Master VIP is not mounted on the local machine. It notifies the operations and maintenance personnel that while the local machine was originally designated as the master node, the master node has been switched to a new node. Additionally, since the master node has been switched, the system can notify the operations and maintenance personnel that relevant configurations need to be modified, such as changing the configured master parameters.

[0234] S316: This means that the local machine is not the master node set in the fence_check configuration file (set_master parameter). It can determine whether the local machine is the current master node.

[0235] If yes, execute S317; otherwise, execute S318.

[0236] S317: This indicates that the local machine is the current master node. This notifies operations personnel that the local machine has become the new master node, and a cluster failover has occurred. Additionally, since the local machine has been promoted to the new master, operations personnel can be notified that relevant configurations need to be modified, such as changing the set master parameters.

[0237] S318: This means that the local machine is not the current master node. The logs can record that the local machine is not the new master node and that a failover has occurred in the cluster. It can also be used to further determine whether the local machine is connected to the set master node.

[0238] If no, execute S319; if yes, execute S320.

[0239] It should be noted that the fence_check resource can record all detection and operation logs during operation, and output detailed logs of the network and database instance status when the cluster master node fails. This provides operations and maintenance personnel with the opportunity to query and trace cluster anomaly records for analyzing the cause of the failure. It can also send cluster anomaly notifications to operations and maintenance personnel via email.

[0240] S319: Notify maintenance personnel that the local machine cannot connect to the configured master node.

[0241] Here, when the local machine cannot connect to the designated master node, the operations and maintenance personnel can be informed that the master node configured in the resource configuration information has experienced a network failure and needs to be repaired.

[0242] S320: This means that the local machine can connect to the set master node. At this time, it can be further determined whether the Master VIP is mounted on the set master node.

[0243] If no, execute S321; if yes, execute S322.

[0244] In this step, the local machine can test the network connection status between itself and the Master set in the configuration file. If the connection is successful, it can further determine whether the read / write VIP is still running on the Master node set in the configuration file, that is, whether the Master VIP is mounted on the set master node, in order to determine whether the cluster has experienced a split-brain.

[0245] S321: The log shows that the master VIP is not running on the designated master node, and the cluster status is normal.

[0246] S322: If the read / write VIP is still mounted on the designated master node, the fence mechanism can be triggered on the designated master node, that is, the fence_check anti-split-brain script can be triggered to forcibly terminate the PostgreSQL and related processes on the designated master node and stop the read / write VIP.

[0247] S323: Determine if the designated master node is in master state. If yes, execute S324; otherwise, execute S325.

[0248] In this step, Pacemaker can review the processing results (i.e., the results of forcibly terminating related processes, etc.) until the read / write VIP of the faulty node is completely removed and the related PostgreSQL processes are stopped.

[0249] S324: Triggers the fence mechanism on the designated master node, forcibly terminating processes such as PostgreSQL on the designated master node and stopping read and write operations on the VIP.

[0250] S325: The master node set in the log is not in master state, so there is no need to trigger fence.

[0251] In the above embodiments, the fence_check resource can obtain the IP address, server name, and gateway address of the node that should become the master node through the configuration parameters in the resource configuration information. The fence_check resource will make real-time judgments on the network connectivity status and database service status of each database node to the gateway based on these configuration parameter information, and perform corresponding operations according to the status. Once the database cluster master node fails to connect to the gateway, it is judged that the cluster has split brain, and the fence_check code is immediately run to detect the cluster status. Based on the logic, it is determined whether the corresponding service (i.e., the corresponding process) on the master node needs to be shut down to avoid cluster split brain and ensure the consistency and integrity of the entire database cluster data.

[0252] As an optional embodiment of the present invention, parameters can be set in the fence_check resource code, as shown in the following example:

[0253]

[0254]

[0255] It should be noted that the fence_check resource's runtime parameters can be customized. These parameters (i.e., configuration parameters) can be added or modified as needed. The fence_check resource can also be started, stopped, and its runtime status viewed at any time. For example, the following types of operations can be performed:

[0256]

[0257] The code above indicates that operations such as start, stop, and status can be performed on fence_check type resources. The monitor is used to monitor the database server status to prevent split-brain operations. It can also be stopped when the resource is no longer needed.

[0258] The database cluster management method of this embodiment can determine the corresponding management operations to manage the nodes of the database cluster by obtaining relevant information of the current master node of the database cluster and combining it with the resource configuration information of the database cluster. This enables timely detection of database split-brain phenomena and timely implementation of corresponding measures, which can avoid the occurrence of cluster split-brain to a certain extent and ensure data consistency and integrity. It does not require additional hardware to prevent split-brain, requires less investment, reduces operation and maintenance costs, and meets the requirements for preventing split-brain in virtualized or cloud-deployed database clusters.

[0259] like Figure 4 As shown, an embodiment of the present invention provides a database cluster management device applied to a first node in a database cluster, comprising:

[0260] The acquisition module 410 is used to acquire the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, Internet Protocol IP address and gateway address;

[0261] The processing module 420 is used to perform management operations on the nodes in the database cluster according to the resource configuration information of the database cluster and the first information corresponding to the current master node;

[0262] The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster.

[0263] In this embodiment, by obtaining relevant information about the current master node of the database cluster and combining it with the resource configuration information of the database cluster, the corresponding management operations can be determined to manage the nodes of the database cluster. This allows for the timely detection of database split-brain phenomena and the implementation of corresponding measures, which can, to a certain extent, prevent the occurrence of cluster split-brain and ensure data consistency and integrity. No additional hardware for preventing split-brain is required, resulting in low investment and reduced operation and maintenance costs. This meets the requirements for preventing split-brain in virtualized or cloud-deployed database clusters.

[0264] Optionally, the processing module 420 includes:

[0265] The first processing submodule is used to determine whether the current master node is a pre-configured master node based on the resource configuration information of the database cluster and the first information corresponding to the current master node.

[0266] The second processing submodule is used to determine whether the first node is a pre-configured master node based on the resource configuration information when the current master node is not a pre-configured master node.

[0267] The third processing submodule is used to perform management operations on the nodes in the database cluster based on the judgment result.

[0268] Optionally, the third processing submodule includes:

[0269] The first processing unit is configured to determine whether the first node is connected to the pre-configured master node when the first node is not a pre-configured master node and the first node is not the current master node.

[0270] The second processing unit is used to determine whether the read / write virtual IP address (VIP) is bound to the pre-configured master node when the first node is connected to the pre-configured master node.

[0271] The third processing unit is used to perform a first management operation on the pre-configured master node when the read / write VIP is bound to the pre-configured master node;

[0272] The first management operation includes at least one of the following:

[0273] Instruct to shut down the first process on the pre-configured master node;

[0274] The instruction is to unbind the read / write VIP from the pre-configured master node.

[0275] Optionally, the third processing submodule further includes:

[0276] The fourth processing unit is used to determine whether the pre-configured master node is in master node status;

[0277] The fifth processing unit is used to perform the first management operation on the pre-configured master node when the pre-configured master node is in the master node state.

[0278] Optionally, the device further includes:

[0279] The first sending module is used to send a first prompt message when the first node is the current master node, the first prompt message being used to indicate that the master node of the database cluster has been switched to the first node;

[0280] The second sending module is used to send a second prompt message when the first node is not connected to the pre-configured master node. The second prompt message is used to indicate that the pre-configured master node has experienced a network failure.

[0281] The first recording module is used to record first status information in the log when the read / write VIP is not bound to the pre-configured master node. The first status information is used to indicate that the read / write VIP is not bound to the pre-configured master node.

[0282] Optionally, the third processing submodule includes:

[0283] The sixth processing unit is used to determine whether the first node is a slave node when the first node is a pre-configured master node;

[0284] The seventh processing unit is used to perform management operations on the first node based on the judgment result.

[0285] Optionally, the seventh processing unit includes:

[0286] The first processing subunit is configured to perform a second management operation on the first node when the first node is the master node.

[0287] The second management operation includes at least one of the following:

[0288] Shut down the first process on the first node;

[0289] Remove the binding between the read / write VIP and the first node.

[0290] Optionally, the seventh processing unit includes:

[0291] The second processing subunit is used to determine whether the read / write VIP is bound to the first node when the first node is a slave node.

[0292] The unbinding subunit is used to unbind the read / write VIP from the first node when the read / write VIP is bound to the first node.

[0293] Optionally, the device further includes:

[0294] The third sending module is used to send a third prompt message, which prompts the master node of the database cluster to switch to a node other than the pre-configured master node.

[0295] Optionally, the device further includes:

[0296] The fourth sending module is used to send a fourth prompt message when the first node is neither the master node nor the slave node, the fourth prompt message being used to indicate that the first node is in an abnormal state.

[0297] The database cluster management device in this embodiment can determine the corresponding management operations to manage the nodes of the database cluster by obtaining relevant information of the current master node of the database cluster and combining it with the resource configuration information of the database cluster. This enables timely detection of database split-brain phenomena and timely implementation of corresponding measures, which can, to a certain extent, prevent the occurrence of cluster split-brain and ensure data consistency and integrity. It does not require additional hardware to prevent split-brain, requires less investment, reduces operation and maintenance costs, and meets the requirements for preventing split-brain in virtualized or cloud-deployed database clusters.

[0298] like Figure 5 As shown, a network device 500 according to an embodiment of the present invention includes a processor 510 and a transceiver 520, wherein the processor is used for:

[0299] Obtain the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, Internet Protocol IP address, and gateway address;

[0300] Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, management operations are performed on the nodes in the database cluster.

[0301] The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster.

[0302] In this embodiment, by obtaining relevant information about the current master node of the database cluster and combining it with the resource configuration information of the database cluster, the corresponding management operations can be determined to manage the nodes of the database cluster. This allows for the timely detection of database split-brain phenomena and the implementation of corresponding measures, which can, to a certain extent, prevent the occurrence of cluster split-brain and ensure data consistency and integrity. No additional hardware for preventing split-brain is required, resulting in low investment and reduced operation and maintenance costs. This meets the requirements for preventing split-brain in virtualized or cloud-deployed database clusters.

[0303] Optionally, when the processor performs management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node, it is specifically used for:

[0304] Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, determine whether the current master node is a pre-configured master node;

[0305] If the current master node is not a pre-configured master node, determine whether the first node is a pre-configured master node based on the resource configuration information;

[0306] Based on the judgment result, management operations are performed on the nodes in the database cluster.

[0307] Optionally, when the processor performs management operations on the nodes in the database cluster based on the judgment result, it is specifically used for:

[0308] If the first node is not a pre-configured master node and is not the current master node, determine whether the first node is connected to the pre-configured master node;

[0309] When the first node is connected to the pre-configured master node, determine whether the read / write virtual IP address (VIP) is bound to the pre-configured master node;

[0310] When the read / write VIP is bound to the pre-configured master node, the first management operation is performed on the pre-configured master node;

[0311] The first management operation includes at least one of the following:

[0312] Instruct to shut down the first process on the pre-configured master node;

[0313] The instruction is to unbind the read / write VIP from the pre-configured master node.

[0314] Optionally, the processor is further configured to:

[0315] Determine whether the pre-configured master node is in master node status;

[0316] When the pre-configured master node is in the master node state, the first management operation is performed on the pre-configured master node.

[0317] Optionally, the processor is further configured to:

[0318] If the first node is the current master node, a first prompt message is sent, which is used to indicate that the master node of the database cluster has been switched to the first node;

[0319] If the first node is not connected to the pre-configured master node, a second prompt message is sent, which is used to indicate that the pre-configured master node has experienced a network failure.

[0320] If the read / write VIP is not bound to the pre-configured master node, a first status information is recorded in the log, which indicates that the read / write VIP is not bound to the pre-configured master node.

[0321] Optionally, when the processor performs management operations on the nodes in the database cluster based on the judgment result, it is specifically used for:

[0322] If the first node is a pre-configured master node, determine whether the first node is a slave node;

[0323] Based on the judgment result, perform management operations on the first node.

[0324] Optionally, when the processor performs management operations on the first node based on the judgment result, it is specifically used for:

[0325] When the first node is the master node, the second management operation is performed on the first node;

[0326] The second management operation includes at least one of the following:

[0327] Shut down the first process on the first node;

[0328] Remove the binding between the read / write VIP and the first node.

[0329] Optionally, when the processor performs management operations on the first node based on the judgment result, it is specifically used for:

[0330] If the first node is a slave node, determine whether the read / write VIP is bound to the first node;

[0331] If the read / write VIP is bound to the first node, then unbind the read / write VIP from the first node.

[0332] Optionally, the processor is further configured to:

[0333] A third prompt message is sent, which prompts the master node of the database cluster to switch to a node other than the pre-configured master node.

[0334] Optionally, the processor is further configured to:

[0335] If the first node is neither the master node nor the slave node, a fourth prompt message is sent, which is used to indicate that the first node is in an abnormal state.

[0336] The network device in this embodiment, by acquiring relevant information about the current master node of the database cluster and combining it with the resource configuration information of the database cluster, can determine the corresponding management operations to manage the nodes of the database cluster. This enables timely detection of database split-brain phenomena and allows for timely implementation of corresponding measures. To a certain extent, this can prevent the occurrence of cluster split-brain situations and ensure data consistency and integrity. No additional split-brain prevention hardware is required, resulting in low investment and reduced operation and maintenance costs. This meets the requirements for split-brain prevention in virtualized or cloud-deployed database clusters.

[0337] Another embodiment of the network device of the present invention, such as Figure 6 As shown, it includes a transceiver 610, a processor 600, a memory 620, and a program or instructions stored in the memory 620 and executable on the processor 600; when the processor 600 executes the program or instructions, it implements the above-described database cluster management method.

[0338] The transceiver 610 is used to receive and send data under the control of the processor 600.

[0339] Among them, Figure 6 In this context, the bus architecture may include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 600) and memory (memory 620). The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 610 may be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. The processor 600 is responsible for managing the bus architecture and general processing, and the memory 620 may store data used by the processor 600 during operation.

[0340] This invention provides a readable storage medium storing a program or instructions. When executed by a processor, the program or instructions implement the steps of the database cluster management method described above and achieve the same technical effect. To avoid repetition, further details are omitted here. The computer-readable storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0341] It should be further noted that the terminals described in this specification include, but are not limited to, smartphones, tablets, etc., and many of the functional components described are referred to as modules in order to emphasize the independence of their implementation.

[0342] In this embodiment of the invention, the module can be implemented in software so that it can be executed by various types of processors. For example, an identified executable code module may include one or more physical or logical blocks of computer instructions, which may be constructed as objects, procedures, or functions. Nevertheless, the executable code of the identified module does not need to be physically located together, but may include different instructions stored in different bits, which, when logically combined, constitute the module and achieve the module's intended purpose.

[0343] In practice, an executable code module can be a single instruction or many instructions, and can even be distributed across multiple different code segments, different programs, and across multiple memory devices. Similarly, operational data can be identified within the module and can be implemented in any suitable form and organized within any suitable type of data structure. This operational data can be collected as a single dataset or distributed across different locations (including different storage devices), and can exist, at least in part, solely as electronic signals within the system or network.

[0344] When a module can be implemented using software, considering the current level of hardware technology, modules that can be implemented in software can be implemented using hardware circuits by those skilled in the art to achieve the corresponding functions, without considering cost. These hardware circuits include conventional very-large-scale integrated circuits (VLSI) or gate arrays, as well as existing semiconductors such as logic chips and transistors, or other discrete components. Modules can also be implemented using programmable hardware devices, such as field-programmable gate arrays, programmable array logic, and programmable logic devices.

[0345] The exemplary embodiments described above are with reference to the accompanying drawings. Many different forms and embodiments are feasible without departing from the spirit and teachings of the invention. Therefore, the invention should not be construed as limiting the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided to make the invention complete and convey the scope of the invention to those skilled in the art. In these drawings, component dimensions and relative dimensions may be exaggerated for clarity. The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, unless clearly indicated otherwise, the singular forms “a,” “an,” and “the” are intended to include all such forms. It will be further understood that the terms “comprising” and / or “including”, when used in this specification, indicate the presence of the stated features, integers, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, integers, steps, operations, components, and / or groups thereof. Unless otherwise indicated, when stated, a range of values ​​includes the upper and lower limits of the range and any subranges in between.

[0346] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A database cluster management method, applied to the first node in a database cluster, characterized in that, include: Obtain the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, Internet Protocol IP address, and gateway address; Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, management operations are performed on the nodes in the database cluster. The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster; The step of performing management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node includes: Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, determine whether the current master node is a pre-configured master node; If the current master node is not a pre-configured master node, determine whether the first node is a pre-configured master node based on the resource configuration information; Based on the judgment result, management operations are performed on the nodes in the database cluster.

2. The method according to claim 1, characterized in that, The step of performing management operations on the nodes in the database cluster based on the judgment result includes: If the first node is not a pre-configured master node and is not the current master node, determine whether the first node is connected to the pre-configured master node; When the first node is connected to the pre-configured master node, determine whether the read / write virtual IP address (VIP) is bound to the pre-configured master node; When the read / write VIP is bound to the pre-configured master node, the first management operation is performed on the pre-configured master node; The first management operation includes at least one of the following: Instruct to shut down the first process on the pre-configured master node; The instruction is to unbind the read / write VIP from the pre-configured master node.

3. The method according to claim 2, characterized in that, After performing the first management operation on the pre-configured master node, the method further includes: Determine whether the pre-configured master node is in master node status; When the pre-configured master node is in the master node state, the first management operation is performed on the pre-configured master node.

4. The method according to claim 2, characterized in that, It also includes at least one of the following: If the first node is the current master node, a first prompt message is sent, which is used to indicate that the master node of the database cluster has been switched to the first node; If the first node is not connected to the pre-configured master node, a second prompt message is sent, which is used to indicate that the pre-configured master node has experienced a network failure. If the read / write VIP is not bound to the pre-configured master node, a first status information is recorded in the log, which indicates that the read / write VIP is not bound to the pre-configured master node.

5. The method according to claim 1, characterized in that, The step of performing management operations on the nodes in the database cluster based on the judgment result includes: If the first node is a pre-configured master node, determine whether the first node is a slave node; Based on the judgment result, perform management operations on the first node.

6. The method according to claim 5, characterized in that, The step of performing management operations on the first node based on the judgment result includes: When the first node is the master node, the second management operation is performed on the first node; The second management operation includes at least one of the following: Shut down the first process on the first node; Remove the binding between the read / write VIP and the first node.

7. The method according to claim 5, characterized in that, The step of performing management operations on the first node based on the judgment result includes: If the first node is a slave node, determine whether the read / write VIP is bound to the first node; If the read / write VIP is bound to the first node, then unbind the read / write VIP from the first node.

8. The method according to claim 7, characterized in that, Also includes: A third prompt message is sent, which prompts the master node of the database cluster to switch to a node other than the pre-configured master node.

9. The method according to claim 5, characterized in that, Also includes: If the first node is neither the master node nor the slave node, a fourth prompt message is sent, which is used to indicate that the first node is in an abnormal state.

10. A database cluster management device, characterized in that, include: The acquisition module is used to acquire the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, Internet Protocol IP address, and gateway address; The processing module is used to perform management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node; The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster; The processing module includes: The first processing submodule is used to determine whether the current master node is a pre-configured master node based on the resource configuration information of the database cluster and the first information corresponding to the current master node. The second processing submodule is used to determine whether the first node is a pre-configured master node based on the resource configuration information when the current master node is not a pre-configured master node. The third processing submodule is used to perform management operations on the nodes in the database cluster based on the judgment result.

11. A network device, characterized in that, include: Transceiver and processor; the processor is used for: Obtain the first information corresponding to the current master node of the database cluster; wherein, the first information includes at least one of the following: server name, Internet Protocol IP address, and gateway address; Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, management operations are performed on the nodes in the database cluster. The resource configuration information includes: the first information corresponding to the pre-configured master node, wherein the pre-configured master node is the master node configured for the database cluster; When the processor performs management operations on the nodes in the database cluster based on the resource configuration information of the database cluster and the first information corresponding to the current master node, it is specifically used for: Based on the resource configuration information of the database cluster and the first information corresponding to the current master node, determine whether the current master node is a pre-configured master node; If the current master node is not a pre-configured master node, determine whether the first node is a pre-configured master node based on the resource configuration information; Based on the judgment result, management operations are performed on the nodes in the database cluster.

12. A network device, comprising: A transceiver, a processor, a memory, and a program or instructions stored in the memory and executable on the processor; characterized in that, when the processor executes the program or instructions, it implements the database cluster management method as described in any one of claims 1 to 9.

13. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the steps of the database cluster management method as described in any one of claims 1 to 9.

Images