A guided database cluster deployment method, device and medium

Abstract

The embodiment of the application discloses a guide type database cluster deployment method, equipment and medium, belongs to the technical field of database, solves the problems of low operation efficiency and easy deployment failure caused by human negligence in the script-based database cluster deployment mode. Including, obtaining the cluster basic configuration information input by the user through the graphical guide interface; adding the to-be-deployed nodes, setting the deployment parameters for each to-be-deployed node, and generating a to-be-deployed node list; pre-detecting the deployment environment of each to-be-deployed node, and when the pre-detection result meets the preset detection condition, starting the deployment task on each to-be-deployed node in parallel, and executing component installation on each to-be-deployed node according to the preset component dependency order; during the deployment process, obtaining the deployment progress information and the deployment log, and performing a rollback operation on the node with deployment failure based on the deployment progress information and the deployment log, so as to reset the state of the node with deployment failure.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a wizard-guided database cluster deployment method, device, and medium. Background Technology

[0002] In today's enterprise-level IT architecture, the database, as the core data carrier, is crucial for ensuring business continuity due to its high availability. High-availability database clusters typically employ an architecture based on master-slave replication and distributed coordination. By combining components such as database software, distributed coordination services, high-availability proxies, and virtual IP management, they achieve automatic failover and zero data loss.

[0003] Currently, the deployment of such clusters primarily relies on automated operation and maintenance scripts. Specifically, operations and maintenance personnel need to pre-write complex deployment scripts, which encapsulate the entire process of instructions, including server environment preparation, installation steps for various components, parameter configuration, and service startup. During deployment, for each server node, the script executes these instructions sequentially to complete the software installation and configuration of a single node. Finally, the nodes are manually connected or linked together using additional scripts to form a working database cluster.

[0004] However, this existing script-based deployment method typically employs a simple serial loop. The deployment process involves independent steps such as node configuration, parameter setting, and environment checks, requiring operations personnel to repeatedly switch between multiple servers and input commands. This discrete operation is not only inefficient but also highly susceptible to human error, leading to command input errors or omissions, which in turn cause deployment failures. Summary of the Invention

[0005] This application provides a wizard-driven database cluster deployment method, device, and medium to solve the following technical problem: In the prior art, script-based deployment methods are inefficient and prone to errors in command input or omissions in steps due to human negligence, which can lead to deployment failure.

[0006] The embodiments of this application adopt the following technical solutions:

[0007] This application provides a wizard-driven database cluster deployment method. It includes: obtaining basic cluster configuration information input by the user through a graphical wizard interface; adding nodes to be deployed in the graphical wizard interface and setting deployment parameters for each node to be deployed, generating a list of nodes to be deployed; performing a deployment environment pre-detection on each node to be deployed based on the basic cluster configuration information and the list of nodes to be deployed, and opening the formal deployment entry when the pre-detection results of all nodes to be deployed meet preset detection conditions; responding to deployment instructions, starting deployment tasks in parallel on each node to be deployed, and performing component installation on each node to be deployed according to a preset component dependency order, so as to add each node to be deployed to the database cluster defined by the basic cluster configuration information; during deployment, obtaining deployment progress information and deployment logs, and performing rollback operations on nodes that failed to deploy based on the deployment progress information and deployment logs, so as to reset the state of the nodes that failed to deploy.

[0008] In one implementation of this application, the user-inputted cluster basic configuration information is obtained through a graphical wizard interface. Specifically, this includes: displaying multiple configuration pages to the user in a preset order within the graphical wizard interface, guiding the user through the input and configuration of basic cluster information in a step-by-step manner; wherein the multiple configuration pages include at least one of a cluster definition page, a distributed coordination service association page, and a cluster security management page; the cluster definition page guides the user to at least input a cluster name, select a database type and compatibility mode, and set a database name; the distributed coordination service association page guides the user to select the desired distributed coordination service (DCS) cluster from the configured service list; and the cluster security management page guides the user to set one of administrator account information, security officer account information, and auditor account information for the database cluster.

[0009] In one implementation of this application, a new node to be deployed is added in the graphical wizard interface, and deployment parameters are set for each node to be deployed to generate a list of nodes to be deployed. Specifically, this includes: in the node management page corresponding to the graphical wizard interface, responding to the new node command, adding one or more nodes to be deployed to the current database cluster; in the node management page, for each newly added node to be deployed, filling in the node deployment parameters selected by the user; wherein, the deployment parameters include at least one of the following: node name, associated server, database port, proxy port, and software installation path; and, when the node to be deployed is in an unmanaged state, adding the node to be deployed to the management system through a pop-up window for adding a server; and forming a node list set by the added nodes to be deployed and their corresponding parameter information, and displaying the node list set in the graphical wizard interface.

[0010] In one implementation of this application, based on the cluster's basic configuration information and a list of nodes to be deployed, a deployment environment pre-detection is performed on each node to be deployed. When the pre-detection results of all nodes to be deployed meet preset detection conditions, the formal deployment entry is opened. Specifically, this includes: responding to a pre-detection command triggered by the user in the graphical wizard interface, performing deployment environment detection on each node in the list of nodes to be deployed; wherein the deployment environment detection includes at least detecting the remote connection status of each node's server, detecting the occupancy of database ports and proxy ports, detecting whether the software installation directory meets preset conditions, and detecting the planned virtual IP addresses. One of the corresponding conflict scenarios; if any node to be deployed fails to detect, based on the modified value of the configuration parameters entered by the user through the modification entry, a special verification operation corresponding to the modified value is initiated to the node to be deployed; for the case of detection failure caused by cluster-level configuration conflict, if the corresponding modified values ​​of all relevant nodes have passed the special verification operation, then a mimicry deployment consensus verification is performed to generate a coordinated and consistent cluster-level repair plan for the temporary modifications of each node that have passed the verification; based on the cluster-level repair plan, pre-detection is performed again, and when the pre-detection results of all nodes to be deployed meet the preset detection conditions, the formal deployment entry is opened.

[0011] In one implementation of this application, for cases where detection fails due to cluster-level configuration conflicts, if the corresponding modified values ​​of all relevant nodes have passed a special verification operation, then a mimicry deployment consensus verification is performed to generate a coordinated cluster-level repair scheme for the temporary modifications of each node that have passed verification. Specifically, this includes: for any node that fails detection due to a cluster-level configuration conflict, after its modified configuration parameter values ​​pass a special verification operation, a corresponding mimicry configuration identifier is generated and injected into the isolated configuration environment of that node. Simultaneously, the node's status is marked as mimicry ready in the graphical wizard interface; when all nodes that fail detection due to the same cluster-level configuration conflict are... When marked as mimicry-ready, a mimicry cluster handshake is triggered across all relevant nodes. Based on the mimicry cluster handshake, a logical cluster channel is established according to the mimicry configuration identifiers of each node. This channel is used to verify the feasibility of achieving state consistency after nodes adopt modified values. If the mimicry cluster handshake is successful, a cluster-level repair snapshot is generated. This snapshot is a declarative topology description file, including the logical relationships between all relevant nodes and their verified mimicry configuration identifiers. After obtaining user confirmation of the cluster-level repair snapshot, the formal configurations of the relevant nodes are updated based on the snapshot to form a consistent cluster-level repair solution.

[0012] In one implementation of this application, deployment tasks are started in parallel on each node to be deployed, and component installation is performed on each node according to a preset component dependency order. Specifically, this includes: starting component installation tasks in parallel on multiple nodes to be deployed based on the preset component dependency order; monitoring the installation status and environmental indicators of each node to be deployed in real time, and generating a diagnostic script based on the anomaly information when any node to be deployed experiences an installation anomaly; sending the diagnostic script to other nodes to be deployed to detect similar problems within the cluster; and after the component installation is completed, determining the primary and backup role relationships within the cluster through the deployed distributed coordination service, establishing a data replication link, and completing the logical assembly of the cluster.

[0013] In one implementation of this application, after the component installation task is started in parallel on multiple nodes to be deployed, the method further includes: monitoring the interaction characteristics of coordination signaling between the nodes to be deployed; wherein the interaction characteristics include at least one of the following: periodic jitter pattern of signaling interaction, causal delay distribution of cross-node signaling, and coupling strength between control plane and data plane signaling; comparing the interaction characteristics with a preset cluster risk pattern library, and predicting the future operational risks of the cluster based on the comparison results; reconstructing the logical architecture of the cluster based on the prediction results, so as to continue the installation process of subsequent components according to the reconstructed logical architecture; wherein the reconstruction of the logical architecture of the cluster includes at least dynamically adjusting the preset roles of nodes in the cluster and replanning the logical connections and data synchronization relationships between nodes; after the logical architecture reconstruction is completed, the installation process of subsequent components continues to be executed according to the reconstructed logical architecture.

[0014] In one implementation of this application, a rollback operation is performed on nodes that have failed to deploy, based on deployment progress information and deployment logs, to reset the state of the nodes that have failed to deploy. Specifically, this includes: when any node is detected to have failed to deploy, a rollback cleanup process is triggered for that node; wherein the rollback cleanup process includes at least one of the following: stopping the database and high availability services that have been started on the node, deleting the created software installation directory and data directory, and removing the related services registered in the system; if the rollback cleanup process fails to completely clean up the environment, a manual cleanup command is generated based on the detection results of the residual environment of the node; wherein the manual cleanup command is executed directly by copying; after the rollback cleanup is completed, the state of the node is reset in the graphical wizard interface.

[0015] This application provides a wizard-driven database cluster deployment device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: obtain cluster basic configuration information input by the user through a graphical wizard interface; add nodes to be deployed in the graphical wizard interface, set deployment parameters for each node to be deployed, and generate a list of nodes to be deployed; perform deployment environment pre-detection on each node to be deployed based on the cluster basic configuration information and the list of nodes to be deployed, and open the formal deployment entry when the pre-detection results of all nodes to be deployed meet the preset detection conditions; respond to the deployment command, start deployment tasks in parallel on each node to be deployed, and perform component installation on each node to be deployed according to a preset component dependency order, so as to add each node to be deployed to the database cluster defined by the cluster basic configuration information; during the deployment process, obtain deployment progress information and deployment logs, and perform rollback operations on nodes that fail to be deployed based on the deployment progress information and deployment logs, so as to reset the state of the nodes that fail to be deployed.

[0016] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: obtain cluster basic configuration information input by the user through a graphical wizard interface; add nodes to be deployed in the graphical wizard interface and set deployment parameters for each node, generating a list of nodes to be deployed; perform deployment environment pre-detection on each node based on the cluster basic configuration information and the list of nodes to be deployed, and open the formal deployment entry when the pre-detection results of all nodes meet preset detection conditions; respond to the deployment instructions, start deployment tasks in parallel on each node to be deployed, and perform component installation on each node according to a preset component dependency order, thereby adding each node to be deployed to the database cluster defined by the cluster basic configuration information; during deployment, obtain deployment progress information and deployment logs, and perform rollback operations on nodes that fail to deploy based on the deployment progress information and deployment logs, thereby resetting the state of the nodes that failed to deploy.

[0017] The above-mentioned technical solutions adopted in this application embodiment can achieve the following beneficial effects: By constructing a graphical wizard interface, configuration information is centrally managed, avoiding maintenance difficulties and error-prone problems caused by parameters being scattered in multiple scripts. By adding nodes and generating a list of nodes to be deployed in the graphical wizard interface, users can complete the management and parameter settings of all servers in one interface, without having to switch repeatedly between multiple servers or terminals, thus improving the deployment efficiency of multi-node clusters. This application embodiment avoids starting deployment with hidden problems through deployment environment pre-detection, reducing deployment failures caused by environmental issues and lowering the complexity and cost of later troubleshooting and rollback. In the event of deployment failure, this application embodiment triggers automatic cleanup operations to quickly restore the environment of the failed node. If automatic cleanup fails, manual cleanup commands guide users to thoroughly resolve the problem, reducing the difficulty and cost of redeployment. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application 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 only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0019] Figure 1 A flowchart of a wizard-driven database cluster deployment method provided in this application embodiment;

[0020] Figure 2 This is a schematic diagram of the structure of a wizard-driven database cluster deployment device provided in an embodiment of this application. Detailed Implementation

[0021] This application provides a wizard-guided database cluster deployment method, device, and medium.

[0022] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0023] Figure 1 A flowchart of a wizard-driven database cluster deployment method provided in this application embodiment is shown below. Figure 1 As shown, the wizard-driven database cluster deployment method includes the following steps:

[0024] Step 101: Obtain the cluster basic configuration information input by the user through the graphical wizard interface.

[0025] In one implementation of this application, a graphical wizard interface displays multiple configuration pages to the user in a preset order, guiding the user through the input and configuration of basic cluster information in a step-by-step manner. These configuration pages include at least one of the following: a cluster definition page, a distributed coordination service association page, and a cluster security management page. The cluster definition page guides the user to at least input a cluster name, select a database type and compatibility mode, and set a database name. The distributed coordination service association page guides the user to select the desired distributed coordination service (DCS) cluster from the configured service list. The cluster security management page guides the user to set one of the following for the database cluster: administrator account information, security officer account information, and auditor account information.

[0026] Specifically, this application provides a graphical, step-by-step interface that guides users through cluster configuration, node management, and parameter settings. The page is presented in a vertical or columnar layout. When a user initiates the cluster creation process, the front-end application first instantiates a wizard state manager. This manager defines and maintains the state of the entire wizard process, including the current step index, form data for each step, step validity status, and dependencies between steps. Simultaneously, a page router is initialized, with routing rules corresponding one-to-one with the wizard steps. The page router is bound to the state manager to ensure that browser forward / backward operations synchronously update the wizard state and interface. On the cluster definition page, users enter the cluster name, select the database type, compatibility mode, and set the database name. On the distributed coordination service association page, users select the pre-built DCS cluster. On the cluster security management page, users set the database administrator, security officer, and auditor accounts and their corresponding passwords. Common parameters, such as the time synchronization service address, also need to be configured. Through the graphical wizard interface, users are guided to complete the configuration of basic cluster information. All configured parameters are centrally stored for easy reuse later.

[0027] When the user completes all configuration pages and clicks "Complete Wizard," the front-end application extracts all step data from the wizard's state manager and encapsulates it into a cluster deployment descriptor conforming to a predefined JSON Schema (a specification or metadata based on JSON format used to define and validate JSON data structures and content). After encapsulation, the front-end submits this descriptor to the back-end service via a pre-defined interface. Upon receiving the descriptor, the back-end service first performs integrity and business logic verification. If the verification passes, it persists the descriptor to the database and encrypts and stores the relevant configuration fragments. Simultaneously, it generates a globally unique deployment task ID for this cluster specification and associates it with the cluster specification ID. Finally, the deployment task ID is returned to the front-end, and the front-end interface immediately redirects to the deployment task monitoring panel, guiding the user to the next stage of the pre-detection and deployment process.

[0028] Step 102: In the graphical wizard interface, add new nodes to be deployed and set deployment parameters for each node to be deployed to generate a list of nodes to be deployed.

[0029] In one implementation of this application, on the node management page corresponding to the graphical wizard interface, a new node command is invoked to add one or more nodes to be deployed in the current database cluster. On the node management page, for each newly added node to be deployed, the user-selected node deployment parameters are populated; these parameters include at least one of the following: node name, associated server, database port, proxy port, and software installation path. Furthermore, when a node to be deployed is not yet under management, it is added to the management system via a "Add Server" pop-up window. The added nodes to be deployed and their corresponding parameter information form a node list set, which is then displayed in the graphical wizard interface.

[0030] Specifically, in this embodiment, in response to the "Add Node" command, a new node to be deployed is added, and information such as the node name, associated server, database port, HAC port, and software installation path is filled in. If the server to be deployed is not yet under management, it can be added directly through the "Add Server" pop-up window without exiting the deployment process. Information on all nodes to be deployed is displayed centrally in a list format, supporting editing and deletion of node information at any time. The list of undeployed nodes centrally displays information on all nodes to be deployed and provides editing and deletion entry points.

[0031] Furthermore, when a user enters the node management page during the wizard process, the front-end application loads the page components. After the components are initialized, a request to retrieve data is sent to the backend service. The request includes a unique identifier for the currently configured database cluster, used to call the corresponding interface provided by the backend. Upon receiving the request, the backend service queries the database and returns a list of all nodes to be deployed that have been added to this cluster, along with their detailed information. Simultaneously, to support the associated server option, the front-end also requests a list of all managed servers available for deployment in the system. The backend returns a list containing information such as server identifier, hostname, network address, operating system type, and remote connection status. After receiving these two sets of data, the front-end stores them in local state variables: one for storing the node list and the other for storing the available server resource pool. Based on this data, it begins rendering the node list display area and the "Add Node" button on the page.

[0032] When a user clicks the "Add Node" button on the node management page, the front-end click event handler is triggered. This handler first creates a new node data object template in memory. The template's structure matches the backend interface definition, including attributes such as node name, associated server, database port, proxy port, and software installation path, with their initial values ​​set to default values. Next, a pop-up window is dynamically generated on the current page; this pop-up is an edit form for filling in detailed node information. Each input control in the form is bound to the node data object template. Simultaneously, the dropdown selection box for the associated server loads and displays a list of available servers obtained from the backend. This embodiment ensures interface independence and data isolation for adding nodes. In the node edit form, the user needs to fill in various deployment parameters sequentially. Each input box is equipped with real-time validation to ensure data accuracy and validity. For example, for adding a node to be deployed, after clicking "Test and Add," the backend attempts to connect to the server to verify its reachability and permissions. Once verification is successful, the node is officially added to the management system, and the server dropdown list in the outer form is refreshed, automatically selecting the newly added server.

[0033] Furthermore, after the user completes the form and clicks the "Confirm" button, the front-end performs final form data validation. If validation passes, the entered node information is submitted to the back-end service via the back-end interface. Upon receiving the data, the back-end service persists this node information to a dedicated database table within a database transaction and establishes its association with the current cluster and the selected server. After successful operation, the back-end returns a response containing complete node information. Upon receiving the successful response, the front-end first closes the node editing overlay window; then, it adds the returned new node object to its local node list array; next, based on the updated node list array, it re-renders the node list display area on the page; finally, it synchronizes the updated global node list state to the state manager of the entire wizard process, ensuring that subsequent pre-detection, deployment, and other stages receive the latest configuration. At this point, the newly added node has become part of the current cluster's list of nodes to be deployed.

[0034] In this embodiment, the progress of each deployment step, the real-time status of nodes, and operation logs are displayed in real time. The node status is clearly marked with "success / failure / in progress", so the deployment status can be grasped without having to search through the logs.

[0035] Step 103: Based on the cluster's basic configuration information and the list of nodes to be deployed, perform a pre-deployment environment test on each node to be deployed, and open the formal deployment portal when the pre-deployment results of all nodes to be deployed meet the preset test conditions.

[0036] In one implementation of this application, in response to a pre-detection command triggered by the user in the graphical wizard interface, deployment environment detection is performed on each node in the list of nodes to be deployed. This deployment environment detection includes at least one of the following: detecting the remote connection status of each node's server, detecting the occupancy of database and proxy ports, detecting whether the software installation directory meets preset conditions, and detecting conflicts corresponding to the planned virtual IP addresses. If any node fails the detection, a special verification operation corresponding to the modified value is initiated for that node based on the modified value entered by the user through the modification entry. For detection failures caused by cluster-level configuration conflicts, if the corresponding modified values ​​of all relevant nodes pass the special verification operation, a mimicry deployment consensus verification is performed to generate a consistent cluster-level repair plan based on the verified temporary modifications of each node. Pre-detection is then performed again based on the cluster-level repair plan, and the formal deployment entry is opened when the pre-detection results of all nodes meet the preset detection conditions.

[0037] Specifically, after the user clicks the pre-detection button, the system automatically performs checks on all nodes to be deployed. The checks include: whether the server remote connection is normal, whether the port is not in use, whether the installation directory is empty, whether the operating system is compatible, and whether there are virtual IP conflicts. Logs are output in real time during the detection process, and the detection result for each node is marked as success / failure. The system will only open the deployment button when all nodes have a successful pre-detection status, avoiding deployment with pre-existing environmental issues.

[0038] Furthermore, after aggregating the pre-detection results from all nodes, the backend service returns them to the frontend interface in a structured data format. Upon receiving the results, the frontend renders them into a clear detection report. The report is typically displayed in tabular form, with each row corresponding to a detection item for a node, and its status marked with icons and colors. For any detection item marked as failed, a "modify" button is rendered at the end of its corresponding table row, serving as the entry point for user correction. When a user clicks the modify button for a failed item, a lightweight edit box pops up, pre-populated with the original failed configuration value and clearly displaying the specific reason for the detection failure, guiding the user to enter a new configuration value. After the user enters the new configuration value in the edit box and clicks "verify," the frontend sends the modified value, the corresponding node identifier, and the detection item type to a dedicated verification interface on the backend. The backend service creates a temporary verification task, which logs into the target node and performs a targeted, rapid detection for the single new value. For example, for a port, it checks if the new port is free; for a directory, it checks if the new path meets the conditions. Successful or failed verification results, along with detailed verification logs, are pushed out in real time and displayed near the user's clicked "Modify" button, clearly informing the user whether the modified value is valid. The system continuously analyzes and detects failure patterns in its background logic. When it identifies multiple node failures caused by configuration conflicts at the same cluster level, it records these related nodes. Subsequently, the user waits to complete the modifications to each of these related nodes and pass the specific verification.

[0039] The backend detects that all nodes that failed due to the same cluster-level conflict have had their corresponding new configuration values ​​verified, triggering the mimicry deployment consensus verification process. After the mimicry deployment consensus verification process starts, it first generates a mimicry configuration identifier for each verified new configuration value on each relevant node and marks it in an isolated configuration storage area of ​​the corresponding node via a secure channel, while simultaneously setting the node state to mimicry ready. Once all relevant nodes are ready, the coordinator triggers a mimicry cluster handshake covering all relevant nodes. This handshake is a lightweight distributed coordination process that sends control signaling to these nodes for consistency testing. The mimicry cluster handshake attempts to establish a logical cluster channel between all relevant nodes based on the mimicry configuration identifiers injected into each node's isolated environment. This channel is only used for exchanging test signaling. Through this channel, the coordinator sends instructions simulating real cluster formation to the nodes and listens to and analyzes the responses of each node. Its purpose is to verify whether these nodes, after adopting their new configuration values, can logically correctly follow the same protocol rules and ultimately achieve state consistency within the logical cluster channel. If verification is successful, the mimicry configuration identifiers of all nodes and their logical relationships are packaged to generate a cluster-level remediation snapshot. This snapshot is a declarative configuration file that precisely describes the final configuration that each node needs to adopt to resolve the conflict and their interrelationships. The generated cluster-level remediation snapshot is presented to the user for final confirmation.

[0040] After the user clicks "Apply this solution" on the interface, the backend service will synchronously update the official configuration parameters of all relevant nodes in the database based on the snapshot. After the update is complete, a new pre-detection process will be automatically triggered. When the backend confirms that the detection results of all nodes have passed, the official deployment entry will be opened.

[0041] Step 104: Respond to the deployment command, start the deployment task in parallel on each node to be deployed, and perform component installation on each node to be deployed according to the preset component dependency order, so as to add each node to be deployed to the database cluster defined by the cluster basic configuration information.

[0042] In one implementation of this application, component installation tasks are initiated in parallel on multiple nodes to be deployed, based on a preset component dependency order. The installation status and environmental metrics of each node to be deployed are monitored in real time. If any node experiences an installation anomaly, a diagnostic script is generated based on the anomaly information and sent to other nodes to be deployed, enabling the detection of similar issues across the cluster. After component installation is complete, the primary / standby role relationship within the cluster is determined through a deployed distributed coordination service, a data replication link is established, and the logical assembly of the cluster is completed.

[0043] Specifically, after the user clicks the deploy button, the system's deployment orchestrator begins working, automatically performing operations on each node according to the preset dependency order: first, the database is installed; then, the high-availability proxy component is installed; next, vip-manager (a virtual IP auto-migrating tool for high-availability database clusters) is installed; then, the cluster is initialized; and finally, the nodes are added to the cluster. Multiple nodes can be deployed simultaneously. Operation logs for each step are output in real time during the deployment process, facilitating troubleshooting. Successfully deployed nodes are automatically moved to the deployed node list; nodes that fail to deploy remain in the undeployed node list for later processing.

[0044] Furthermore, in the graphical wizard interface, after the user clicks the "Start Deployment" button, the system retrieves a list of nodes to be deployed in the current cluster and a predefined component installation process template from the database. This template is a directed acyclic graph, where nodes represent components and edges represent dependencies between components. Based on this template, an installation task sequence is generated for each node in the list. These tasks are then distributed to a group of deployment executors, which connect to their assigned nodes via remote protocols, enabling parallel startup of component installation tasks across multiple nodes. During installation task execution, each command or script executed by the deployment executor on the target node captures its standard output, standard error stream, and command return code in real time. This information, along with timestamps, node identifiers, and component names, is sent back to the backend monitoring center as a log stream. Simultaneously, the executor collects key environmental metrics of the nodes at preset frequencies, such as CPU utilization, memory usage, disk I / O, and network connection count. The monitoring center has a rule engine that determines an installation anomaly occurs when a command return code is non-zero, a specific keyword appears in the error log, or environmental metrics exceed a threshold. Once an anomaly is confirmed, a corresponding diagnostic script is matched and instantiated from a pre-defined script library based on the anomaly type. After generating the diagnostic script, the list of nodes to be deployed is retrieved to identify all other nodes in the "installing" state that have not yet completed the installation of the current abnormal component. The generated diagnostic script is dynamically inserted as a high-priority temporary task into the front of the task queue of these target nodes. Upon receiving this diagnostic task, the deployment executor on each node executes the diagnostic script on its local node. After execution, the diagnostic results are sent back. In this way, by utilizing the anomaly information discovered from one node, preventative detection is performed concurrently on all nodes in the cluster that may face similar risks, achieving the goal of learning from single-point failures and providing early warnings on a global scale.

[0045] After all component installation tasks on all nodes are successfully completed, the cluster enters the self-organization phase. High-availability proxies connect to the distributed coordination service cluster configured during the pre-detection phase. Each node's high-availability proxy competes with the coordination service for a distributed lock representing the leader. Once a node successfully acquires the lock, it creates a path representing the cluster in the coordination service, writes its connection information, identifies itself as the master node, and starts the main database service. Other nodes that fail to acquire the lock act as backup nodes, continuously listening to the master node's information in the coordination service. Once they acquire the information, backup nodes use native database tools to pull all data from the master node, initialize their local data directory, configure and start the streaming replication process, and establish a continuously synchronized data replication link pointing to the master node. When all backup nodes complete this process and register with the coordination service, the high-availability database cluster is logically assembled.

[0046] In one implementation of this application, after initiating component installation tasks in parallel on multiple nodes to be deployed, the method further includes: monitoring the interaction characteristics of coordination signaling between the nodes to be deployed, wherein the interaction characteristics include at least one of the following: periodic jitter pattern of signaling interaction, causal delay distribution of cross-node signaling, and coupling strength between control plane and data plane signaling. The interaction characteristics are compared with a preset cluster risk model library, and the operational risks that the cluster may encounter in the future are predicted based on the comparison results. Based on the prediction results, the logical architecture of the cluster is reconstructed, so that the subsequent component installation process can continue to be executed according to the reconstructed logical architecture; wherein, the reconstructing of the logical architecture of the cluster includes at least dynamically adjusting the preset roles of nodes in the cluster and replanning the logical connections and data synchronization relationships between nodes. After the logical architecture reconstructing is completed, the subsequent component installation process continues to be executed according to the reconstructed logical architecture.

[0047] Specifically, after the parallel installation task starts and key components such as the high-availability agent successfully start on each node, the coordination signaling that nodes inevitably exchange for self-organization is captured and parsed at the network layer or at the log interface layer of the agent component. This signaling includes, but is not limited to: registration heartbeats sent by nodes to the distributed coordination service, handshake messages between primary and backup nodes for establishing streaming replication, and control messages for synchronizing states between high-availability agents. For each type of signaling interaction, high-dimensional temporal characteristics are calculated and recorded, including: 1. Periodic jitter pattern: by analyzing the arrival time interval sequence of continuous heartbeat messages, its standard deviation and abnormal spikes are calculated to assess the stability of signaling transmission; 2. Causal delay distribution: the delay between causally related signaling pairs is tracked, and their distribution histograms are plotted to assess the determinism of network paths; 3. Coupling strength: the correlation between the active period of control plane signaling and the throughput of data plane signaling is analyzed to assess whether both are constrained by the same bottleneck resource. The extracted feature vectors are sent to the background risk analysis engine along with node identifiers and timestamps. The risk analysis engine rapidly matches and infers from the real-time input feature vectors against the rule base, outputting prediction results. The engine's output includes: risk type, risk level, associated nodes, and prediction basis. For nodes with unreliable leader risks: the preset role of the node in the cluster is dynamically adjusted through the configuration management interface. For example, it can be removed from the primary node candidate list and its role forcibly marked as a synchronous backup node. For node pairs with unstable synchronization link risks: the logical connections and data synchronization relationships between nodes are redesigned. For example, in the cluster configuration, the member list of synchronous replicas is modified, removing backup nodes with unstable risks from the primary node's synchronization list and changing them to asynchronous backup nodes. After the logical architecture refactoring plan is determined, the remaining installation and configuration processes continue according to the refactored logical architecture.

[0048] Step 105: During the deployment process, obtain deployment progress information and deployment logs. Based on the deployment progress information and deployment logs, perform rollback operations on nodes that failed to deploy in order to reset the status of the nodes that failed to deploy.

[0049] In one implementation of this application, when a deployment failure is detected on any node, a rollback cleanup process is triggered for that node. This rollback cleanup process includes at least one of the following: stopping the database and high-availability services already running on the node, deleting the created software installation directory and data directory, and removing related services registered in the system. If the rollback cleanup process fails to completely clean up the environment, a manual cleanup command is generated based on the detection results of the residual environment on the node. This manual cleanup command is executed directly by copying. After the rollback cleanup is completed, the node's state is reset in a graphical wizard interface.

[0050] Specifically, for nodes where deployment fails, the system automatically performs cleanup operations: stopping started services, deleting installed directories, cleaning up the database data directory, and removing related services registered in the system. If automatic cleanup fails, it generates manual cleanup instructions that can be directly copied and executed based on the actual residual state of the node, guiding the user to complete the cleanup. After cleanup, the node's pre-detection status is reset to undetected, and the user can re-execute pre-detection and deployment after modifying the node configuration. In other words, by determining whether the database service and high availability service on the current node are normal, when an abnormality is detected, corresponding high availability service cleanup instructions and database cleanup instructions are generated and executed by the user.

[0051] 1. High Availability Cleanup Command: Stops the high availability service, cleans up the high availability executable program and generated log files;

[0052] 2. Database cleanup command: Cleans up the database data directory, WAL log directory, passwordless files, and database executable programs;

[0053] 3. Clean up the information of registered nodes in the cluster.

[0054] Figure 2 This is a schematic diagram of a wizard-driven database cluster deployment device provided in an embodiment of this application. Figure 2 As shown, the wizard-driven database cluster deployment device 200 includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201. The memory 202 stores instructions executable by the at least one processor 201, which, when executed, enable the at least one processor 201 to: obtain cluster basic configuration information input by the user through a graphical wizard interface; add nodes to be deployed in the graphical wizard interface and set deployment parameters for each node, generating a list of nodes to be deployed; perform deployment environment pre-detection on each node based on the cluster basic configuration information and the list of nodes to be deployed, and open the formal deployment entry when the pre-detection results of all nodes meet the preset detection conditions; respond to deployment instructions, start deployment tasks in parallel on each node to be deployed, and perform component installation on each node according to a preset component dependency order, thereby adding each node to be deployed to the database cluster defined by the cluster basic configuration information; during deployment, obtain deployment progress information and deployment logs, and perform rollback operations on nodes that fail to deploy based on the deployment progress information and deployment logs, thereby resetting the state of the nodes that failed to deploy.

[0055] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: obtain cluster basic configuration information input by the user through a graphical wizard interface; add nodes to be deployed in the graphical wizard interface and set deployment parameters for each node, generating a list of nodes to be deployed; perform deployment environment pre-detection on each node based on the cluster basic configuration information and the list of nodes to be deployed, and open the formal deployment entry when the pre-detection results of all nodes meet preset detection conditions; respond to the deployment instructions, start deployment tasks in parallel on each node to be deployed, and perform component installation on each node according to a preset component dependency order, thereby adding each node to be deployed to the database cluster defined by the cluster basic configuration information; during deployment, obtain deployment progress information and deployment logs, and perform rollback operations on nodes that fail to deploy based on the deployment progress information and deployment logs, thereby resetting the state of the nodes that failed to deploy.

[0056] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0057] The above descriptions are merely embodiments of this application and are not intended to limit the scope of this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions in the embodiments of this application.

Claims

1. A wizard-driven database cluster deployment method, characterized in that, The method includes: Obtain basic cluster configuration information input by the user through a graphical wizard interface; In the graphical wizard interface, add a new node to be deployed, set deployment parameters for each node to be deployed, and generate a list of nodes to be deployed; Based on the cluster's basic configuration information and the list of nodes to be deployed, a deployment environment pre-detection is performed on each node. When the pre-detection results for all nodes meet preset detection conditions, the formal deployment entry is opened. Specifically, this includes responding to a pre-detection command triggered by the user in the graphical wizard interface, performing deployment environment detection on each node in the list of nodes to be deployed. The deployment environment detection includes at least detecting the remote connection status of each node's server, detecting the occupancy of database and proxy ports, detecting whether the software installation directory meets preset conditions, and detecting conflicts corresponding to the planned virtual IP addresses. In one of the following scenarios: if any of the nodes to be deployed fails to detect, a special verification operation corresponding to the modified value input by the user through the modification entry is initiated to the node to be deployed based on the modified value of the configuration parameters; for detection failures caused by cluster-level configuration conflicts, if the corresponding modified values ​​of all relevant nodes pass the special verification operation, a mimicry deployment consensus verification is performed to generate a consistent cluster-level repair plan based on the temporary modifications of each node that have passed the verification; pre-detection is performed again based on the cluster-level repair plan, and the formal deployment entry is opened when the pre-detection results of all nodes to be deployed meet the preset detection conditions; In response to the deployment command, the deployment task is started in parallel on each of the nodes to be deployed, and the components are installed on each node according to the preset component dependency order, so as to add each node to be deployed to the database cluster defined by the cluster basic configuration information. During deployment, deployment progress information and deployment logs are obtained. Based on the deployment progress information and deployment logs, rollback operations are performed on nodes that fail to deploy, so as to reset the state of the nodes that fail to deploy. The step of starting deployment tasks in parallel on each of the nodes to be deployed, and performing component installation on each node according to a preset component dependency order, specifically includes: Based on the preset component dependency order, component installation tasks are started in parallel on multiple nodes to be deployed. The installation status and environmental indicators of each node to be deployed are monitored in real time, and a diagnostic script is generated based on the abnormal information when any node to be deployed experiences an installation anomaly. The diagnostic script is sent to other nodes to be deployed to detect the same type of problem across the cluster. After the components are installed, the primary and backup roles within the cluster are determined through the deployed distributed coordination service, a data replication link is established, and the logical assembly of the cluster is completed. After starting the component installation task in parallel on multiple nodes to be deployed, the method further includes: The interaction characteristics of coordination signaling between nodes to be deployed are monitored; wherein the interaction characteristics include at least one of the following: periodic jitter pattern of signaling interaction, causal delay distribution of cross-node signaling, and coupling strength between control plane and data plane signaling. The interaction features are compared with a preset cluster risk pattern library, and the operational risks that the cluster may encounter in the future are predicted based on the comparison results. Based on the prediction results, the logical architecture of the cluster is reconstructed so that the installation process of subsequent components can continue to be executed according to the reconstructed logical architecture. The reconstructing of the logical architecture of the cluster includes at least dynamically adjusting the preset roles of nodes in the cluster and replanning the logical connections and data synchronization relationships between nodes.

2. The wizard-driven database cluster deployment method according to claim 1, characterized in that, The process of obtaining basic cluster configuration information input by the user through a graphical wizard interface specifically includes: In the graphical wizard interface, multiple configuration pages are displayed to the user in a preset order to guide the input and configuration of basic cluster information in a step-by-step manner; wherein, the multiple configuration pages include at least one of the following: cluster definition page, distributed coordination service association page, and cluster security management page; The cluster definition page is used to guide users to at least one of the following: enter the cluster name, select the database type and compatibility mode, and set the database name; The distributed coordination service association page is used to guide users to select the desired distributed coordination service DCS cluster from the configured service list; The cluster security management page is used to guide users to set one of the following for the database cluster: administrator account information, security officer account information, and auditor account information.

3. The wizard-guided database cluster deployment method according to claim 1, characterized in that, In the graphical wizard interface, adding nodes to be deployed and setting deployment parameters for each node to be deployed, and generating a list of nodes to be deployed, specifically includes: In the node management page corresponding to the graphical wizard interface, respond to the add node command to add one or more nodes to be deployed in the current database cluster; On the node management page, for each newly added node to be deployed, the node deployment parameters selected by the user are filled in; wherein, the deployment parameters include at least one of the following: node name, associated server, database port, proxy port, and software installation path; In addition, when the node to be deployed is in a state of not being included in management, the node to be deployed is added to the management system through a pop-up window for adding a new server; The added nodes to be deployed and their corresponding parameter information are combined to form a node list set, which is then displayed in the graphical wizard interface.

4. The wizard-guided database cluster deployment method according to claim 1, characterized in that, In the event of detection failure due to cluster-level configuration conflicts, if the corresponding modified values ​​of all relevant nodes have passed the special verification operation, then a mimicry deployment consensus verification is performed to generate a coordinated and consistent cluster-level repair solution based on the temporary modifications of each node that have passed the verification. Specifically, this includes: For any node that fails to detect due to cluster-level configuration conflict, after its modified configuration parameter value passes the special verification operation, a corresponding mimicry configuration identifier is generated and injected into the isolated configuration environment of the node. At the same time, the node's status is marked as mimicry ready in the graphical wizard interface. When all nodes that fail to detect due to the same cluster-level configuration conflict are marked as mimicry ready, a mimicry cluster handshake is triggered across all relevant nodes. Based on the mimicry cluster handshake, a logical cluster channel is established according to the mimicry configuration identifier of each node, so as to verify the feasibility of the nodes achieving state coordination consistency after adopting the modified value through the logical cluster channel. If the mimicry cluster handshake is successful, a cluster-level repair snapshot is generated; wherein, the cluster-level repair snapshot is a declarative topology description file, including the logical relationship between all relevant nodes and their verified mimicry configuration identifiers; After obtaining user confirmation of the cluster-level repair snapshot, the formal configuration of the relevant nodes is updated based on the cluster-level repair snapshot to form the coordinated and consistent cluster-level repair scheme.

5. The wizard-guided database cluster deployment method according to claim 1, characterized in that, The step of performing a rollback operation on nodes that failed to deploy based on the deployment progress information and deployment logs to reset the state of the nodes that failed to deploy specifically includes: When any node deployment failure is detected, a rollback and cleanup process for that node is triggered; wherein, the rollback and cleanup process includes at least one of the following: stopping the database and high availability services that have been started on the node, deleting the created software installation directory and data directory, and removing the related services registered in the system; If the rollback cleanup process fails to completely clean up the environment, a manual cleanup command is generated based on the detection results of the residual environment of the node; wherein, the manual cleanup command is executed directly by copying. After the rollback cleanup is complete, the state of the node is reset in the graphical wizard interface.

6. A wizard-guided database cluster deployment device, characterized in that, The device includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to perform the method described in any one of claims 1-5.

7. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are capable of performing the method described in any one of claims 1-5.

Images