Database cluster state detection method and system

Abstract

The application provides a database cluster state detection method and system, and relates to the technical field of databases. The method applied to a cloud control platform comprises the following steps: receiving first state information sent by a first detection agent to obtain state information of each database instance in a database cluster that meets a first condition and generating labels of corresponding Pods by using the state information of each database instance in the database cluster that meets the first condition; receiving first global state information sent by the first detection agent to obtain global state information corresponding to each detection agent in the database cluster and performing arbitration processing based on the global state information corresponding to each detection agent in the database cluster to obtain final state information of each database instance in the database cluster; and updating the labels of the corresponding Pods by using the final state information of each database instance in the database cluster. The method provided by the application can improve the database cluster state detection efficiency.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a database cluster status detection method and system. Background Technology

[0002] In container cloud environments, database clusters are typically deployed in a containerized manner to support the high availability, elastic scaling, and rapid deployment requirements of enterprise applications. During the operation of the database cluster to provide services, it is necessary to have real-time and accurate awareness of the primary and backup status of each node in the cluster in order to perform operations such as traffic routing and failover.

[0003] In related technologies, the status of each node in the database cluster is actively detected by an external detection system, or by the health check interface built into the database cluster. These technologies suffer from at least one of the following problems: high latency in status detection, high overhead in status detection, low integration with container cloud platforms, and weak ability to handle abnormal scenarios. This results in low efficiency for database cluster status detection. Summary of the Invention

[0004] This application provides a database cluster status detection method and system to improve the efficiency of database cluster status detection.

[0005] Firstly, this application provides a database cluster status detection method applied to a cloud control platform. The method includes: receiving first status information sent by a first detection agent to obtain the status information of each database instance in the database cluster that meets a first condition, and generating a label for a corresponding Pod using the status information of each database instance in the database cluster that meets the first condition; the database cluster includes N database instances, each of which is deployed on N Pods, and each Pod runs its own database instance and detection agent; the first condition indicates that the status of the database instance has changed, and N is an integer greater than or equal to 2; receiving first global status information sent by the first detection agent to obtain the global status information corresponding to each detection agent in the database cluster, and performing arbitration processing based on the global status information corresponding to each detection agent in the database cluster to obtain the final status information of each database instance in the database cluster; the first global status information is obtained by the first detection agent from other accessible detection agents in the database cluster; and updating the label of the corresponding Pod using the final status information of each database instance in the database cluster.

[0006] In one possible embodiment, arbitration processing based on the global state information corresponding to each detection agent in the database cluster includes: aggregating the global state information corresponding to each detection agent in the database cluster to obtain target global state information; performing conflict checks on the target global state information to obtain conflict check results; and, if the conflict check results indicate that there is an abnormal state in the database cluster, performing exception handling using a preset exception handling strategy to obtain the final state information of each database instance in the database cluster.

[0007] In one possible embodiment, the status information includes heartbeat data, and the method further includes: receiving heartbeat data reported by a first detection agent when the first status information indicates that the first database instance meets the second condition, so as to obtain the heartbeat data of each database instance in the database cluster that meets the first condition, wherein the heartbeat data indicates whether the corresponding database instance is alive, and the second condition indicates that the status of the first database instance has not changed and the status information reporting interval of the first database instance exceeds a preset threshold.

[0008] In one possible embodiment, the global state information corresponding to each detection agent in the database cluster includes state check results. The state check results are obtained by each detection agent based on the global state information through at least one of communication check, multi-master node check, masterless node check, and state verification.

[0009] In one possible embodiment, after obtaining the final state information of each database instance in the database cluster, the method further includes: recording the state change of the database cluster through event notification when the final state information indicates that a state change has occurred in the database cluster.

[0010] In one possible implementation, the Pod's label is made available to target services via an application programming interface, and the target services include at least one of traffic routing, detection and alarm, and fault scheduling.

[0011] Secondly, this application provides a database cluster status detection method applied to an execution node. The execution node includes a first Pod, which is any one of N Pods. The first Pod runs a first detection agent and a first database instance, where N is an integer greater than or equal to 2. The method includes: for the first Pod, obtaining first status information of the first database instance through the first detection agent, and sending the first status information to a cloud control platform through the first detection agent when the first status information indicates that the first database instance meets a first condition; the first condition indicates that the status of the database instance has changed; obtaining status information of other database instances in the database cluster through the first detection agent to obtain first global status information, and sending the first global status information to the cloud control platform through the first detection agent.

[0012] In one possible embodiment, the first status information includes heartbeat data, and the method further includes: when the first status information indicates that the first database instance meets a second condition, reporting the heartbeat data to the cloud control platform through a first detection agent, wherein the second condition indicates that the status of the first database instance has not changed and the reporting interval of the status information of the first database instance exceeds a preset threshold.

[0013] In one possible embodiment, after obtaining the first global state information, the method further includes: performing a database cluster state check based on the first global state information through a first detection agent to obtain a first state check result. The first global state information includes the first state check result, and the database cluster state check includes at least one of communication check, multi-master node check, no-master node check, and state verification.

[0014] Thirdly, this application provides a database cluster status detection device applied to a cloud control platform. The device includes: a generation module, used to receive first status information sent by a first detection agent to obtain the status information of each database instance in the database cluster that meets a first condition, and to generate a label for the corresponding Pod using the status information of each database instance in the database cluster that meets the first condition; the database cluster includes N database instances, each of which is deployed on one of the N Pods, and each Pod runs its own database instance and detection agent, the first condition indicating that the status of the database instance has changed, and N is an integer greater than or equal to 2; an arbitration module, used to receive first global status information sent by the first detection agent to obtain the global status information corresponding to each detection agent in the database cluster, and to perform arbitration processing based on the global status information corresponding to each detection agent in the database cluster to obtain the final status information of each database instance in the database cluster, wherein the first global status information is obtained by the first detection agent from other accessible detection agents in the database cluster; and an update module, used to update the label of the corresponding Pod using the final status information of each database instance in the database cluster.

[0015] Fourthly, this application provides a database cluster status detection device. This device is applied to an execution node, which includes a first Pod, which is any one of N Pods. The first Pod runs a first detection agent and a first database instance, where N is an integer greater than or equal to 2. The device includes: a sending module, configured to, for the first Pod, obtain first status information of the first database instance through the first detection agent and, if the first status information indicates that the first database instance meets a first condition, send the first status information to a cloud control platform through the first detection agent; the first condition indicates that the status of the database instance has changed; the sending module is further configured to, through the first detection agent, obtain status information of other database instances in the database cluster, obtain first global status information, and send the first global status information to the cloud control platform through the first detection agent.

[0016] Fifthly, this application provides a database cluster status detection system, comprising: a cloud control platform and an execution node, wherein the cloud control platform is used to execute the method as described in any of the first aspects, and the execution node is used to execute the method as described in any of the second aspects.

[0017] Fifthly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method as described in any of the first aspects or the method as described in any of the second aspects.

[0018] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects or the method as described in any of the second aspects.

[0019] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects or the method of any one of the second aspects.

[0020] In this embodiment, each Pod containing a database instance can promptly detect the status of its local database instance through its own detection agent. Only when the status of the database instance changes does the detection agent send the corresponding status information to the cloud control platform, reporting the latest database instance status. This reduces unnecessary status information reporting and thus reduces resource overhead. The detection agent is a lightweight agent deployed within the Pod, capable of detecting the status of database instances within the same Pod through local communication, eliminating the need for cross-node communication overhead. It also avoids the performance bottlenecks caused by external detection systems' periodic polling, such as status detection latency and high overhead.

[0021] In addition to reporting the latest database instance status when the database instance status changes, each detection agent also obtains global status information from other detection agents in the database cluster and reports it to the cloud control platform. This allows the cloud control platform to obtain the global status of the database cluster from the perspective of each detection agent and perform accurate arbitration processing based on this, so as to automatically handle abnormal states and ensure the consistency of the database cluster status.

[0022] Furthermore, the latest database instance status can be written to the corresponding Pod's tag. The Pod tag also supports updates using the final status information of each database instance in the database cluster. This allows status information to be exposed externally through Pod tags, and external target services can consume this status information seamlessly, simplifying the status consumption logic of external target services. Moreover, Pod tags accurately and conveniently reflect the database cluster status. This enhances integration with container clouds and improves cloud-native capabilities.

[0023] In summary, the database cluster status detection method of this application embodiment can achieve second-level synchronization from database instance status changes to Pod tag updates on the cloud control platform, significantly improving the real-time performance of database cluster status detection and the automation capability of abnormal status handling, while greatly reducing resource consumption. Therefore, the database cluster status detection method of this application embodiment has higher database cluster status detection efficiency. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram of a database cluster status detection system according to an embodiment of this application;

[0026] Figure 2 This is an interactive flowchart of the database cluster status detection method according to an embodiment of this application;

[0027] Figure 3 This is a schematic diagram of a database cluster status detection method according to another embodiment of this application;

[0028] Figure 4 This is a schematic diagram of a database cluster status detection device applied to a cloud control platform according to an embodiment of this application;

[0029] Figure 5 This is a schematic diagram of a database cluster status detection device applied to an execution node according to an embodiment of this application;

[0030] Figure 6This is a schematic diagram of an electronic device according to an embodiment of this application.

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

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

[0033] The technical terms used in the embodiments of this application will be explained below.

[0034] Container cloud: A cloud computing platform built on container virtualization technology, providing full lifecycle management capabilities including container deployment, scheduling, orchestration, operation and maintenance, and detection. Container cloud achieves management and elastic scaling of massive container resources through a unified control platform. The following explanation will use Kubernetes (K8s) as an example to illustrate container cloud.

[0035] A Pod consists of one or more containers, a shared storage volume, a network IP address, and container runtime configurations. It is the smallest unit of deployment, scheduling, and management in Kubernetes.

[0036] Pod tags: Key-value pairs of metadata in Kubernetes used to identify and select Pods, and can be used for service discovery, deployment strategies, etc.

[0037] Agent: A dedicated program or component running on a Pod or database cluster to perform specific tasks on behalf of others, without directly participating in business logic.

[0038] Operator pattern: An extended pattern in Kubernetes that uses custom controllers and custom resources to manage and operate complex stateful applications.

[0039] A database cluster is a distributed collection of multiple database instances connected via a specific protocol. It achieves high availability, load balancing, and data disaster recovery through the collaborative work of these instances. Each database instance can be understood as a node.

[0040] Network partitioning (split-brain): A situation where multiple master nodes exist simultaneously within a database cluster, which can cause data forks and confusion in the logic of upper-layer applications.

[0041] High availability: A measure of a database cluster's ability to continuously provide services within a specified time period.

[0042] Multiple master nodes: In a database cluster, an abnormal state in which multiple nodes simultaneously act as master nodes to accept write operations.

[0043] No master node: An abnormal state in a database cluster where no node acts as the master node to accept write operations.

[0044] In related technology 1, the status of each node in the database cluster is actively detected by an external detection system. Specifically, an independent detection agent periodically connects to the database instance and executes queries to obtain the primary and backup status of the nodes. However, this periodic polling method has a latency in status detection and cannot reflect status changes in real time. Furthermore, frequent queries to the node status of the database cluster increase the database cluster load, meaning that status detection is costly, which may lead to performance bottlenecks, especially in large-scale database clusters.

[0045] In related technology 2, the health status of each node in the database cluster is detected through the built-in health check interface. Specifically, the health check probe of the database cluster is configured to periodically check the health status of the nodes. This method is only used to detect whether a node is running to determine whether the node is alive, and cannot provide detailed database cluster topology information, such as the ability to detect the master-slave node relationship. This makes related technology 2 unsuitable for abnormal scenarios such as multi-master node scenarios or masterless node scenarios.

[0046] In summary, the relevant technologies suffer from at least one of the following problems: high latency in database cluster node status detection, high overhead in status detection, low integration with container cloud platforms, and weak ability to handle abnormal scenarios. These issues make it difficult to meet the real-time and automated requirements of container cloud platforms for dynamic status detection of database clusters.

[0047] Based on this, this application proposes a database cluster status detection method and system, which realizes dynamic detection and cloud-native exposure of database cluster status by introducing a collaborative mechanism of lightweight agent and Operator mode in container cloud environment.

[0048] Specifically, 1) Through a layered mechanism of local status detection and database cluster-level anomaly detection, the master / slave status, health status, and replication status of database instances and database clusters are captured in a timely manner; 2) A status change-driven reporting strategy is adopted, which triggers reporting only when the status changes, significantly reducing the frequency of meaningless reporting; 3) Status information is directly written into Pod tags, and the standardized distribution and consumption of status information are realized through cloud-native APIs.

[0049] This can solve at least one of the following problems: high latency in state detection, high overhead in state detection, low integration with container cloud platforms, and weak ability to handle abnormal scenarios.

[0050] This application's embodiments are applicable to database cluster scenarios deployed in container cloud platforms. In this scenario, database instances run as Pods, and service discovery, traffic routing, and failover are achieved through Pod tags. For example, when a primary / standby switch or node failure occurs in the database cluster, status information can be synchronized to Pod tags in real time to dynamically adjust traffic policies, trigger alarms based on Pod tag changes, and perform load balancing based on Pod tags.

[0051] Figure 1 This is a schematic diagram of a database cluster status detection system according to an embodiment of this application.

[0052] like Figure 1 As shown, the system architecture consists of execution node 1 and cloud control platform 2.

[0053] Execution node 1 can be a single server or any server node in a server cluster. If the execution node is a single server, the database cluster is deployed on that server. If the execution node is any server node in a server cluster, the database cluster is deployed on that server cluster.

[0054] The database cluster consists of N database instances, and execution node 1 can deploy N Pods.

[0055] N is an integer greater than or equal to 2. Each Pod deploys one detection agent and one database instance. The detection agent is used to detect the status of the database instance in the Pod, and the database instance supports master-slave replication.

[0056] The cloud control platform 2 can receive the status of database instances reported by each detection agent through the controller (operator). The cloud control platform 2 can also be a server.

[0057] For example, the cloud control platform 2 can provide information such as the status of database instances to the outside world through an application programming interface (API). For instance, an upper-layer application can obtain the status of each database instance by calling the API in order to perform traffic routing, send alarms, etc.

[0058] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0059] Figure 2 This is an interactive flowchart of the database cluster status detection method according to an embodiment of this application.

[0060] like Figure 2 As shown, the database cluster status detection method of this application embodiment includes steps S110 to S150.

[0061] S110. For the first Pod, the execution node obtains the first status information of the first database instance through the first detection agent, and when the first status information indicates that the first database instance meets the first condition, it sends the first status information to the cloud control platform through the first detection agent.

[0062] Correspondingly, the cloud control platform receives the first status information sent by the first detection agent to obtain the status information of each database instance in the database cluster that meets the first condition.

[0063] The execution node includes the first Pod, which is any one of N Pods, where N is an integer greater than or equal to 2. The database cluster includes N database instances, which are deployed one-to-one on the N Pods. Each Pod runs its own database instance and detection agent. For example, the first Pod runs the first detection agent and the first database instance.

[0064] In S110, taking any one of the N Pods (i.e. the first Pod) as an example, it can be understood that the detection agent corresponding to each database instance that meets the first condition, including the first detection instance, sends the corresponding status information to the cloud control platform, so that the cloud control platform can obtain the status information of each database instance in the database cluster that meets the first condition.

[0065] The first condition indicates a change in the database instance's status. When a database instance supports master-slave replication mode, its status can include: node role status, replication status, and health status. Node role status indicates whether the database instance is a master or standby node; replication status indicates the data synchronization status of the standby node with the master node; and health status indicates whether the database instance is alive.

[0066] Each Pod runs its own database instance and detection agent. Taking the first Pod as an example: Since the first detection agent and the first database instance both run on the first Pod, the first detection agent and the first database instance share the network and storage of the first Pod. The first detection agent can obtain the status information of the first database instance through local communication.

[0067] For example, each detection agent can periodically check whether the state of the database instance in the same Pod has changed.

[0068] The S120 cloud control platform uses the status information of each database instance in the database cluster that meets the first condition to generate labels for the corresponding Pods. For example... Figure 2 As shown, the cloud control platform executes the database cluster status detection method of this application embodiment through the controller (operator).

[0069] It is understandable that each database instance that meets the first condition indicates that the state of the database instance has changed. By generating a label for the corresponding Pod, the latest state of the database instance can be written to the label of the Pod running the database instance.

[0070] S130. The execution node obtains the status information of other database instances in the database cluster through the first detection agent, obtains the first global status information, and sends the first global status information to the cloud control platform through the first detection agent.

[0071] Correspondingly, the cloud control platform receives the first global status information sent by the first detection agent in order to obtain the global status information of other detection agents in the database cluster.

[0072] In S130, the detection agent corresponding to each database instance, including the first detection instance, sends the corresponding global status information to the cloud control platform, so that the cloud control platform can obtain the global status information corresponding to each detection agent in the database cluster.

[0073] Taking the first detection agent as an example, it can obtain the Pod addresses of each database instance in the database cluster, thus obtaining a full list of nodes. Based on this full list, it can call the status interface of the Pod where other database instances reside. This status interface provides the status information of the local database instances within the Pod. The first detection agent integrates the first status information of the first database instance with the status information of other database instances besides the first database instance to obtain the first global status information.

[0074] For example, if the first database instance meets the first condition, the first detection agent can package the first state information and the first global state information and send them to the cloud control platform.

[0075] S140, the cloud control platform performs arbitration processing based on the global status information corresponding to each detection agent in the database cluster to obtain the final status information of each database instance in the database cluster.

[0076] Arbitration is used to ensure the consistency of the database cluster state through conflict detection and handling strategies.

[0077] In one possible implementation, arbitration is used to determine if the global state information of the various detection agents does not conflict. In this case, any one of the global state information can be used to indicate the final state information of each database instance in the database cluster. Alternatively, arbitration may determine if the global state information of the various detection agents does conflict. In this case, the conflict can be resolved until it is resolved. During this process, the state information of at least some database instances is updated to obtain the final state information of each database instance in the database cluster.

[0078] The S150 cloud control platform uses the final status information of each database instance in the database cluster to update the label of the corresponding Pod.

[0079] In this embodiment, each Pod containing a database instance can promptly detect the status of its local database instance through its own detection agent. Only when the status of the database instance changes does the detection agent send the corresponding status information to the cloud control platform, reporting the latest database instance status. This reduces unnecessary status information reporting and thus reduces resource overhead. The detection agent is a lightweight agent deployed within the Pod, capable of detecting the status of database instances within the same Pod through local communication, eliminating the need for cross-node communication overhead. It also avoids the performance bottlenecks caused by external detection systems' periodic polling, such as status detection latency and high overhead.

[0080] In addition to reporting the latest database instance status when the database instance status changes, each detection agent also obtains global status information from other detection agents in the database cluster and reports it to the cloud control platform. This allows the cloud control platform to obtain the global status of the database cluster from the perspective of each detection agent and perform accurate arbitration processing based on this, so as to automatically handle abnormal states and ensure the consistency of the database cluster status.

[0081] Furthermore, the latest database instance status can be written to the corresponding Pod's tag. The Pod tag also supports updates using the final status information of each database instance in the database cluster. This allows status information to be exposed externally through Pod tags, and external target services can consume this status information seamlessly, simplifying the status consumption logic of external target services. Moreover, Pod tags accurately and conveniently reflect the database cluster status. This enhances integration with container clouds and improves cloud-native capabilities.

[0082] In summary, the database cluster status detection method of this application embodiment can achieve second-level synchronization from database instance status changes to Pod tag updates on the cloud control platform, significantly improving the real-time performance of database cluster status detection and the automation capability of abnormal status handling, while greatly reducing resource consumption. Therefore, the database cluster status detection method of this application embodiment has higher database cluster status detection efficiency.

[0083] like Figure 2 As shown, in one possible embodiment, the Pod's label is made available to target services through an application programming interface (API), and the target services include at least one of traffic routing, detection and alarm, and fault scheduling.

[0084] For example, the target service of the upper-layer application is used to implement traffic routing, detection and alarm, and fault scheduling.

[0085] Specifically, the target service automatically selects the appropriate database instance to route traffic based on the primary / standby node role status indicated by the Pod tag. Alternatively, the target service can generate alerts by detecting changes in the Pod tag.

[0086] In this embodiment, the Pod tag can achieve standardized exposure of status information through the API. External target services can obtain the status of the database cluster or the status of a specified database instance by calling the API.

[0087] like Figure 2 As shown, in one possible embodiment, the first state information includes heartbeat data, and the method further includes step S160.

[0088] S160. When the first status information indicates that the first database instance meets the second condition, the execution node reports heartbeat data to the cloud control platform through the first detection agent.

[0089] Correspondingly, when the first status information indicates that the first database instance meets the second condition, the cloud control platform receives the heartbeat data reported by the first detection agent to obtain the heartbeat data of each database instance in the database cluster that meets the first condition.

[0090] In S160, taking any one of the N Pods (i.e., the first Pod) as an example, it can be understood that the detection agent corresponding to each database instance that meets the second condition, including the first detection instance, reports heartbeat data to the cloud control platform, so that the cloud control platform can obtain the heartbeat data of each database instance in the database cluster that meets the second condition.

[0091] The heartbeat data indicates whether the corresponding database instance is alive, and the second condition indicates that the status of the first database instance has not changed and the interval for reporting the status information of the first database instance exceeds a preset threshold.

[0092] The preset threshold indicates the time interval during which the database instance waits for a heartbeat data report to be triggered when its state remains unchanged. For example, the preset threshold ranges from [5, 20] seconds, and can specifically be 10 seconds.

[0093] For example, if the state of the first database instance does not change and the interval between reporting the state information of the first database instance does not exceed a preset threshold, the first detection agent does not need to report heartbeat data to the cloud control platform, nor does it need to report the state information of the first database instance.

[0094] In this embodiment, different reporting strategies are adopted based on the status of the database instance to reduce communication overhead. Specifically, when the status of the database instance changes, the detection agent immediately reports the status information to the cloud control platform to ensure timely updates to the database instance's status. When the status of the database instance remains unchanged, it indicates that the database instance is stable. In this case, there is no need to frequently report the database instance's status information. Instead, a preset threshold is used to determine whether to report the database instance's heartbeat data, and the heartbeat data indicates that the database instance is alive. Specifically, heartbeat data is reported when the interval between reports of the database instance's status information exceeds the preset threshold; otherwise, heartbeat data is not reported.

[0095] like Figure 2 As shown, in one possible embodiment, after obtaining the first global state information in S110, the method further includes step S170.

[0096] S170. The execution node performs a database cluster status check based on the first global status information through the first detection agent and obtains the first status check result. The first global status information includes the first status check result. The database cluster status check includes at least one of communication check, multi-master node check, no-master node check, and status verification.

[0097] Status verification is used to verify the accuracy of the status information of each database instance in the database cluster, thereby ensuring the accuracy of masterless node checks, multi-master node checks, and communication checks.

[0098] Communication checks are used to examine the communication status between individual database instances in a database cluster.

[0099] In this embodiment, each detection agent performs a cluster-level status check based on the global status information it detects. Specifically, it checks the communication status of the database cluster, whether there are multiple master nodes, whether there are no master nodes, and verifies the status information of each database instance. This allows for preliminary cluster-level status checks on the detection agent side. The cloud control platform can then directly utilize the status check results from each detection agent for global arbitration processing, reducing the load on the cloud control platform and improving arbitration processing speed.

[0100] Each detection agent detects the status of other database instances in the database cluster, obtaining global status information that is a local global perspective of the corresponding Pod. Taking the first Pod as an example, a network partition (split-brain) exists, causing the first detection agent to obtain only the global status information of the current network partition, which has one master node. Similarly, other network partitions in the database cluster each have one master node, resulting in a multi-master node situation. The local global perspective based on the first Pod cannot detect multiple master nodes in a split-brain scenario. Therefore, the database cluster status detection method in this embodiment sends the global status information detected by each detection agent to the cloud control platform, where the cloud control platform performs global arbitration processing.

[0101] Specifically, in one possible embodiment, step S140 includes steps S141 to S143.

[0102] S141. The cloud control platform aggregates the global status information corresponding to each detection agent in the database cluster to obtain the target global status information. This target global status information is the latest status of the database cluster and breaks through the limitations of local perspectives such as network partitions.

[0103] S142. The cloud control platform performs conflict checks on the target's global status information and obtains the conflict check results.

[0104] For example, the cloud control platform can perform cross-validation based on target global state information to check for conflicts. The conflict arises when the global state information from different detection agents indicates different database cluster states.

[0105] S143. When the conflict check results indicate that the database cluster is in an abnormal state, the cloud control platform uses the preset abnormal state handling strategy to handle the abnormality in order to obtain the final state information of each database instance in the database cluster.

[0106] For example, if the conflict check results indicate that the database cluster is not in an abnormal state, the cloud control platform does not need to perform any exception handling or update the corresponding Pod's label.

[0107] For example, abnormal states include: no master node and multiple master nodes. The preset abnormal state handling strategy can prioritize ensuring data consistency before restoring the normal topology of the database cluster.

[0108] For example, in the case of an abnormal state without a master node, the corresponding abnormal state handling strategy is as follows: scan the database cluster and filter candidate standby nodes based on their health status; elect and forcibly promote the candidate standby node with the characteristics of minimum replication latency from the candidate standby nodes to the new master node; and re-establish the replication link between the other nodes and the new master node and update the data synchronously as standby master nodes.

[0109] For example, in the case of an abnormal state of multiple master nodes, the corresponding abnormal state handling strategy is as follows: trigger read-only degradation and switch all data write entry points; arbitrate based on the priority of replication log positions to obtain the only valid master node and forcibly demote all pseudo master nodes to standby nodes; repair the replication link and synchronize data differences.

[0110] In this embodiment, the cloud control platform serves as the sole arbiter of the global state of the database cluster. Specifically, the cloud control platform integrates the global state information from various detection agents to obtain target global state information. This target global state information represents the latest state of the database cluster and overcomes the limitations of local perspectives such as network partitions. Conflict detection is performed using the target global state information to detect abnormal states such as no master node or multiple master nodes. In the event of an abnormal state, the cloud control platform also performs conflict resolution. The final state information obtained after conflict resolution indicates the final valid database cluster state. This enables accurate detection and automated anomaly handling of the database cluster's abnormal state, ensuring data consistency and improving the performance of the database cluster.

[0111] like Figure 2 As shown, in one possible embodiment, after obtaining the final state information of each database instance in the database cluster in step S140, the method further includes: S180.

[0112] S180. When the final status information indicates that a database instance has undergone a status change, record the status change of the database instance through an event notification.

[0113] For example, the event notification is a K8s event.

[0114] In this embodiment, event notification enables the observability, auditability, and alerting of the database cluster status. Event notification does not participate in business logic communication; for example, it does not notify detection agents. Instead, it targets operations personnel, external detection systems, or alerting systems. Recording database instance status changes through event notification provides external detection or alerting systems with automatic and standardized triggering of abnormal database cluster states without adding extra burden to the database cluster, and it is also compatible with the container cloud ecosystem.

[0115] Figure 3 This is a schematic diagram of a database cluster status checking method according to another embodiment of this application.

[0116] like Figure 3 As shown, the database cluster status check method includes steps S201 to S211. Steps S201 to S206 are executed by the first detection agent on the detection agent side; the first detection agent is only one of N detection agents used as an example. Steps S207 to S211 are executed by the controller of the cloud control platform.

[0117] S201. Detect whether the status of the first database instance has changed.

[0118] If a change occurs, proceed to step S201. If no change occurs, proceed to step S205.

[0119] S202, The controller that acquires the first status information and reports it to the cloud control platform.

[0120] S203. Obtain the status information of other database instances in the database cluster, obtain the first global status information, and report it to the controller of the cloud control platform.

[0121] S204. Perform a database cluster status check based on the first global status information to obtain the first status check result. Figure 3 In the example, the first state check result can be included in the first global state information and reported to the controller on the cloud control platform. Of course, besides this method, the first global state information and the first state check result can be reported separately.

[0122] S205. Detect whether the reporting time interval of the first database instance exceeds the preset threshold.

[0123] If the threshold is exceeded, proceed to step S206; otherwise, return to step S201.

[0124] S206. Obtain the heartbeat data of the first database instance.

[0125] exist Figure 3In the example, the heartbeat data of the first database instance may be included in the first global status information and reported to the controller of the cloud control platform.

[0126] The reporting interval is the reporting interval for the first global state information, which includes the first state information.

[0127] S207. Utilize the status information of database instances whose status has changed in the database cluster to generate labels for the corresponding Pods.

[0128] S208. Aggregate the global status information of each detection agent in the database cluster to obtain the target global status information.

[0129] S209. Perform conflict checks on the target's global state information to obtain the conflict check results.

[0130] S210. If the conflict check results indicate that the database cluster is in an abnormal state, perform exception handling using the preset exception handling strategy to obtain the final state information of each database instance in the database cluster. The final state information can update the label of the corresponding Pod.

[0131] S211. Record the state changes of the database cluster through event notification.

[0132] The steps of the embodiments of this application can be found in the relevant content above, and will not be repeated here.

[0133] Figure 4 This is a schematic diagram of a database cluster status detection device used in a cloud control platform. Figure 4 As shown in the embodiment of this application, the database cluster status detection device for cloud control platform includes: generation module 310, arbitration module 320 and update module 330.

[0134] The generation module 310 is used to receive the first status information sent by the first detection agent to obtain the status information of each database instance in the database cluster that meets the first condition and to generate the corresponding Pod's label using the status information of each database instance in the database cluster that meets the first condition. The database cluster includes N database instances, and the N database instances are deployed one-to-one on N Pods. Each Pod runs its own database instance and detection agent. The first condition indicates that the status of the database instance has changed, and N is an integer greater than or equal to 2.

[0135] Arbitration module 320 is used to receive the first global status information sent by the first detection agent, so as to obtain the global status information corresponding to each detection agent in the database cluster and perform arbitration processing based on the global status information corresponding to each detection agent in the database cluster to obtain the final status information of each database instance in the database cluster. The first global status information is obtained by the first detection agent from other accessible detection agents in the database cluster.

[0136] Update module 330 is used to update the label of the corresponding Pod using the final state information of each database instance in the database cluster.

[0137] In one possible embodiment, the arbitration module includes: an aggregation submodule, used to aggregate global state information corresponding to each detection agent in the database cluster to obtain target global state information; a conflict checking submodule, used to perform conflict checking on the target global state information to obtain conflict checking results; and a conflict handling submodule, used to perform exception handling using a preset exception handling strategy when the conflict checking results indicate that there is an abnormal state in the database cluster, so as to obtain the final state information of each database instance in the database cluster.

[0138] In one possible embodiment, the status information includes heartbeat data. The device method further includes: a receiving module, configured to receive heartbeat data reported by a first detection agent when the first status information indicates that the first database instance meets a second condition, so as to obtain the heartbeat data of each database instance in the database cluster that meets the first condition. The heartbeat data indicates whether the corresponding database instance is alive. The second condition indicates that the status of the first database instance has not changed and the status information reporting interval of the first database instance exceeds a preset threshold.

[0139] In one possible embodiment, the global state information corresponding to each detection agent in the database cluster includes state check results. The state check results are obtained by each detection agent based on the global state information through at least one of communication check, multi-master node check, masterless node check, and state verification.

[0140] In one possible embodiment, the device further includes a recording module, configured to record the state change of the database cluster via an event notification when the final state information indicates that a state change has occurred in the database cluster.

[0141] In one possible implementation, the Pod's label is made available to target services via an application programming interface, and the target services include at least one of traffic routing, detection and alarm, and fault scheduling.

[0142] Figure 5This is a schematic diagram of a database cluster status detection device applied to an execution node. The execution node includes a first Pod, which is any one of N Pods. The first Pod runs a first detection agent and a first database instance, where N is an integer greater than or equal to 2. Figure 5 As shown in the embodiment of this application, the database cluster status detection device applied to the execution node includes: a sending module 410.

[0143] The sending module 410 is used to obtain the first status information of the first database instance through the first detection agent for the first Pod, and send the first status information to the cloud control platform through the first detection agent when the first status information indicates that the first database instance meets the first condition; the first condition indicates that the status of the database instance has changed.

[0144] The sending module 410 is also used to obtain the status information of other database instances in the database cluster through the first detection agent, obtain the first global status information, and send the first global status information to the cloud control platform through the first detection agent.

[0145] In one possible embodiment, the first status information includes heartbeat data, and the device further includes a heartbeat reporting module, used to report heartbeat data to the cloud control platform through a first detection agent when the first status information indicates that the first database instance meets a second condition, wherein the second condition indicates that the status of the first database instance has not changed and the reporting interval of the status information of the first database instance exceeds a preset threshold.

[0146] In one possible embodiment, the device further includes: an inspection module, configured to perform a database cluster status inspection based on first global status information through a first detection agent, and obtain a first status inspection result, wherein the first global status information includes the first status inspection result, and the database cluster status inspection includes at least one of communication inspection, multi-master node inspection, masterless node inspection, and status verification.

[0147] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, this application embodiment provides an electronic device including a processor 501 and a memory 502. Optionally, the device further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0148] The electronic device can be a server.

[0149] In the specific implementation process, the memory 502 stores code, and the processor 501 runs the code stored in the memory 502 to execute the method of the above method embodiment.

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

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

[0152] The memory 502 may include high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage.

[0153] Bus 504 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 504 can be divided into address bus, data bus, control bus, etc. For ease of illustration, the bus 504 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0154] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the above-described method embodiments.

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

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

[0157] This application provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in any of the embodiments described above.

[0158] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

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

[0160] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0161] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0162] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0163] If the integrated unit / module is implemented as a software program module and sold or used as an independent financial product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software financial product. This computer software financial product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0164] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0165] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0166] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A database cluster status detection method, characterized in that, The method, applied to a cloud-based control platform, includes: The system receives first status information sent by the first detection agent to obtain the status information of each database instance in the database cluster that meets the first condition, and uses the status information of each database instance in the database cluster that meets the first condition to generate a label for the corresponding Pod. The database cluster includes N database instances, which are deployed one-to-one on N Pods. Each Pod runs its own database instance and detection agent. The first condition indicates that the status of the database instance has changed. N is an integer greater than or equal to 2. The system receives the first global status information sent by the first detection agent to obtain the global status information corresponding to each detection agent in the database cluster and performs arbitration processing based on the global status information corresponding to each detection agent in the database cluster to obtain the final status information of each database instance in the database cluster. The first global status information is obtained by the first detection agent from other accessible detection agents in the database cluster. The label of the corresponding Pod is updated using the final state information of each database instance in the database cluster.

2. The method according to claim 1, characterized in that, The arbitration process based on the global state information corresponding to each detection agent in the database cluster includes: By aggregating the global status information corresponding to each detection agent in the database cluster, the target global status information is obtained; Perform a conflict check on the target's global state information to obtain the conflict check result; If the conflict check result indicates that the database cluster is in an abnormal state, an abnormal state handling strategy is used to handle the abnormality in order to obtain the final state information of each database instance in the database cluster.

3. The method according to claim 1, characterized in that, The status information includes heartbeat data, and the method further includes: When the first status information indicates that the first database instance meets the second condition, the heartbeat data reported by the first detection agent is received to obtain the heartbeat data of each database instance in the database cluster that meets the first condition. The heartbeat data indicates whether the corresponding database instance is alive. The second condition indicates that the status of the first database instance has not changed and the reporting interval of the status information of the first database instance exceeds a preset threshold.

4. The method according to any one of claims 1-3, characterized in that, The global status information corresponding to each detection agent in the database cluster includes status check results. The status check results are obtained by each detection agent based on the global status information through at least one of communication check, multi-master node check, no-master node check, and status verification.

5. The method according to any one of claims 1-3, characterized in that, After obtaining the final state information of each database instance in the database cluster, the method further includes: When the final state information indicates that a state change has occurred in the database cluster, the state change of the database cluster is recorded via event notification.

6. The method according to any one of claims 1-3, characterized in that, The Pod's label is made available to target services through an application programming interface. The target services include at least one of traffic routing, detection and alarm, and fault scheduling.

7. A database cluster status detection method, characterized in that, Applied to an execution node, the execution node includes a first Pod, which is any one of N Pods, the first Pod running a first detection agent and a first database instance, where N is an integer greater than or equal to 2, the method includes: For the first Pod, the first state information of the first database instance is obtained through the first detection agent, and if the first state information indicates that the first database instance meets the first condition, the first state information is sent to the cloud control platform through the first detection agent; the first condition indicates that the state of the database instance has changed. The first detection agent obtains the status information of other database instances in the database cluster, obtains the first global status information, and sends the first global status information to the cloud control platform through the first detection agent.

8. The method according to claim 7, characterized in that, The first status information includes heartbeat data, and the method further includes: When the first status information indicates that the first database instance meets the second condition, the first detection agent reports heartbeat data to the cloud control platform. The second condition indicates that the status of the first database instance has not changed and the reporting interval of the status information of the first database instance exceeds a preset threshold.

9. The method according to claim 7 or 8, characterized in that, After obtaining the first global state information, the method further includes: The database cluster status is checked by the first detection agent based on the first global status information to obtain the first status check result. The first global status information includes the first status check result. The database cluster status check includes at least one of communication check, multi-master node check, no-master node check and status verification.

10. A database cluster status detection system, characterized in that, include: A cloud control platform and an execution node, wherein the cloud control platform is used to execute the method as described in any one of claims 1 to 6, and the execution node is used to execute the method as described in any one of claims 7 to 9.

Images