Database processing method and apparatus, electronic device, and computer readable medium

Abstract

The application discloses a database processing method and device, electronic equipment and computer readable medium, relates to the technical field of computers, and the method comprises the following steps: receiving a database processing request, obtaining a corresponding cluster resource identifier, determining at least one distributed node corresponding to the cluster resource identifier; obtaining the node state identifier of the at least one distributed node, and then determining the corresponding node life cycle stage according to the node state identifier; obtaining the corresponding expected node state identifier according to the node life cycle stage, and then determining the to-be-scheduled resource based on the node state identifier and the expected node state identifier; executing the process of scheduling the to-be-scheduled resource, receiving the returned scheduling result information, and then updating the node state identifier based on the scheduling result information until the node state identifier is updated to the expected node state identifier. It has reentrant capability, can guarantee the atomicity of the variable allocation operation, is simple to code, and reduces the probability of introducing program errors.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a database processing method, apparatus, electronic device, and computer-readable medium. Background Technology

[0002] When changing the CPU, memory, storage space size, and storage type of a database instance, imperative coding is used. This requires decomposing all the operations of the change into code and organizing them in the order of execution. The coding implementation is complex, the atomicity of the change operations cannot be guaranteed, and retry and error handling logic needs to be added for each step, making the coding complex.

[0003] In the process of developing this application, the inventors discovered at least the following problems in the prior art:

[0004] Using imperative coding to modify the database can lead to unexpected overall processes due to the interrelationship between steps. Adding or deleting some logic or functions can result in complex coding and introduce program errors. Summary of the Invention

[0005] In view of this, embodiments of this application provide a database processing method, apparatus, electronic device, and computer-readable medium, which can solve the problems of existing database configuration methods that use imperative coding, where the steps are related and adding or deleting some logic and functions can lead to an overall process that does not meet expectations, complex coding, and easy introduction of program errors.

[0006] To achieve the above objectives, according to one aspect of an embodiment of this application, a database processing method is provided, comprising:

[0007] Receive database processing requests, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier;

[0008] Obtain the node status identifier of at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier;

[0009] Obtain the corresponding expected node status identifier based on the node lifecycle stage, and then determine the resources to be scheduled based on the node status identifier and the expected node status identifier.

[0010] The process executes the scheduling of resources to be scheduled, receives the returned scheduling result information, and then updates the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier.

[0011] Optionally, before receiving a database processing request, the method further includes:

[0012] In response to a cluster resource processing event being detected, the cluster resource processing event is sent to the event queue;

[0013] In response to retrieving cluster resource processing events from the event queue, a corresponding database processing request is generated.

[0014] Optionally, before updating the node status identifier based on the scheduling result information, the method further includes:

[0015] In response to the scheduling result information indicating that the resource scheduling failed, the cluster resource processing event is added back to the event queue.

[0016] Optionally, the node status identifier is updated based on the scheduling result information, including:

[0017] In response to the scheduling result information indicating that the resource has been successfully scheduled and the node has been added in the corresponding lifecycle stage, a new distributed node is created based on the successfully scheduled resource, and the node status identifier of the new distributed node is updated to the ready identifier.

[0018] Optionally, the resources to be scheduled are determined based on the node status identifier and the expected node status identifier, including:

[0019] Determine the number of cluster replicas corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the expected node status identifier;

[0020] The number of distributed nodes to be created is determined based on the number of cluster replicas and the number of distributed nodes corresponding to the expected node status identifiers.

[0021] Based on the number of distributed nodes to be created and the expected node status identifiers, the resources to be scheduled are determined.

[0022] Optionally, the resources to be scheduled are determined based on the node status identifier and the expected node status identifier, including:

[0023] Determine the threshold number of nodes in the creation state corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the node creation state identifier;

[0024] The number of distributed nodes to be created is determined based on the node number threshold and the number of distributed nodes corresponding to the status identifiers of nodes being created.

[0025] Based on the number of distributed nodes to be created and the expected node status identifiers, the resources to be scheduled are determined.

[0026] Optionally, before determining the resource to be scheduled based on the node status identifier and the expected node status identifier, the method further includes:

[0027] In response to the update of the corresponding node in the lifecycle stage, iterate through the existing distributed nodes in the cluster corresponding to the cluster resource identifier and determine the distributed nodes that are in the marked deletion state.

[0028] Determine the number of distributed nodes in the ready state in the cluster. In response to a distributed node in the marked-for-deletion state not being the master in the cluster and the number of distributed nodes in the ready state in the cluster reaching a preset threshold, remove the deletion protection flag of the distributed node in the marked-for-deletion state.

[0029] Optionally, before determining the resource to be scheduled based on the node status identifier and the expected node status identifier, the method further includes:

[0030] In response to the deletion of a node corresponding to a node's lifecycle stage, determine the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas corresponding to the cluster resource identifier in the cluster.

[0031] Based on the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas, determine the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion.

[0032] The deletion process is performed on the corresponding distributed nodes based on the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion.

[0033] Optionally, before determining the resource to be scheduled based on the node status identifier and the expected node status identifier, the method further includes:

[0034] In response to the role switching in the node lifecycle phase, determine the corresponding triggering strategy;

[0035] In response to the triggering policy, immediately switch the process that switches the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state.

[0036] In response to the switching of the operation and maintenance window corresponding to the triggering policy and the current time being within the cluster operation and maintenance window, a process is triggered to switch the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state.

[0037] In addition, this application also provides a database processing apparatus, including:

[0038] The receiving unit is configured to receive database processing requests, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier.

[0039] The node lifecycle stage determination unit is configured to obtain the node status identifier of at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier.

[0040] The resource to be scheduled determination unit is configured to obtain the corresponding expected node status identifier according to the node lifecycle stage, and then determine the resource to be scheduled based on the node status identifier and the expected node status identifier.

[0041] The execution unit is configured to execute the process that schedules the resources to be scheduled, and receive the returned scheduling result information. Then, it updates the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier.

[0042] Optionally, the database processing apparatus further includes a request generation unit, configured to:

[0043] In response to a cluster resource processing event being detected, the cluster resource processing event is sent to the event queue;

[0044] In response to retrieving cluster resource processing events from the event queue, a corresponding database processing request is generated.

[0045] Optionally, the execution unit is further configured to:

[0046] In response to the scheduling result information indicating that the resource scheduling failed, the cluster resource processing event is added back to the event queue.

[0047] Optionally, the execution unit is further configured to:

[0048] In response to the scheduling result information indicating that the resource has been successfully scheduled and the node has been added in the corresponding lifecycle stage, a new distributed node is created based on the successfully scheduled resource, and the node status identifier of the new distributed node is updated to the ready identifier.

[0049] Optionally, the resource determination unit to be scheduled is further configured as follows:

[0050] Determine the number of cluster replicas corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the expected node status identifier;

[0051] The number of distributed nodes to be created is determined based on the number of cluster replicas and the number of distributed nodes corresponding to the expected node status identifiers.

[0052] Based on the number of distributed nodes to be created and the expected node status identifiers, the resources to be scheduled are determined.

[0053] Optionally, the resource determination unit to be scheduled is further configured as follows:

[0054] Determine the threshold number of nodes in the creation state corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the node creation state identifier;

[0055] The number of distributed nodes to be created is determined based on the node number threshold and the number of distributed nodes corresponding to the status identifiers of nodes being created.

[0056] Based on the number of distributed nodes to be created and the expected node status identifiers, the resources to be scheduled are determined.

[0057] Optionally, the database processing apparatus further includes a node update unit, configured to:

[0058] In response to the update of the corresponding node in the lifecycle stage, iterate through the existing distributed nodes in the cluster corresponding to the cluster resource identifier and determine the distributed nodes that are in the marked deletion state.

[0059] Determine the number of distributed nodes in the ready state in the cluster. In response to a distributed node in the marked-for-deletion state not being the master in the cluster and the number of distributed nodes in the ready state in the cluster reaching a preset threshold, remove the deletion protection flag of the distributed node in the marked-for-deletion state.

[0060] Optionally, the data processing apparatus further includes a node deletion unit, configured to:

[0061] In response to the deletion of a node corresponding to a node's lifecycle stage, determine the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas corresponding to the cluster resource identifier in the cluster.

[0062] Based on the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas, determine the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion.

[0063] The deletion process is performed on the corresponding distributed nodes based on the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion.

[0064] Optionally, the data processing device also includes a role switching unit, configured to:

[0065] In response to the role switching in the node lifecycle phase, determine the corresponding triggering strategy;

[0066] In response to the triggering policy, immediately switch the process that switches the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state.

[0067] In response to the switching of the operation and maintenance window corresponding to the triggering policy and the current time being within the cluster operation and maintenance window, a process is triggered to switch the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state.

[0068] In addition, this application also provides a database processing electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the database processing method described above.

[0069] In addition, this application also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the database processing method described above.

[0070] One embodiment of the above invention has the following advantages or beneficial effects: This application receives a database processing request, obtains the corresponding cluster resource identifier, and determines at least one corresponding distributed node based on the cluster resource identifier; obtains the node status identifier of at least one distributed node, and then determines the corresponding node lifecycle stage based on the node status identifier; obtains the corresponding expected node status identifier based on the node lifecycle stage, and then determines the resource to be scheduled based on the node status identifier and the expected node status identifier; executes the process of scheduling the resource to be scheduled, and receives the returned scheduling result information, and then updates the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier. After splitting various configuration change-related operations into different lifecycle stages, determining the corresponding node lifecycle stage based on the node status identifier, determining the resource to be scheduled based on the node status identifier and the expected node status identifier, and then performing the conversion of the node status identifier to the expected node status identifier, it has reentrancy capability, can guarantee the atomicity of configuration change operations, has simple coding implementation, and reduces the probability of introducing program errors.

[0071] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0072] The accompanying drawings are provided to better understand this application and do not constitute an undue limitation thereof. Wherein:

[0073] Figure 1 This is a schematic diagram of the main flow of a database processing method provided according to an embodiment of this application;

[0074] Figure 2 This is a schematic diagram of the main flow of a database processing method provided according to an embodiment of this application;

[0075] Figure 3This is a schematic diagram of a database processing method provided according to an embodiment of this application;

[0076] Figure 4 This is a resource topology diagram of a MySQL cluster according to an embodiment of the database processing method provided in this application;

[0077] Figure 5 This is a schematic diagram of the execution logic of a MySQL controller for a database processing method provided according to an embodiment of this application;

[0078] Figure 6 This is a schematic diagram of the main units of a database processing apparatus according to an embodiment of this application;

[0079] Figure 7 This is an exemplary system architecture diagram to which embodiments of this application can be applied;

[0080] Figure 8 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers in the embodiments of this application. Detailed Implementation

[0081] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. The acquisition, storage, use, and processing of data in the technical solutions of this application all comply with relevant national laws and regulations.

[0082] Figure 1 This is a schematic diagram of the main flow of a database processing method provided according to an embodiment of this application, as shown below. Figure 1 As shown, the database processing methods include:

[0083] Step S101: Receive a database processing request, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier.

[0084] In this embodiment, the execution entity of the database processing method (e.g., a server) can receive database processing requests via wired or wireless connections. Specifically, the database processing request may be a request to change the CPU, memory, storage space size, or storage type (local storage, shared storage) of a database instance. This embodiment does not specifically limit the content of the database processing request. After receiving the database processing request, the execution entity can obtain the cluster resource identifier carried in the request to determine the resources of the corresponding database cluster to be processed. It can also obtain at least one distributed node corresponding to the resources of the database cluster to be processed; the distributed node may be, for example, a MySQL node. For example, such as... Figure 4 The diagram shows the resource topology of a database cluster (e.g., a MySQL cluster). A MySQL cluster is described by a "MySQL Cluster" CR (custom resource), which contains multiple Statefulset resources (determined by the number of cluster replicas). Each Statefulset represents a MySQL node. A MySQL cluster is a shared-nothing, distributed node architecture storage solution that achieves high fault tolerance and high performance.

[0085] Specifically, before receiving a database processing request, the database processing method also includes:

[0086] In response to a cluster resource processing event being detected, the cluster resource processing event is sent to the event queue; in response to a cluster resource processing event being retrieved from the event queue, a corresponding database processing request is generated.

[0087] In this embodiment, a MySQL cluster is built on the Kubernetes platform using default resources such as StatefulSet, ConfigMap, and Secret provided by Kubernetes. Various configuration-related operations are broken down and executed atomically. The MySQL controller detects the current state of the MySQL cluster and compares it with the expected state of the MySQL cluster recorded in ETCD. It then continuously executes relevant operations to transform the actual state of the MySQL cluster to the user's expected state. The MySQL controller listens to the "MySQL Cluster" resource in the Kubernetes API service and responds to different events related to the resource. For example, upon listening to a "Create" event for the "MySQL Cluster" resource, the MySQL controller responds to the event and creates a MySQL cluster that meets the expected specifications. The ETCD cluster is a component of the Kubernetes cluster; it is a three-replica, strongly consistent key-value store used to store various stateful data within the Kubernetes cluster.

[0088] MySQL controllers include, for example Figure 5 The five modules shown are: cluster status analysis module, node addition module, node update module, node deletion module, and role switching module. These five modules within the MySQL controller are independent of each other. Whenever a Kubernetes event related to MySQL cluster resources is detected, the event is placed in the MySQL controller's event queue. The controller then retrieves the event from the queue, generates a corresponding database processing request, and so on. Figure 5 The MySQL controller shown contains various modules that process the database request sequentially. If any module encounters an exception, the MySQL cluster resource is added back to the event queue, and the above process is repeated. Figure 5 Once the modules contained in the MySQL controller shown have executed successfully, the database processing process will exit normally.

[0089] Step S102: Obtain the node status identifier of at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier.

[0090] The executing entity can obtain the status identifier of at least one distributed node corresponding to the "MySQL cluster" resource to determine the status of at least one distributed node corresponding to the "MySQL cluster" resource. For example, the node status identifiers are BJSC and JX, representing the "marked for deletion" status and the "ready" status, respectively. The corresponding node lifecycle stage is determined based on the obtained node status identifiers of at least one distributed node. For example, the node lifecycle stage corresponding to node status identifier BJSC is the node deletion stage, and the node lifecycle stage corresponding to node status identifier JX is the role switching stage. This application embodiment does not specifically limit the correspondence between node status identifiers and node lifecycle stages.

[0091] Step S103: Obtain the corresponding expected node status identifier according to the node lifecycle stage, and then determine the resources to be scheduled based on the node status identifier and the expected node status identifier.

[0092] Before determining the resources to be scheduled, the execution entity can first perform cluster status analysis. Specifically, this can involve calling the cluster status analysis module of the MySQL controller to obtain all Statefulsets under the current MySQL cluster resources, analyzing the status of all Statefulsets, and comparing it with the user's expected MySQL cluster status. The analysis content is divided into the following two aspects: a) and b)

[0093] a) For each MySQL node (i.e., a single Statefulset):

[0094] The roles of a Statefulset (master, slave, unknown);

[0095] Is the Statefulset in a "marked for deletion" state?

[0096] Is the Statefulset in a "ready" state?

[0097] Does the Statefulset specification (CPU, memory, storage) meet expectations?

[0098] b) For clusters:

[0099] The number of StatefulSets in the "creating" state;

[0100] The number of Statefulsets that "meet expectations": those that meet the specifications and are not in the "marked for deletion" state;

[0101] The number of Statefulsets in the "ready" state: those that meet the specifications, are not in the "marked for deletion" state, and are in the "ready" state.

[0102] Does the cluster's "master database" meet expectations? That is, does the StatefulSet containing the "master database" meet expectations?

[0103] The collection of StatefulSets that can be promoted to the main library: all StatefulSets that are in the "ready" state.

[0104] Specifically, determining the resources to be scheduled based on node status identifiers and expected node status identifiers includes: determining the threshold number of nodes in the creation state corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the node status identifiers in the creation state; determining the number of distributed nodes to be created based on the node number threshold and the number of distributed nodes corresponding to the node status identifiers in the creation state; and determining the resources to be scheduled based on the number of distributed nodes to be created and the expected node status identifiers.

[0105] For example, after performing cluster state analysis, the executing entity determines, based on the output of the "Cluster State Analysis" module, whether the number of "Creating" Statefulsets is greater than the maximum number of nodes allowed in the cluster to be in the "Creating" state. Based on the determination result, it creates the corresponding number of Statefulsets. That is, if the number of "Creating" Statefulsets is less than the maximum number of nodes allowed in the cluster to be in the "Creating" state, it creates an equal number of Statefulsets to the number of "Creating" Statefulsets.

[0106] After determining the number of distributed nodes that need to be created (i.e., the number of distributed nodes to be created), the executing entity can determine the resources to be scheduled (i.e., the resources to be scheduled) based on the number of distributed nodes that need to be created and the expected node state identifiers corresponding to the states that need to be achieved.

[0107] Specifically, before determining the resources to be scheduled based on the node status identifier and the expected node status identifier, the method also includes:

[0108] In response to the update of the corresponding node in the lifecycle stage, it iterates through the existing distributed nodes in the cluster corresponding to the cluster resource identifier and identifies the distributed nodes in the marked-for-deletion state; it determines the number of distributed nodes in the ready state in the cluster, and when the distributed node in the marked-for-deletion state is not the master database in the cluster and the number of distributed nodes in the ready state in the cluster reaches a preset threshold, it removes the deletion protection identifier of the distributed node in the marked-for-deletion state.

[0109] For example, after performing cluster state analysis, the executing entity can call the "node update" module of the MySQL controller to traverse the existing nodes in the cluster and handle different situations accordingly:

[0110] Nodes in the "Creating" state: Skip.

[0111] Nodes in the "Mark for Deletion" state:

[0112] If the node is not the master in the cluster, and the number of Statefulsets in the "ready state" in the cluster meets the expectation (that is, reaches the preset threshold), the deletion protection flag of the node can be removed.

[0113] By using custom finalizers, a "node protection" feature can be added to enable features such as delayed node deletion and backup before node deletion.

[0114] Specifically, before determining the resources to be scheduled based on the node status identifier and the expected node status identifier, the method also includes:

[0115] In response to node deletion corresponding to a node's lifecycle stage, determine the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas in the cluster corresponding to the cluster resource identifier; based on the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas, determine the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion; and perform deletion processing on the corresponding distributed nodes based on the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion.

[0116] For example, after performing cluster status analysis, the executing entity can call the "node deletion" module of the MySQL controller to traverse the nodes in the cluster and perform deletion operations based on the cluster status and the status of the specified node:

[0117] In response to the number of Statefulsets in the "ready state" in the cluster being greater than or equal to the number of cluster replicas, nodes whose specifications "do not meet expectations" are marked for deletion.

[0118] If the number of "ready" Statefulsets in the cluster exceeds the number of cluster replicas, mark the redundant "ready" nodes for deletion.

[0119] If the number of "expected" Statefulsets in the cluster exceeds the number of cluster replicas, mark and delete the excess nodes that are not in the "ready state".

[0120] Specifically, before determining the resources to be scheduled based on the node status identifier and the expected node status identifier, the method further includes: determining the corresponding triggering strategy in response to the role switching corresponding to the node lifecycle stage; executing the process of switching the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state in response to the immediate switch corresponding to the triggering strategy; and triggering the process of switching the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state in response to the operation and maintenance window switching corresponding to the triggering strategy and the current time being within the cluster operation and maintenance window period.

[0121] For example, after performing cluster status analysis, the executing entity can perform role switching. The triggering conditions for role switching are: the node where the cluster's primary database resides does not meet expectations, or the number of Statefulsets in the "ready state" reaches the cluster replica count. Triggering strategies are: immediate switch and maintenance window switch. When the triggering conditions are met, a "high availability switch" operation is performed according to the triggering strategy. If the triggering condition is immediate switch: a "high availability switch" operation is immediately initiated, switching the cluster primary database to a Statefulset in the "ready state". If the triggering condition is maintenance window switch: it is determined whether the current time is within the cluster maintenance window period; if it is, an instance high availability switch is triggered.

[0122] Step S104: Execute the process of scheduling the resources to be scheduled, and receive the returned scheduling result information. Then, update the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier.

[0123] Specifically, before updating the node status identifier based on the scheduling result information, the method also includes: in response to the failure of resource scheduling corresponding to the scheduling result information, adding the cluster resource processing event back to the event queue.

[0124] Specifically, updating the node status identifier based on the scheduling result information includes: in response to the successful scheduling of the resource corresponding to the scheduling result information and the addition of the node corresponding to the node lifecycle stage, creating a new distributed node based on the successfully scheduled resource, and updating the node status identifier of the new distributed node to the ready identifier.

[0125] The various modules within the MySQL controller operate independently. Whenever a Kubernetes event related to MySQL cluster resources is detected, it is placed in the MySQL controller's event queue. Events are then retrieved from the queue and processed sequentially by each module. If a module encounters an exception (e.g., resource scheduling failure), the resource is re-added to the event queue, and the process repeats. If all modules execute successfully, the controller exits normally. When resource scheduling is successful and a new node is added corresponding to the lifecycle phase, a new distributed node is created based on the successfully scheduled resource, and the node status flag of the new distributed node is updated to the ready flag.

[0126] This embodiment receives a database processing request, obtains the corresponding cluster resource identifier, and determines at least one corresponding distributed node based on the cluster resource identifier; obtains the node status identifier of at least one distributed node, and then determines the corresponding node lifecycle stage based on the node status identifier; obtains the corresponding expected node status identifier based on the node lifecycle stage, and then determines the resource to be scheduled based on the node status identifier and the expected node status identifier; executes the process of scheduling the resource to be scheduled, receives the returned scheduling result information, and then updates the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier. After splitting various configuration change-related operations into different lifecycle stages, determining the corresponding node lifecycle stage based on the node status identifier, determining the resource to be scheduled based on the node status identifier and the expected node status identifier, and then performing the conversion from the node status identifier to the expected node status identifier, it has reentrancy capability, can guarantee the atomicity of configuration change operations, has simple coding implementation, and reduces the probability of introducing program errors.

[0127] Figure 2 This is a schematic diagram of the main flow of a database processing method provided according to an embodiment of this application, such as... Figure 2 As shown, the database processing methods include:

[0128] Step S201: Receive a database processing request, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier.

[0129] Database processing requests can be requests to change the CPU, memory, storage space size, or storage type (local storage, shared storage) of a database instance. This application embodiment does not specifically limit the content of the database processing request. After receiving a database processing request, the executing entity can obtain the cluster resource identifier carried in the request to determine the resources of the corresponding database cluster that needs to be processed. It can also obtain at least one distributed node corresponding to the resources of the database cluster that needs to be processed; the distributed node can be, for example, a MySQL node.

[0130] Step S202: Obtain the node status identifier of at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier.

[0131] The node lifecycle stages include: cluster status analysis, node addition, node update, node deletion, and role switching.

[0132] Step S203: Obtain the corresponding expected node status identifier based on the node lifecycle stage.

[0133] Each node lifecycle stage has a corresponding expected node state (e.g., what state a distributed node will be added to, updated to, deleted to, or switched to), and the expected node state has a corresponding expected node state identifier.

[0134] Step S204: Determine the number of cluster replicas corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the expected node status identifier.

[0135] The executing entity determines the expected node status identifier from the node status identifiers corresponding to at least one distributed node identified based on the cluster resource identifier. The expected node status identifier can be FHYQ. "Expected" means that the specifications of the distributed node (e.g., CPU, memory, storage) meet preset values.

[0136] Step S205: Determine the number of distributed nodes to be created based on the number of cluster replicas and the number of distributed nodes corresponding to the expected node status identifiers.

[0137] For example, the system determines whether the number of "expected" StatefulSets is greater than or equal to the number of cluster replicas (i.e., the node count threshold), and then determines the number of distributed nodes to be created based on this result. If the number of "expected" StatefulSets is greater than or equal to the number of cluster replicas (i.e., the node count threshold), then the number of distributed nodes to be created is the same as the number of cluster replicas. If the number of "expected" StatefulSets is less than the number of cluster replicas (i.e., the node count threshold), then the number of distributed nodes to be created is the same as the number of "expected" StatefulSets.

[0138] Step S206: Determine the resources to be scheduled based on the number of distributed nodes to be created and the expected node status identifiers.

[0139] For example, after performing cluster state analysis, the executing entity can determine whether the number of "expected" Statefulsets is greater than or equal to the number of cluster replicas (i.e., the node number threshold) based on the output of the "Cluster State Analysis" module. Based on the determination result, a corresponding number of Statefulsets are created. That is, if the number of "expected" Statefulsets is greater than or equal to the number of cluster replicas, then a number of Statefulsets equal to the number of cluster replicas are created. If the number of "expected" Statefulsets is less than the number of cluster replicas, then a number of Statefulsets equal to the number of "expected" Statefulsets are created.

[0140] After determining the number of distributed nodes that need to be created (i.e., the number of distributed nodes to be created), the executing entity can more accurately determine the resources that need to be scheduled (i.e., the resources to be scheduled) based on the number of distributed nodes that need to be created and the expected node state identifiers corresponding to the states that need to be achieved.

[0141] Step S207: Execute the process of scheduling the resources to be scheduled, receive the returned scheduling result information, and then update the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier.

[0142] This application embodiment breaks down various configuration change-related operations into different lifecycle stages, determines the corresponding node lifecycle stage based on the node status identifier, determines the resources to be scheduled based on the node status identifier and the expected node status identifier, and then performs the conversion of the node status identifier to the expected node status identifier. It has reentrancy capability, can guarantee the atomicity of configuration change operations, has simple coding implementation, and reduces the probability of introducing program errors.

[0143] Figure 3This is a schematic diagram illustrating an application scenario of the database processing method provided in one embodiment of this application. The database processing method of this embodiment can be applied to database configuration scenarios based on a Kubernetes custom controller. In this embodiment, Label: A tag is an identifier used to classify resources. A resource tag is essentially key-value data. Tags are identifiable attributes on a specified object, and these attributes have specific meaning only to the user. Name, Namespace: Name is the identifier of a resource object in the Kubernetes cluster. Their scope is usually within the same namespace. The names of resources and objects of the same type must be unique. Cluster Gateway (APIServer): The gateway interface of the Kubernetes cluster, responsible for parsing client requests. ETCD (Cluster State Store): Stores persistent Kubernetes data and provides a watch mechanism for listening to and pushing changes. In the Kubernetes cluster system, when a key-value pair in ETCD changes, it notifies the API Server, which then outputs the change to the client via the watchAPI.

[0144] like Figure 3As shown, the executing entity adds a new resource type, "MySQL Cluster Type," to the Kubernetes API service through a Kubernetes Custom Resource (CRD). The Kubernetes API creates a new RESTful resource path based on the description of the CRD. Users can manipulate the "MySQL Cluster" resource via HTTP requests. The "MySQL Cluster" resource is stored in the ETCD cluster as a YAML file. User API operations are creation, modification, and deletion operations on the specified YAML file. A custom MySQL controller listens for events (creation, modification, deletion) on the "MySQL Cluster" resource through the Kubernetes API service. The MySQL controller can then receive all events related to the "MySQL Cluster" resource. The "MySQL Cluster" resource records the user's expected MySQL status (number of replicas, CPU, memory, disk type and size, parameters, etc.) and the current MySQL status (MySQL node role: master or slave, whether the cluster is in read-only state, etc.). In the YAML file, `apiVersion` indicates the version of the Kubernetes resource; `kind` indicates that the Kubernetes resource is a MySQL cluster type resource, i.e., a MySQL cluster resource; `metadata` contains the resource's metadata, such as the resource name, the namespace it resides in, and the tags it contains; `spec` contains the detailed settings of the resource: `mysqlVersion` indicates the MySQL version of the database cluster (5.6, 5.7, 8.0, etc.), `replicas` indicates the number of nodes in the cluster (2 nodes indicate one master and one slave), `cpu` indicates the CPU configuration of the nodes, `memory` indicates the memory configuration of the nodes, `storageSize` indicates the storage space size of the nodes, `storageClass` indicates the storage disk type of the nodes (local storage, shared storage, etc.), `mysqlConf` indicates the cluster parameter configuration, and `options` contains other attributes of the MySQL cluster resource. A MySQL cluster resource contains multiple StatefulSets. The naming convention for a StatefulSet is: MySQL cluster name + 5-character random string. The cluster to which a StatefulSet belongs is determined by its labels (i.e., node identifiers). The YAML file contains information about the StatefulSet: apiVersion and kind are the resource version and type; metadata includes the creation timestamp, finalizers, tag set, name, namespace, and MySQL cluster resource information; spec contains other related attributes of the StatefulSet.

[0145] When the system malfunctions, such as when the Kubernetes cluster lacks resources: After the "Add Node" module creates a new Statefulset resource, the newly created Statefulset resource will remain in the "creating" state because Kubernetes cannot schedule the resource. Once the system administrators add enough resources, Kubernetes will schedule and create the Statefulset normally. When the Statefulset becomes "ready", it will still trigger MySQL cluster events. The MySQL controller listens for the events, and each MySQL controller module processes them in turn, finally adjusting the entire cluster state to the expected state.

[0146] The MySQL controller detects the current state of the MySQL cluster and compares it with the expected state of the MySQL cluster recorded in ETCD. It then continuously executes relevant operations to more quickly and accurately transform the actual state of the MySQL cluster to the user's expected state. ETCD, a component of the Kubernetes cluster, is a three-replica, strongly consistent key-value store used to store various stateful data within the Kubernetes cluster.

[0147] This application embodiment can realize the resource topology of a MySQL cluster: multiple MySQL nodes are composed of multiple Statefulsets, each Statefulset has 1 replica, representing a master or slave database; three independent modules, "node addition", "node update", and "node deletion", manage the lifecycle of nodes, making the controller reentrant; an independent "high availability failover" module allows for customization of the triggering timing of "failover operations"; and custom finalizers are used to implement data security-related functions of the MySQL cluster, such as delayed deletion and backup before deletion.

[0148] Figure 6 This is a schematic diagram of the main units of a database processing apparatus according to an embodiment of this application. Figure 6 As shown, the database processing device 600 includes a receiving unit 601, a node lifecycle stage determination unit 602, a resource to be scheduled determination unit 603, and an execution unit 604.

[0149] The receiving unit 601 is configured to receive database processing requests, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier.

[0150] The node lifecycle stage determination unit 602 is configured to obtain the node status identifier of at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier.

[0151] The resource to be scheduled determination unit 603 is configured to obtain the corresponding expected node status identifier according to the node life cycle stage, and then determine the resource to be scheduled based on the node status identifier and the expected node status identifier.

[0152] Execution unit 604 is configured to execute processes that schedule resources to be scheduled, receive the returned scheduling result information, and then update the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier.

[0153] In some embodiments, the database processing apparatus further includes Figure 6 The request generation unit (not shown) is configured to: send the cluster resource processing event to the event queue in response to listening to the cluster resource processing event; and generate the corresponding database processing request in response to retrieving the cluster resource processing event from the event queue.

[0154] In some embodiments, the execution unit 604 is further configured to: in response to the failure of resource scheduling corresponding to the scheduling result information, add the cluster resource processing event back to the event queue.

[0155] In some embodiments, the execution unit 604 is further configured to: in response to the scheduling result information corresponding to the successful scheduling of resources and the addition of nodes corresponding to the node lifecycle stage, create a new distributed node based on the successfully scheduled resources, and update the node status identifier of the new distributed node to the ready identifier.

[0156] In some embodiments, the resource to be scheduled determination unit 603 is further configured to: determine the number of cluster replicas corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the expected node status identifier; determine the number of distributed nodes to be created based on the number of cluster replicas and the number of distributed nodes corresponding to the expected node status identifier; and determine the resource to be scheduled based on the number of distributed nodes to be created and the expected node status identifier.

[0157] In some embodiments, the resource to be scheduled determination unit 603 is further configured to: determine the threshold number of nodes in the creation state corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the node in the creation state identifier; determine the number of distributed nodes to be created based on the node number threshold and the number of distributed nodes corresponding to the node in the creation state identifier; and determine the resource to be scheduled based on the number of distributed nodes to be created and the expected node state identifier.

[0158] In some embodiments, the database processing apparatus further includes Figure 6The node update unit (not shown) is configured to: in response to the node update corresponding to the lifecycle stage, traverse the existing distributed nodes in the cluster corresponding to the cluster resource identifier and determine the distributed nodes in the marked-for-deletion state; determine the number of distributed nodes in the ready state in the cluster; and when the distributed nodes in the marked-for-deletion state are not the master database in the cluster and the number of distributed nodes in the ready state in the cluster reaches a preset threshold, remove the deletion protection identifier of the distributed nodes in the marked-for-deletion state.

[0159] In some embodiments, the data processing apparatus further includes Figure 6 The node deletion unit (not shown) is configured to: in response to node deletion corresponding to a node lifecycle stage, determine the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas in the cluster corresponding to the cluster resource identifier; determine the nodes to be identified for deletion and the number of nodes to be identified for deletion based on the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas; and perform deletion processing on the corresponding distributed nodes based on the nodes to be identified for deletion and the number of nodes to be identified for deletion.

[0160] In some embodiments, the data processing apparatus further includes Figure 6 The role switching unit (not shown) is configured to: determine the corresponding triggering strategy in response to the role switching corresponding to the node lifecycle stage; execute the process of switching the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state in response to the immediate switch corresponding to the triggering strategy; and trigger the process of switching the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state in response to the operation and maintenance window switching corresponding to the triggering strategy and the current time being within the cluster operation and maintenance window period.

[0161] It should be noted that the database processing method and database processing device in this application are related in terms of specific implementation content, so repeated content will not be described again.

[0162] Figure 7 An exemplary system architecture 700 is shown that can be applied to the database processing method or database processing apparatus of the embodiments of this application.

[0163] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing communication links between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0164] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0165] Terminal devices 701, 702, and 703 can be various electronic devices with data processing screens and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0166] Server 705 can be a server providing various services, such as a backend management server supporting data processing requests submitted by users using terminal devices 701, 702, and 703 (for example only). The backend management server can receive database processing requests, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier; obtain the node status identifier of at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier; obtain the corresponding expected node status identifier based on the node lifecycle stage, and then determine the resource to be scheduled based on the node status identifier and the expected node status identifier; execute the process of scheduling the resource to be scheduled, and receive the returned scheduling result information, and then update the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier. After splitting various configuration change-related operations into different lifecycle stages, determining the corresponding node lifecycle stage based on the node status identifier, determining the resource to be scheduled based on the node status identifier and the expected node status identifier, and then performing the conversion from the node status identifier to the expected node status identifier, it has reentrancy capability, ensures the atomicity of configuration change operations, simplifies coding implementation, and reduces the probability of introducing program errors.

[0167] It should be noted that the database processing method provided in this application embodiment is generally executed by server 705, and correspondingly, the database processing device is generally located in server 705.

[0168] It should be understood that Figure 7 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0169] The following is for reference. Figure 8 It shows a schematic diagram of the structure of a computer system 800 suitable for implementing a terminal device according to the embodiments of this application. Figure 8 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0170] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 802 or programs loaded from storage section 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the computer system 800. The CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0171] The following components are connected to I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 810 as needed so that computer programs read from it can be installed into storage section 808 as needed.

[0172] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by central processing unit (CPU) 801, it performs the functions defined above in the system of this application.

[0173] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0174] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0175] The units described in the embodiments of this application can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor can be described as including a receiving unit, a node lifecycle stage determination unit, a resource to be scheduled determination unit, and an execution unit. The names of these units do not necessarily limit the specific unit itself.

[0176] In another aspect, this application also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs. When the one or more programs are executed by the device, the device receives a database processing request, obtains a corresponding cluster resource identifier, determines at least one corresponding distributed node based on the cluster resource identifier, obtains a node status identifier of at least one distributed node, and then determines the corresponding node lifecycle stage based on the node status identifier; obtains a corresponding expected node status identifier based on the node lifecycle stage, and then determines the resource to be scheduled based on the node status identifier and the expected node status identifier; executes a process to schedule the resource to be scheduled, receives returned scheduling result information, and then updates the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier.

[0177] According to the technical solution of the embodiments of this application, after splitting the various configuration change-related operations into different life cycle stages, the corresponding node life cycle stage is determined according to the node status identifier, the resource to be scheduled is determined based on the node status identifier and the expected node status identifier, and then the node status identifier is converted to the expected node status identifier. It has reentrancy capability, can guarantee the atomicity of configuration change operations, has simple coding implementation, and reduces the probability of introducing program errors.

[0178] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A database processing method, characterized in that, include: Receive a database processing request, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier; Obtain the node status identifier of the at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier; The expected node status identifier is obtained according to the node lifecycle stage, and then the resource to be scheduled is determined based on the node status identifier and the expected node status identifier. The process of scheduling the resource to be scheduled is executed, and the returned scheduling result information is received. Then, the node status identifier is updated based on the scheduling result information until the node status identifier is updated to the expected node status identifier. Before determining the resource to be scheduled based on the node status identifier and the expected node status identifier, the method further includes: in response to the node update corresponding to the lifecycle stage, traversing the existing distributed nodes in the cluster corresponding to the cluster resource identifier, and determining the distributed nodes in the marked deletion state; The number of distributed nodes in the ready state in the cluster is determined. In response to the distributed node in the marked-for-deletion state not being the master database in the cluster and the number of distributed nodes in the ready state in the cluster reaching a preset threshold, the deletion protection flag of the distributed node in the marked-for-deletion state is removed.

2. The method according to claim 1, characterized in that, Prior to receiving the database processing request, the method further includes: In response to the detection of a cluster resource processing event, the cluster resource processing event is sent to the event queue; In response to retrieving the cluster resource processing event from the event queue, a corresponding database processing request is generated.

3. The method according to claim 2, characterized in that, Before updating the node status identifier based on the scheduling result information, the method further includes: In response to the failure of resource scheduling corresponding to the scheduling result information, the cluster resource processing event is added back to the event queue.

4. The method according to claim 1, characterized in that, Updating the node status identifier based on the scheduling result information includes: In response to the successful scheduling of the resource corresponding to the scheduling result information and the addition of the node corresponding to the node lifecycle stage, a new distributed node is created based on the successfully scheduled resource, and the node status identifier of the new distributed node is updated to the ready identifier.

5. The method according to claim 1, characterized in that, The step of determining the resource to be scheduled based on the node status identifier and the expected node status identifier includes: Determine the number of cluster replicas corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the expected node status identifier; Based on the number of cluster replicas and the number of distributed nodes corresponding to the expected node status identifiers, the number of distributed nodes to be created is determined. Based on the number of distributed nodes to be created and the expected node status identifier, the resources to be scheduled are determined.

6. The method according to claim 1, characterized in that, The step of determining the resource to be scheduled based on the node status identifier and the expected node status identifier includes: Determine the threshold number of nodes in the creation state corresponding to the cluster resource identifier and the number of distributed nodes corresponding to the node creation state identifier; The number of distributed nodes to be created is determined based on the node number threshold and the number of distributed nodes corresponding to the node status identifiers in the corresponding creation process. Based on the number of distributed nodes to be created and the expected node status identifier, the resources to be scheduled are determined.

7. The method according to claim 1, characterized in that, Before determining the resource to be scheduled based on the node status identifier and the expected node status identifier, the method further includes: In response to the deletion of a node corresponding to the node lifecycle stage, determine the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas corresponding to the cluster resource identifier in the cluster. Based on the number of distributed nodes in the ready state, the number of distributed nodes in the expected state, and the number of cluster replicas, determine the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion. The deletion process is performed on the corresponding distributed nodes based on the nodes that need to be identified for deletion and the number of nodes that need to be identified for deletion.

8. The method according to claim 1, characterized in that, Before determining the resource to be scheduled based on the node status identifier and the expected node status identifier, the method further includes: In response to the role switching corresponding to the node lifecycle stage, determine the corresponding triggering strategy; In response to the immediate switch corresponding to the triggering policy, the process of switching the master database of the cluster corresponding to the cluster resource identifier to the distributed node in the ready state is executed; In response to the switching of the operation and maintenance window corresponding to the triggering strategy and the current time being within the cluster operation and maintenance window period, a process is triggered to switch the master database of the cluster corresponding to the cluster resource identifier to a distributed node in a ready state.

9. A database processing apparatus, characterized in that, include: The receiving unit is configured to receive database processing requests, obtain the corresponding cluster resource identifier, and determine at least one corresponding distributed node based on the cluster resource identifier. The node lifecycle stage determination unit is configured to obtain the node status identifier of the at least one distributed node, and then determine the corresponding node lifecycle stage based on the node status identifier. The resource to be scheduled determination unit is configured to obtain the corresponding expected node status identifier according to the node lifecycle stage, and then determine the resource to be scheduled based on the node status identifier and the expected node status identifier. The execution unit is configured to execute a process that schedules the resource to be scheduled, and receive the returned scheduling result information, and then update the node status identifier based on the scheduling result information until the node status identifier is updated to the expected node status identifier. The database processing device further includes a node update unit, configured to: in response to a node update corresponding to a lifecycle stage, traverse the existing distributed nodes in the cluster corresponding to the cluster resource identifier and determine the distributed nodes in the marked-for-deletion state; determine the number of distributed nodes in the ready state in the cluster; and when a distributed node in the marked-for-deletion state is not the master database in the cluster and the number of distributed nodes in the ready state in the cluster reaches a preset threshold, remove the deletion protection identifier of the distributed node in the marked-for-deletion state.

10. A database processing electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-8.

11. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-8.

Images