State control method and device of database instance, equipment, medium and product
By monitoring and automatically configuring database instances in real time, the problem of low efficiency in database scheduling and management in existing technologies is solved, realizing automated database cluster management and improving state control efficiency and system stability.
Patent Information
- Application Number
- CN202511332314.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-17
- Publication Date
- 2026-01-16
Smart Images
Figure CN121349993A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database management, and in particular to a method, apparatus, device, medium and product for controlling the state of a database instance. Background Technology
[0002] In cloud-native architectures, enterprises have increasingly complex needs for database deployment and management. With the popularization of containerization technology, container cluster management platforms (Kubernetes, K8s) have become the mainstream container orchestration platforms, allowing enterprises to manage database instances through their native resources.
[0003] Currently, we mainly rely on Kubernetes' native stateful application management components to provide orderly deployment, stable network identification, and storage binding; we achieve automated management of complex applications through custom controllers; and we rely on third-party tools to achieve failover, thereby enabling containerized deployment of the database.
[0004] However, existing database scheduling and management technologies cannot achieve complex management functions and require manual intervention and assistance from third-party tools, resulting in low efficiency in the state control of database instances. Summary of the Invention
[0005] This application provides a method, apparatus, device, medium, and product for controlling the state of a database instance, in order to solve the problem that the existing database scheduling and management cannot achieve complex management functions and requires manual intervention and assistance from third-party tools, resulting in low efficiency in controlling the state of the database instance.
[0006] Firstly, this application provides a method for state control of a database instance, including:
[0007] Real-time monitoring of the database instance to be controlled is performed to obtain its running status.
[0008] If the database instance to be controlled is in the running state, then collect the running indicator data of the member nodes of the database instance to be controlled; where the member nodes are the master node and slave node in the cluster corresponding to the database instance.
[0009] Based on operational metric data, determine the health status of member nodes to identify healthy and unhealthy member nodes.
[0010] Obtain resource information for leased resources in the cluster;
[0011] Update the master-slave node permissions of healthy member nodes based on the resource information of the leased resources.
[0012] In one possible design, resource information includes the lease term;
[0013] Accordingly, based on the resource information of the leased resources, the master and slave node permissions of healthy member nodes are updated, including:
[0014] Determine whether there are valid leased resources in the cluster based on the lease term;
[0015] If there are valid lease resources in the cluster, then determine whether there is a current holder of valid lease resources among the healthy member nodes;
[0016] If a current holder exists among the healthy member nodes, then the current holder's master node permissions will be maintained;
[0017] If there is no current holder among the healthy member nodes, then a lease contention process is performed based on the healthy member nodes to determine the holder of the master node permissions among the healthy member nodes, and the master-slave node permissions of the holder of the master node permissions are updated.
[0018] In one possible design, based on the healthy member nodes, a lease contention process is performed to determine the holder of master node permissions among the healthy member nodes, including:
[0019] Obtain the member identification information and operational indicator data of healthy member nodes;
[0020] The health priority of healthy member nodes is determined based on the member identification information and operational indicator data they carry.
[0021] Based on health priority, the holder of master node permissions is determined among the healthy member nodes.
[0022] In one possible design, after determining whether there are valid leased resources in the cluster based on the lease term, the following steps are also included:
[0023] If there are no valid lease resources in the cluster, the node health check of the cluster is performed again to update healthy member nodes and update unhealthy member nodes.
[0024] Based on the resource information, a lease contention process is performed on the updated healthy member nodes to determine the holder of master node permissions among the updated healthy member nodes.
[0025] In one possible design, after determining the health status of member nodes based on operational metric data to identify healthy and unhealthy member nodes, the following steps are also included:
[0026] Detect whether unhealthy member nodes have valid lease resources;
[0027] If a non-healthy member node has valid lease resources, then release the lease lock of the non-healthy member node;
[0028] If a non-healthy member node does not have a valid lease resource, then restore the database corresponding to the database instance;
[0029] An alarm for abnormal cluster status is triggered based on unhealthy member nodes.
[0030] In one possible design, cluster abnormal state alarms are triggered based on unhealthy member nodes, including:
[0031] Obtain the abnormal status types of unhealthy member nodes; among which, abnormal status types include member health check failure type and lease competition failure type;
[0032] Trigger cluster abnormal status alarms based on the type of abnormal status.
[0033] In one possible design, a database instance includes associated resource information and database instance creation information; wherein,
[0034] Associated resource information includes resource type and version information, as well as specific metadata of the resource instance;
[0035] Database instance creation information includes expected state information and current state information.
[0036] In one possible design, performance metrics include multiple metrics such as CPU utilization, memory utilization, network latency, and database connection count.
[0037] Secondly, this application provides a state control device for a database instance, comprising:
[0038] The monitoring module is used to monitor the database instance to be controlled in real time in order to obtain the running status of the database instance to be controlled.
[0039] The data acquisition module is used to collect the operating metric data of the member nodes of the database instance to be controlled if the running status of the database instance to be controlled is "running"; where the member nodes are the master node and slave node in the cluster corresponding to the database instance.
[0040] The first judgment module is used to determine the health status of member nodes based on operational indicator data, so as to identify healthy and unhealthy member nodes.
[0041] The acquisition module is used to obtain resource information about leased resources in the cluster;
[0042] The update module is used to update the master and slave node permissions of healthy member nodes based on the resource information of the leased resources.
[0043] Thirdly, this application provides a state control device for a database instance, including: a memory and a processor;
[0044] The memory stores instructions that the computer executes;
[0045] The processor executes computer execution instructions stored in memory, causing the processor to execute the state control method of the database instance as described in the first aspect of the invention.
[0046] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement a state control method for a database instance as described in the first aspect of the invention.
[0047] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements a state control method for a database instance as described in the first aspect of the invention.
[0048] This application provides a method, apparatus, device, medium, and product for controlling the state of a database instance, comprising: real-time monitoring of the database instance to be controlled to obtain its operating status; if the database instance to be controlled is in operation, collecting operating indicator data of the member nodes of the database instance to be controlled; determining the node health status of the member nodes based on the operating indicator data to obtain healthy and unhealthy member nodes; obtaining resource information of the leased resources of the cluster; and updating the master-slave node permissions of the healthy member nodes based on the resource information of the leased resources. Compared with existing technologies where database scheduling and management cannot achieve complex management functions and requires manual intervention and third-party tools, resulting in low efficiency of database instance state control, this application combines real-time monitoring of database instance policy information to achieve automatic configuration and maintenance of the database cluster, reducing manual intervention and thus improving the efficiency of database instance state control. Attached Figure Description
[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0050] Figure 1 A schematic diagram of the system architecture of a database instance state control method provided in this application embodiment;
[0051] Figure 2 A schematic flowchart of a database instance state control method provided in this application embodiment. Figure 1 ;
[0052] Figure 3 A schematic diagram of the design structure of the instance set provided in the embodiments of this application;
[0053] Figure 4 A schematic flowchart of a database instance state control method provided in this application embodiment. Figure 2 ;
[0054] Figure 5 A schematic flowchart of a database instance state control method provided in this application embodiment. Figure 3 ;
[0055] Figure 6 A schematic diagram illustrating the high availability design and mechanism operation flow of the instance set provided in this application embodiment;
[0056] Figure 7 A schematic diagram of the state control device for a database instance provided in this application embodiment;
[0057] Figure 8 This is a schematic diagram of the structure of a database instance state control device provided in an embodiment of this application. Detailed Implementation
[0058] 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.
[0059] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, nor do they necessarily imply difference. It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.
[0060] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the database instance state control method provided in the embodiments of this application is merely an example, and the database instance state control method may include more or less content.
[0061] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:
[0062] Kubernetes (K8s) is an open-source container orchestration system used to automate the deployment, scaling, and management of containerized applications.
[0063] An instance set is used to manage a group of instances (each instance typically corresponds to a Pod), and is especially suitable for efficient orchestration of stateful applications such as databases.
[0064] In cloud-native architectures, enterprises have increasingly complex needs for database deployment and management. With the widespread adoption of containerization technology, Kubernetes has become the mainstream container orchestration platform, but its native resources have significant limitations when managing database instances. Typical scenarios include:
[0065] Optionally, automated deployment of distributed database clusters cannot be achieved: enterprises need to quickly build highly available database clusters across availability zones and regions, but traditional Kubernetes cannot understand the topological relationships of database roles (such as master nodes and slave nodes), resulting in operations such as scaling and fault recovery relying on manual intervention.
[0066] Optionally, it is not possible to achieve unified management of heterogeneous databases: the configuration and operation and maintenance logic of existing databases are quite different, and existing container orchestration tools lack the ability to abstract heterogeneous databases, resulting in high maintenance costs.
[0067] Optionally, dynamic resource scheduling and fault self-healing cannot be achieved: In cloud environments, database instances need to dynamically adjust resources (such as memory) according to the load, but traditional Kubernetes only schedules based on container status and cannot perceive the internal health status of the database (such as transaction consistency and log synchronization status), resulting in low resource utilization or delayed fault recovery.
[0068] Existing technologies primarily rely on Kubernetes native resources and third-party tools to achieve containerized deployment of databases, but they suffer from the following problems:
[0069] Missing role semantics: Kubernetes native resources only provide sequential numbers and stable network identifiers, which cannot express database-specific role relationships (such as master-slave replication topology). For example, when scaling up, it can only simply increase the number of replicas and cannot automatically configure master-slave replication links, resulting in a chaotic cluster topology.
[0070] On the one hand, health checks are incomplete: existing health check mechanisms (such as Liveness / Readiness probes) are based only on the container process status and cannot detect internal database anomalies (such as inconsistent transaction logs or connection pool overload). For example, when the MySQL master node experiences write delays due to log backlog, the container status may still show as normal, but the actual service is already unavailable.
[0071] On the one hand, data consistency guarantees are insufficient: traditional Kubernetes rolling updates or fault recovery do not consider database transaction consistency. For example, after a master node fails, data loss may occur when a slave node is promoted to a new master node due to inconsistent log sequence numbers.
[0072] On the one hand, heterogeneous database support is limited: existing solutions require developing independent deployment templates for different database types, lacking a unified abstract interface, which leads to high operational complexity.
[0073] On the one hand, providing only sequential numbers and stable network identifiers makes it impossible to understand the role relationships unique to the database.
[0074] On the one hand, when expanding capacity, you can only simply add replicas and cannot automatically configure the database replication topology.
[0075] On the other hand, the rolling update and fault recovery mechanisms do not take into account database data consistency.
[0076] To address the aforementioned issues, the inventors, during their research on the low efficiency of database instance state control, discovered that existing database scheduling and management technologies cannot achieve complex management functions, requiring manual intervention and third-party tools. Therefore, the inventors considered integrating semantics such as database roles (master / slave), replication topology, and health check policies into the Kubernetes resource model through custom resource definitions for instance sets. This allows Kubernetes to understand the database's business logic and topology, automatically configuring and maintaining the database cluster, reducing manual intervention. Based on this, embodiments of this application provide a database instance state control method, apparatus, device, medium, and product, applicable to the field of database management, aiming to solve the problem of low efficiency in existing database instance state control technologies.
[0077] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are 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 now be described with reference to the accompanying drawings.
[0078] Figure 1 This is a schematic diagram of the system architecture for a database instance state control method provided in an embodiment of this application. The state control system for this database instance is a computer device. Figure 1 In the above architecture, at least one of data acquisition device 101, processing device 102 and display device 103 is included.
[0079] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the processing system architecture of the database instance state control method. In other feasible embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or divide some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of both.
[0080] In the specific implementation process, the data acquisition device 101 may include an input / output interface or a communication interface. The data acquisition device 101 can be connected to the processing device through the input / output interface or the communication interface to monitor the database instance to be controlled in real time, so as to obtain the operating status of the database instance to be controlled.
[0081] Processing device 102 can update the master and slave node permissions of healthy member nodes based on the resource information of the leased resources.
[0082] The display device 103 can also be a touch screen or the screen of a terminal device, used to receive user commands while displaying the above-mentioned content, so as to realize interaction with the user.
[0083] It should be understood that the aforementioned processing device can be implemented by a processor reading instructions from memory and executing those instructions, or it can be implemented by a chip circuit.
[0084] Furthermore, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0085] The technical solution of this application will be described in detail below with reference to specific embodiments:
[0086] Figure 2 A schematic flowchart of a database instance state control method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the method includes:
[0087] S201. Monitor the database instance to be controlled in real time to obtain the running status of the database instance to be controlled.
[0088] The database instance includes associated resource information and database instance creation information.
[0089] The associated resource information includes resource type and version information, as well as specific metadata of the resource instance.
[0090] The database instance creation information includes expected state information and current state information.
[0091] For example, an InstanceSet running on Kubernetes contains the following:
[0092] Optional, the resource type and version information of the InstanceSet.
[0093] Optionally, Kubernetes resources have "identification identifiers" that the application programming interface server uses to identify resource types and execute corresponding processing logic, ensuring that the client and server agree on the definition of the resource.
[0094] Optional, the specific metadata of the resource instance of the InstanceSet.
[0095] Optionally, the "identity attributes" of Kubernetes resources support features such as tag filtering and namespace isolation, and are the foundation of Kubernetes resource management.
[0096] Optional, the expected state of the InstanceSet during operation.
[0097] Optional, the user explicitly declares the desired configuration goals they want the system to achieve through the InstanceSetSpec field. It is the core embodiment of the Kubernetes declarative application programming interface pattern, allowing the system to automatically implement and maintain the required state.
[0098] Optional, the current state of the InstanceSet during runtime.
[0099] Optionally, the real-time status during actual runtime is recorded by the InstanceSetStatus field, reflecting the degree to which the system achieves the user's expected state. This data is dynamically updated by the controller and is used to monitor the cluster's running status, track update progress, or diagnose anomalies. It is a direct representation of the "actual state" in the declarative application programming interface pattern.
[0100] In one possible embodiment, Figure 3 A schematic diagram of the design structure of the instance set provided in the embodiments of this application, such as Figure 3 As shown:
[0101] Optionally, the execution process of an instance set can be divided into four core stages, forming a closed-loop management mechanism.
[0102] First, in the resource information acquisition phase, InstanceSet interacts with Kubernetes to obtain basic data such as resource type and version information, resource instance metadata, etc., providing underlying resource definition and status support for subsequent operation.
[0103] Secondly, in the expected state setting phase, users define the expected state of the InstanceSet through the configuration interface, covering more than ten parameters such as basic configuration, availability control, template and instance configuration, storage configuration, and update strategy, thus clarifying the ideal goal of system operation.
[0104] Secondly, during the current status feedback phase, InstanceSet continuously collects data such as the basic status, replica status, version control, and condition status during actual operation, forming a dynamic current status information stream, which is then transmitted to the coordination module in real time.
[0105] Finally, in the state coordination phase, the instanceSet operator, as the core coordinator, compares the differences between the desired state and the current state, triggers adjustment operations (such as replica scaling, version upgrades, etc.), and pushes the current state to converge towards the desired state, ultimately achieving stable operation.
[0106] Optionally, the execution logic of the instance collection is driven by state consistency, and automated management is achieved through a "monitor-compare-adjust" loop mechanism.
[0107] Among them, the instanceSet operator, as the logical hub, undertakes three key functions:
[0108] Specifically, status monitoring continuously collects bidirectional data streams of the desired state (user-defined) and the current state (actual operation) to ensure the real-time nature and completeness of status information.
[0109] Specifically, difference analysis uses a preset strategy (such as update priority and availability constraints) to semantically analyze state differences, distinguishing between differences that "must be fixed" (such as insufficient replica count) and those that are "tolerable" (such as non-critical condition states).
[0110] Specifically, the operation execution involves calling underlying resource interfaces based on the difference analysis results to perform operations such as scaling up / down, configuration updates, and version switching. Throughout this process, user-defined strategies (such as rolling upgrades and maximum unavailable replica limits) are strictly followed to ensure that the adjustments meet business continuity requirements. This logic, through closed-loop control, achieves a precise mapping from user intent to the actual system state.
[0111] It should be noted that by using the operator to automatically coordinate state differences, replacing the traditional manual item-by-item inspection and adjustment mode, the state convergence time is significantly shortened (e.g., from several hours of manual operation to minutes of automatic adjustment). Especially in large-scale cluster scenarios, the management cost is reduced exponentially, thereby improving management efficiency.
[0112] It should be noted that by using two-way state binding (expected and current) and a strategic adjustment mechanism, the "configuration drift" problem in traditional management (such as the actual state not being synchronized after the user modifies the configuration) is completely solved, ensuring that resource instances always conform to the business definition and avoiding service anomalies or resource waste caused by inconsistent states, thereby achieving state consistency guarantee.
[0113] It should be noted that the built-in update strategies (such as rolling upgrades and phased pauses), availability controls (such as minimum number of available replicas), and fault tolerance mechanisms (such as state rollback) can minimize the impact on business operations during high-risk operations such as version upgrades and configuration changes, ensure the continuity of critical services, and improve the overall system reliability and resilience, thereby enhancing system stability.
[0114] S202. If the database instance to be controlled is in running status, then collect the running indicator data of the member nodes of the database instance to be controlled.
[0115] Member nodes are the master and slave nodes in the cluster corresponding to the database instance.
[0116] S203. Based on the operational indicator data, determine the node health status of member nodes to identify healthy and unhealthy member nodes.
[0117] The operational metrics include several of the following: CPU utilization, memory utilization, network latency, and number of database connections.
[0118] S204. Obtain resource information for the leased resources of the cluster.
[0119] S205. Update the master-slave node permissions of healthy member nodes based on the resource information of the leased resources.
[0120] It should be noted that InstanceSet requires the following components and features:
[0121] Optional, Kubernetes Pod: A Pod is the most basic unit of deployment and management, and the carrier of all applications. It represents a collection of one or more containers running in the cluster, which share network, storage, and lifecycle.
[0122] Optional, Kubernetes Service: Service discovery and load balancing, providing a unified network interface for a group of Pods.
[0123] Optional, Kubernetes ConfigMap: Stores application configurations (such as environment variables and configuration files) as a separate resource, avoiding hardcoding.
[0124] Optional, Kubernetes Secret: Securely stores sensitive data such as passwords, Application Programming Interface (API) keys, Transport Layer Security Certificates (TLS), etc., avoiding plaintext storage in Yet Another Markup Language (YAML) formats or environments.
[0125] Optional, Kubernetes PersistentVolume: Storage resources (such as shared volumes) in the cluster, pre-created by the administrator.
[0126] Optional, Kubernetes PersistentVolumeClaim: The user's storage request, declaring the required storage size and access mode.
[0127] Optional, Kubernetes StorageClass: Defines different types of storage for users to choose from as needed.
[0128] It should also be noted that, based on existing technologies and unique orchestration logic, this application also proposes a database high-availability switching logic based on Kubernetes lease resources.
[0129] Lease is an API resource in the coordination.k8s.io / v1 group of Kubernetes, used to coordinate the state and implement mutual exclusion access among cluster nodes / instances. In high availability scenarios, it is the core criterion for "master election"—the node / instance that acquires the Lease can obtain specific permissions (such as becoming the master node to handle write requests), while other nodes stand by as slave nodes.
[0130] This embodiment provides a database instance state control method, including: real-time monitoring of the database instance to be controlled to obtain its running status; if the database instance to be controlled is running, collecting the running indicator data of the member nodes of the database instance to be controlled; judging the node health status of the member nodes based on the running indicator data to obtain healthy and unhealthy member nodes; obtaining the resource information of the leased resources of the cluster; and updating the master-slave node permissions of the healthy member nodes based on the resource information of the leased resources. Compared with the existing database scheduling management, which cannot achieve complex management functions and requires manual intervention and third-party tools, resulting in low efficiency of database instance state control, this application combines real-time monitoring of database instance policy information to achieve automatic configuration and maintenance of the database cluster, reducing manual intervention and thus improving the efficiency of database instance state control.
[0131] Figure 4 A schematic flowchart of a database instance state control method provided in this application embodiment. Figure 2 ,like Figure 4 As shown, the resource information includes the lease term, so the specific implementation steps of S205 above include:
[0132] S401. Determine whether there are valid leased resources in the cluster based on the lease term.
[0133] S402. If there are valid lease resources in the cluster, determine whether there is a current holder of valid lease resources among the healthy member nodes.
[0134] It should be noted that the following steps are included after step S402:
[0135] Optionally, if there are no valid lease resources in the cluster, the node health check of the cluster is performed again to obtain updated healthy member nodes and updated unhealthy member nodes.
[0136] Furthermore, based on resource information, lease contention processing is performed on the updated healthy member nodes to determine the holder of master node permissions among the updated healthy member nodes.
[0137] S403. If a current holder exists among the healthy member nodes, then the current holder's master node permissions are maintained.
[0138] S404. If there is no current holder among the healthy member nodes, then according to the healthy member nodes, perform lease contention processing to determine the holder of the master node permission among the healthy member nodes, and update the master-slave node permissions of the holder of the master node permission.
[0139] It should be noted that step S404 specifically includes:
[0140] Specifically, obtain the member identification information and operational indicator data of healthy member nodes.
[0141] Specifically, the health priority of healthy member nodes is determined based on the member identification information and operational indicator data they carry.
[0142] Specifically, based on health priority, the holder of master node permissions is determined among the healthy member nodes.
[0143] Optionally, the operation process of cluster master node permission management can be divided into four core stages, forming a dynamically adjustable closed-loop mechanism.
[0144] First, in the lease validity check phase (S401), the system scans the status of all lease resources in the cluster based on the preset lease term parameters to determine whether there are any valid leases that have not expired (i.e., the remaining lease time is greater than zero or the expiration condition has not been triggered).
[0145] Specifically, if a valid lease exists, proceed to the next stage.
[0146] Specifically, if it does not exist, the lease reconstruction process is triggered, the node health check is re-executed (distinguishing between updated healthy member nodes and unhealthy member nodes), and a lease competition process is initiated for healthy nodes to ultimately determine the new master node permission holder.
[0147] Secondly, if a valid lease exists (S402), the process enters the holder verification stage, where the system checks whether the current list of healthy member nodes contains the holder of the valid lease (i.e., whether the node ID recorded in the lease is in the set of healthy nodes).
[0148] Specifically, if (S403) exists, the current holder's master node permissions are maintained directly, and the process ends.
[0149] Specifically, if it does not exist (S404), the lease competition phase begins. Based on the operating indicators (such as CPU, memory, network latency, etc.) and identification information (such as node identity and role labels) of healthy member nodes, a new master node is determined by priority ranking, and the permission allocation is updated.
[0150] Optionally, the process operates with a lease mechanism at its core, combined with health checks and priority competition, to achieve dynamic allocation and fault tolerance of master node permissions.
[0151] The lease serves as proof of legitimacy, ensuring that only nodes holding valid leases can exercise master node privileges, thus preventing unauthorized nodes from taking over.
[0152] Specifically, when a lease exists but the holder is unavailable (e.g., due to node failure or network isolation), the system quickly identifies the failed node through health checks and triggers a competition mechanism: it collects the operating metrics (e.g., load, response time) and identification information (e.g., deployment role, priority label) of healthy nodes, calculates health priority based on preset rules (e.g., lower load, higher priority, priority for nodes with specified roles), and finally selects the node with the highest priority as the new master node, completing a seamless switch of permissions.
[0153] It should be noted that this logic uses a three-layer filtering process of "lease verification - health confirmation - competitive election" to balance legitimacy, usability, and performance optimization.
[0154] It should be noted that this design structure brings three significant benefits.
[0155] On the one hand, the lease mechanism ensures the legitimacy of the master node's permissions, while health checks are combined to promptly remove failed nodes, avoiding interruptions to the main service due to node failures. Especially in distributed systems, this can significantly shorten fault recovery time (from the traditional manual intervention mode to automatic switching at the second level), thereby ensuring high availability.
[0156] On the one hand, during the lease competition phase, the optimal node is selected as the master node based on operational indicators (such as load), avoiding performance bottlenecks caused by high-load nodes being mistakenly selected as master nodes, improving the overall cluster's resource utilization and response efficiency, thereby achieving optimized resource utilization.
[0157] On the other hand, the dynamic updating of leases and the dynamic adjustment of healthy nodes enable the system to adapt to complex scenarios such as node additions and subtractions and network fluctuations, ensuring that the master node authority is always held by the available and best-performing node, reducing the risk of service anomalies caused by configuration errors or inconsistent states, thereby achieving enhanced fault tolerance and consistency.
[0158] In this embodiment, lease validity verification ensures the legality of cluster resource allocation and avoids permission confusion caused by invalid leases. When a valid lease exists, a healthy member node verification mechanism is used to accurately identify whether the current master node holder is available, maintaining the stability of its permissions. If the lease expires or the master node is unavailable, the healthy node list is updated and lease contention is executed. A health priority evaluation system, constructed by combining member identification information and operational indicator data, dynamically elects the optimal master node from among the healthy nodes, ultimately achieving rapid updates of master and slave node permissions and improving system fault tolerance. This effectively ensures the high availability and system stability of the cluster master node, reduces the impact of node failures on cluster services through a dynamic adjustment mechanism, improves the reliability and fault tolerance efficiency of the distributed system, and thus improves the state control efficiency of the database instance.
[0159] Figure 5 A schematic flowchart of a database instance state control method provided in this application embodiment. Figure 3 ,like Figure 5 As shown, the procedure following step S203 further includes:
[0160] S501, Detect whether there are valid lease resources for unhealthy member nodes.
[0161] S502. If a non-healthy member node has valid lease resources, then release the lease lock of the non-healthy member node.
[0162] S503. If a non-healthy member node does not have a valid lease resource, then restore the database corresponding to the database instance.
[0163] S504. Obtain the abnormal status type of unhealthy member nodes.
[0164] Among them, the abnormal status types include member health check failure type and lease competition failure abnormal type.
[0165] S505. Trigger cluster abnormal status alarms based on the abnormal status type.
[0166] Optionally, the abnormal handling process for unhealthy member nodes can be divided into five core stages, forming a closed-loop mechanism for fault diagnosis and repair.
[0167] First, in the lease status detection phase (S501), the system checks whether member nodes marked as unhealthy still hold valid lease resources (i.e., whether the lease has not expired and has not been actively released).
[0168] Specifically, if a valid lease exists (S502), the lease lock release phase begins, forcibly releasing the node's lock on the master node's permissions, thus avoiding permission freezes caused by an unhealthy node but an expired lease.
[0169] Specifically, if no valid lease exists (S503), the database recovery phase begins, where recovery operations (such as restarting the service, repairing data copies, and synchronizing master-slave data) are performed on the database instance associated with that node to ensure the consistency of the database state.
[0170] Secondly, after completing the lease or database processing, the process enters the anomaly diagnosis stage (S504). The system collects detailed anomaly information of unhealthy member nodes and identifies their anomaly status type (including "member health check failure" such as heartbeat timeout, service unavailable, or "lease contention failure" such as network interruption during contention, insufficient priority, etc.).
[0171] Finally, in the alarm triggering phase (S505), based on the diagnosed anomaly type, the system calls the preset alarm rules (such as triggering a "node unavailable" alarm when a health check fails, or triggering a "master node election anomaly" alarm when a lease contention fails) to push alarm information to the operation and maintenance personnel or monitoring system, thus completing the closed-loop processing of the fault.
[0172] Optionally, the process logic is centered on fault classification and resource release, combined with diagnosis and alarms to achieve precise operation and maintenance.
[0173] For unhealthy nodes, two scenarios are first distinguished through lease detection:
[0174] Specifically, if a node holds a valid lease, it means that it was once the master node but is currently unavailable. Releasing the lease lock at this time is a critical operation, which can prevent other healthy nodes from being unable to take over the master node's permissions due to the lease not being released, thus ensuring the continuity of cluster services.
[0175] Specifically, if a node has no valid lease, it means that it has never obtained master node privileges or the lease has expired. In this case, the focus shifts to database recovery to ensure the availability of data services associated with the node.
[0176] Among them, the identification of abnormal state types (S504) further refines the causes of failure: health check failure may point to underlying issues such as node hardware failure or network partitioning, while lease contention failure may be related to defects in the contention algorithm or node configuration problems.
[0177] Among them, type-based alarms (S505) enable operations and maintenance personnel to quickly locate the root cause of problems (such as distinguishing between "node downtime" and "election algorithm error"), thereby improving fault handling efficiency.
[0178] It should be noted that this logic, through a four-layer structure of "detection-processing-diagnosis-alarm," balances the timeliness of fault repair with the accuracy of cause analysis.
[0179] It should be noted that this design structure brings three significant benefits:
[0180] On the one hand, by forcibly releasing the lease locks of unhealthy nodes, the problem of master node permissions being stuck due to lease retention in the traditional model is avoided. Healthy nodes can quickly take over the service, shortening the fault recovery time (such as from several minutes of manual intervention to seconds of automatic release), thereby improving the efficiency of resource release.
[0181] On the one hand, for unhealthy nodes without leases, their database instances are directly restored to fix data inconsistencies or service interruptions caused by node anomalies, ensuring strong consistency of the distributed database, reducing the risk of data loss, and thus achieving data consistency assurance.
[0182] On the other hand, by subdividing abnormal status types and corresponding alarms, operations and maintenance personnel can quickly identify the root cause of the fault (such as distinguishing between "node hardware failure" and "election configuration error"), and take targeted repair measures (such as restarting the node or adjusting the competition strategy), reducing the cost of blind troubleshooting, improving the maintainability and stability of the overall system, and thus enhancing the accuracy of operations and maintenance.
[0183] In this embodiment, by employing a lease validity detection and classification mechanism for unhealthy member nodes, combined with database recovery and anomaly diagnosis technologies, precise handling of faulty nodes and rapid system recovery are achieved. Through a technical chain of "detection-release-recovery-diagnosis-alarm," the fault recovery time is effectively shortened (from minutes of manual intervention to seconds of automatic processing), reducing the risk of data loss and improving operational accuracy and overall system reliability. This, in turn, enhances the efficiency of database instance state control.
[0184] This application also provides an embodiment, Figure 6 A schematic diagram illustrating the high availability design and mechanism operation flow of the instance set provided in the embodiments of this application is shown below. Figure 6 As shown:
[0185] Optionally, the high availability design and mechanism operation process of the instance set can be divided into five core stages, forming a complete closed loop from startup to fault recovery.
[0186] Specifically, during the startup phase, the system first initializes the database instance through the database startup module to ensure the availability of basic services. Then, it enters the health check phase, where the node health check module periodically scans the running status of each node (such as service processes and network connectivity), while the cluster health check module assesses the overall health of the cluster from a global perspective (such as the number of nodes and master-slave synchronization status).
[0187] Specifically, the lease management phase is a key branch point in the process: for healthy nodes, the system checks whether they hold a valid lease (i.e., whether they are authorized to be the master database).
[0188] If a node does not hold a lease, it attempts to compete for the "lease lock" through the lease management module. If the competition fails (e.g., another node has already acquired the lease), a database recovery operation is triggered (e.g., restarting the service or repairing data replicas). For nodes that already hold a lease but are marked as abnormal (e.g., heartbeat timeout), the system will forcibly downgrade them to the primary database, release the lease lock, and prevent permission freezes.
[0189] Specifically, the master-slave switchover phase is triggered when the lease changes or a node fails: if the original master is downgraded due to an anomaly, a healthy node becomes the new master through lease competition, and the original master switches to a slave and synchronizes data; if the cluster as a whole is unhealthy (such as most nodes failing), an alarm is sent to Kubernetes through the event notification module, waiting for manual intervention or cluster self-healing.
[0190] More specifically, the system ultimately synchronizes status changes (such as master database switching and node recovery) to the external management platform in real time through the event notification phase, thus completing the process loop.
[0191] Optionally, the design uses multi-level fault tolerance and dynamic authorization as its core logic, and achieves high availability through four collaborative mechanisms.
[0192] Among them, the health check mechanism is the foundation, which accurately identifies the scope of the fault through two-layer checks at the node level (single node service status) and the cluster level (overall topology and data consistency) (such as distinguishing between "single node network fluctuations" and "cluster partitions").
[0193] The lease management mechanism is the core, which ensures the uniqueness of the master database through "lease lock": healthy nodes must compete to obtain a lease in order to become the master database, and the lease must be renewed regularly (e.g., through a heartbeat mechanism) to prevent invalid nodes from occupying permissions for a long time; the leases of abnormal master databases will be forcibly released to ensure rapid transfer of permissions.
[0194] Among these, the master-slave failover mechanism is crucial for fault recovery. Combining lease status and health check results, it automatically executes a "degradation-election-promotion" process (e.g., demoting a failed master to a slave and electing the healthiest node as the new master) to ensure service continuity. The event notification mechanism serves as an external interface, pushing internal state changes (such as master failover and node recovery) to management platforms like Kubernetes in real time, supporting automated operations and maintenance (e.g., automatically adjusting load balancing and triggering backup tasks).
[0195] It should be noted that the four mechanisms achieve full automation of the entire process from fault detection to service recovery through the logical chain of "inspection-authorization-switch-notification".
[0196] It should be noted that this high-availability design brings three significant benefits:
[0197] On the one hand, through the rapid linkage of health checks and master-slave switching, when the master database fails, permission transfer can be completed within seconds (such as switching from a failed node to a healthy node), avoiding service interruption. Especially in high-concurrency scenarios, this ensures user experience and business continuity, thereby achieving service continuity assurance.
[0198] On the one hand, the lease management mechanism ensures that only healthy and optimally performing nodes hold master database permissions (such as selecting the master database through load indicators), avoiding performance bottlenecks caused by high-load nodes being mistakenly selected as the master database, improving the overall cluster resource efficiency, and thus optimizing resource utilization.
[0199] On the other hand, the integration of the event notification mechanism with Kubernetes transforms fault handling from manual intervention to automated platform response (such as automatically triggering master database switching and generating alarm logs), significantly reducing the workload of operations and maintenance personnel. At the same time, through precise event classification (such as distinguishing between "single node failure" and "cluster-level failure"), the efficiency of fault location and repair is improved, thereby reducing operation and maintenance costs.
[0200] For example, the mechanism operation steps of the above instance set are as follows:
[0201] The first step is to use database client tools or Kubernetes probes (such as the exec probe to execute commands like pg_isready (PostgreSQL) or mysqladmin ping (MySQL)) to check if the database instance is running and accessible, and then proceed to the corresponding branch based on the returned results.
[0202] The second step involves collecting metrics such as CPU usage, memory usage, network latency, and database connection count of member nodes, setting thresholds (e.g., CPU usage exceeding 80% for 5 consecutive minutes is considered unhealthy), determining the health status of members, and driving subsequent lease and recovery processes.
[0203] The third step is to call the Kubernetes API to create or update lease resources. By setting the lease term and including member identifiers, lease competition is implemented, with the healthiest member getting the lease first.
[0204] The fourth step, when promoting a node to master, triggers the database cluster master-slave switching logic (such as MySQL's CHANGE MASTERTO or PostgreSQL's streaming replication master-slave switching command), and sets the node that acquired the lease as the master node.
[0205] Optionally, during a downgrade, the switch operation is reversed, releasing lease resources and relinquishing master node permissions.
[0206] The fifth step is to delete or mark a lease as invalid via the Kubernetes API to ensure that other nodes can compete for the lease again. The release operation needs to be coordinated with processes such as role downgrading and state synchronization to ensure the consistency of the cluster state.
[0207] Step 7: For unhealthy members, operations such as restarting containers, migrating loads, and repairing networks can be performed. If the database instance is abnormal, the database self-healing process is triggered (such as backup-based recovery and automatic rebuilding of slave nodes). After the member's health status is restored, it can re-participate in cluster lease competition and role coordination.
[0208] By leveraging the Kubernetes Event mechanism, abnormal cluster states (such as member health check failures or lease contention anomalies) are output as events or alarms, enabling operations and maintenance personnel to perceive and intervene in real time.
[0209] Figure 7 A schematic diagram of the state control device for a database instance provided in this application embodiment is shown below. Figure 7 As shown, the device includes: a monitoring module 71, a data acquisition module 72, a first judgment module 73, an acquisition module 74, and an update module 75.
[0210] The monitoring module 71 is used to monitor the database instance to be controlled in real time in order to obtain the running status of the database instance to be controlled.
[0211] The acquisition module 72 is used to acquire the operating indicator data of the member nodes of the database instance to be controlled if the running status of the database instance to be controlled is running; wherein, the member nodes are the master node and slave node in the cluster corresponding to the database instance.
[0212] The first judgment module 73 is used to judge the node health status of member nodes based on the operation index data, so as to obtain healthy member nodes and unhealthy member nodes.
[0213] Module 74 is used to obtain resource information of leased resources in the cluster;
[0214] Update module 75 is used to update the master and slave node permissions of healthy member nodes based on the resource information of the leased resources.
[0215] In one possible design, resource information includes the lease term;
[0216] Accordingly, based on the resource information of the leased resources, the master and slave node permissions of healthy member nodes are updated, including:
[0217] The update module 75 is also used to determine whether there are valid lease resources in the cluster based on the lease term;
[0218] If there are valid lease resources in the cluster, then determine whether there is a current holder of valid lease resources among the healthy member nodes;
[0219] If a current holder exists among the healthy member nodes, then the current holder's master node permissions will be maintained;
[0220] If there is no current holder among the healthy member nodes, then a lease contention process is performed based on the healthy member nodes to determine the holder of the master node permissions among the healthy member nodes, and the master-slave node permissions of the holder of the master node permissions are updated.
[0221] In one possible design, based on the healthy member nodes, a lease contention process is performed to determine the holder of master node permissions among the healthy member nodes, including:
[0222] The update module 75 is also used to obtain the member identification information and operational indicator data of healthy member nodes;
[0223] The health priority of healthy member nodes is determined based on the member identification information and operational indicator data they carry.
[0224] Based on health priority, the holder of master node permissions is determined among the healthy member nodes.
[0225] In one possible design, after determining whether there are valid leased resources in the cluster based on the lease term, the following steps are also included:
[0226] The update module 75 is also used to re-check the node health of the cluster if there are no valid lease resources in the cluster, so as to update healthy member nodes and update unhealthy member nodes.
[0227] Based on the resource information, a lease contention process is performed on the updated healthy member nodes to determine the holder of master node permissions among the updated healthy member nodes.
[0228] In one possible design, after determining the health status of member nodes based on operational metric data to identify healthy and unhealthy member nodes, the following steps are also included:
[0229] The first judgment module 73 is also used to detect whether unhealthy member nodes have valid lease resources;
[0230] If a non-healthy member node has valid lease resources, then release the lease lock of the non-healthy member node;
[0231] If a non-healthy member node does not have a valid lease resource, then restore the database corresponding to the database instance;
[0232] An alarm for abnormal cluster status is triggered based on unhealthy member nodes.
[0233] In one possible design, cluster abnormal state alarms are triggered based on unhealthy member nodes, including:
[0234] The first judgment module 73 is also used to obtain the abnormal status type of unhealthy member nodes; among which, the abnormal status type includes member health check failure type and lease competition failure abnormal type;
[0235] Trigger cluster abnormal status alarms based on the type of abnormal status.
[0236] In one possible design, a database instance includes associated resource information and database instance creation information; wherein,
[0237] Associated resource information includes resource type and version information, as well as specific metadata of the resource instance;
[0238] Database instance creation information includes expected state information and current state information.
[0239] In one possible design, performance metrics include multiple metrics such as CPU utilization, memory utilization, network latency, and database connection count.
[0240] This embodiment provides a database instance state control device that can execute a database instance state control method of the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.
[0241] In the specific implementation of the aforementioned database instance state control method, each module can be implemented as a processor. The processor can execute computer execution instructions stored in memory, thereby enabling the processor to execute the aforementioned database instance state control method.
[0242] Figure 8 This is a schematic diagram of the structure of a database instance state control device provided in an embodiment of this application. Figure 8 As shown, the state control device 80 of the database instance includes at least one processor 81 and a memory 82. The state control device 80 of the database instance also includes a communication component 83. The processor 81, memory 82, and communication component 83 are connected via a bus 84.
[0243] In the specific implementation process, at least one processor 81 executes computer execution instructions stored in memory 82, causing at least one processor 81 to execute a database management method executed by the state control device side of the database instance above.
[0244] The specific implementation process of processor 81 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0245] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0246] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.
[0247] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0248] The functions implemented by the state control device and master control device of the database instance described above illustrate the solution provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the state control device or master control device of the database instance includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solution of the embodiments of the present invention.
[0249] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the above-described method in the field of database management.
[0250] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0251] 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. Alternatively, the readable storage medium can be an integral part of the processor. Both 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 state control device or master device of the database instance.
[0252] This application also provides a computer program product, comprising: a computer program stored in a readable storage medium, at least one processor of a database instance state control device being able to read the computer program from the readable storage medium, and at least one processor executing the computer program causing the database instance state control device to perform the scheme provided in any of the above embodiments.
[0253] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.
[0254] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A method of state control of a database instance, characterized by, The method comprises: monitoring a database instance to be controlled in real time to obtain a running state of the database instance to be controlled; if the running state of the database instance to be controlled is running, collecting running index data of a member node of the database instance to be controlled; wherein the member node is a master node and a slave node in a cluster corresponding to the database instance; judging a node health state of the member node according to the running index data to obtain a healthy member node and a non-healthy member node; obtaining resource information of a lease resource of the cluster; updating master-slave node permissions of the healthy member node according to the resource information of the lease resource.
2. The method of claim 1, wherein, The resource information comprises a lease period; Correspondingly, the updating of the master-slave node permissions of the healthy member node according to the resource information of the lease resource comprises: judging whether there is a valid lease resource in the cluster according to the lease period; if there is a valid lease resource in the cluster, judging whether there is a current holder of the valid lease resource in the healthy member node; if there is the current holder in the healthy member node, maintaining master node permissions of the current holder; if there is no current holder in the healthy member node, performing lease competition processing according to the healthy member node to determine a holder of the master node permissions in the healthy member node, and updating master-slave node permissions of the holder of the master node permissions.
3. The method of claim 2, wherein, The performing of the lease competition processing according to the healthy member node to determine the holder of the master node permissions in the healthy member node comprises: obtaining member identification information and running index data carried by the healthy member node; judging a health priority of the healthy member node according to the member identification information and the running index data; determining the holder of the master node permissions in the healthy member node according to the health priority.
4. The method of claim 2, wherein, After the judging of whether there is a valid lease resource in the cluster according to the lease period, the method further comprises: if there is no valid lease resource in the cluster, performing node health checking on the cluster again to obtain updated healthy member nodes and updated non-healthy member nodes; performing lease competition processing on the updated healthy member nodes according to the resource information to determine a holder of the master node permissions in the updated healthy member nodes.
5. The method according to any one of claims 1 to 4, characterized in that, After the judging of the node health state of the member node according to the running index data to obtain the healthy member node and the non-healthy member node, the method further comprises: detecting whether there is a valid lease resource in the non-healthy member node; if there is a valid lease resource in the non-healthy member node, releasing a lease lock of the non-healthy member node; if there is no valid lease resource in the non-healthy member node, restoring a database corresponding to the database instance; triggering cluster abnormal state alarm according to the non-healthy member node.
6. The method of claim 5, wherein, The triggering of the cluster abnormal state alarm according to the non-healthy member node comprises: An abnormal state type of the unhealthy member node is acquired; wherein the abnormal state type includes a member health check failure type and a lease competition failure abnormal type; According to the abnormal state type, a cluster abnormal state alarm is triggered.
7. The method according to any one of claims 1 to 4, characterized in that, The database instance includes associated resource information and database instance creation information; wherein, The associated resource information includes resource type and version information and specific metadata of resource instances; The database instance creation information includes desired state information and current state information.
8. The method according to any one of claims 1 to 4, characterized in that, The running index data includes multiple of central processing unit usage, memory usage, network delay and database connection number.
9. An apparatus for controlling a state of a database instance, characterized by comprising: Comprising: A monitoring module for real-time monitoring of a database instance to be controlled to obtain the running state of the database instance to be controlled; A collection module for collecting running index data of member nodes of the database instance to be controlled if the running state of the database instance to be controlled is running; wherein the member nodes are master nodes and slave nodes in a cluster corresponding to the database instance; A first judgment module for judging the node health state of the member nodes according to the running index data to obtain healthy member nodes and unhealthy member nodes; An acquisition module for acquiring resource information of a lease resource of a cluster; An update module for updating the master-slave node authority of the healthy member nodes according to the resource information of the lease resource.
10. A state control apparatus of a database instance, characterized by comprising: Comprising: A memory, a processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the processor executes the method of any one of claims 1-8.
11. A computer readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1-8.
12. A computer program product, characterised in that, A computer program is executed by the processor to implement the method of any one of claims 1-8.