Database node switching method, device and equipment based on hardware fault

Abstract

The invention provides a database node switching method, device and equipment based on hardware faults. Comprising the steps that node fault information of at least one node of a database is acquired, and the fault information of each node is used for indicating the hardware fault condition of the node; for each node, determining a fault type according to the node fault information of the node, and determining a fault processing instruction according to the fault type; and reporting the fault processing instruction to a database management platform. According to the technical scheme, the switching efficiency of the database fault nodes is improved, and the continuity of database services is ensured.

Description

Technical Field

[0001] The present application relates to the field of database processing technology, and in particular to a database node switching method, device and equipment based on hardware failure. Background Art

[0002] In modern information systems, databases are used as key infrastructure and are widely used for data storage and management of various business systems. To improve system stability and business continuity, databases are usually deployed using a distributed architecture. One of the common deployment modes is the master-slave architecture, where one node is the master node, responsible for processing write operations and key transactions, and the remaining nodes are slave nodes, used to share read operations and data redundancy.

[0003] In the prior art, when the physical machine where the primary node is located is unavailable due to hardware failure, the service can be transferred to the backup node through the primary-backup switching mechanism, and the backup node can be upgraded to the primary node to ensure business continuity and high availability.

[0004] However, the above master-slave node switching mechanism takes a long time, resulting in low switching efficiency of the database master-slave nodes. Summary of the invention

[0005] The present application provides a database node switching method, device and equipment based on hardware failure, which are used to solve the technical problem of long time consumption and low efficiency of database master and standby node switching caused by node hardware failure.

[0006] In a first aspect, the present application proposes a database node switching method based on hardware failure, which is applied to a fault management service platform, including:

[0007] Acquire node fault information of at least one node of the database, where the fault information of each node is used to indicate a hardware fault condition of the node;

[0008] For each node, determine the fault type according to the node fault information of each node, and determine a fault handling instruction according to the fault type, wherein the fault handling instruction is used to indicate the content that needs to be backed up when the node is switched;

[0009] The fault handling instruction is reported to the database management platform.

[0010] Further, the acquiring node failure information of at least one node of the database includes:

[0011] Each node corresponding to the database and hardware information of each node synchronized with the database management platform;

[0012] Collecting the operation status information of each node in real time;

[0013] Node fault information of the at least one node is acquired according to the operation status information of each node.

[0014] Further, determining a fault type according to the node fault information of each node, and determining a fault handling instruction according to the fault type, includes:

[0015] Classify the node fault information of the node to determine the fault type, where the fault type includes at least one of event, state, alarm or performance indicator information;

[0016] Determining fault severity information according to the node fault information and the fault type;

[0017] A fault handling instruction is determined according to the fault degree information.

[0018] Furthermore, the method further comprises:

[0019] If an auxiliary switching request sent by the database management platform is received, the database management platform is assisted to complete the node switching of the database according to the auxiliary switching request.

[0020] In a second aspect, the present application proposes a database node switching method based on hardware failure, which is applied to a database management platform, including:

[0021] Receiving a fault handling instruction of at least one node reported by a fault management service platform, wherein the fault handling instruction of each node is used to indicate content that needs to be backed up when the node is switched;

[0022] For each node, node switching and content backup are performed according to the fault handling instruction of the node.

[0023] Further, performing node switching and content backup according to the fault handling instruction of the node includes:

[0024] Determine a target node from backup nodes of the node in the database;

[0025] According to the fault handling instruction, the content that needs to be backed up in the node is backed up to the target node, and the target node is switched to serve as the working node.

[0026] Furthermore, the method further comprises:

[0027] If the node switching of the database is not completed, an auxiliary switching request is sent to the fault management service platform, so that the fault management service platform assists in completing the node switching.

[0028] In a third aspect, the present application proposes a database node switching device based on hardware failure, comprising:

[0029] A node fault information acquisition module, used to acquire node fault information of at least one node in the database, wherein the fault information of each node is used to indicate the hardware fault condition of the node;

[0030] A fault handling instruction determination module, used to determine the fault type of each node according to the node fault information of each node, and determine the fault handling instruction according to the fault type, wherein the fault handling instruction is used to indicate the content that needs to be backed up when the node is switched;

[0031] The fault handling instruction reporting module is used to report the fault handling instruction to the database management platform.

[0032] In a fourth aspect, the present application proposes a database node switching device based on hardware failure, comprising:

[0033] A fault handling instruction receiving module, used to receive a fault handling instruction of at least one node reported by the fault management service platform, wherein the fault handling instruction of each node is used to indicate the content that needs to be backed up when the node is switched;

[0034] The node switching module is used to perform node switching and content backup for each node according to the fault handling instruction of the node.

[0035] In a fifth aspect, the present application proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0036] The memory stores computer-executable instructions;

[0037] The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of the first aspect and the second aspect.

[0038] The database node switching method, device and equipment based on hardware failure provided by the present application obtain node failure information of at least one node of the database, and the failure information of each node is used to indicate the hardware failure condition of the node; for each node, the failure type is determined according to the node failure information of each node, and the failure handling instructions are determined according to the failure type, and the failure handling instructions are used to indicate the content that needs to be backed up when the node is switched; the method of reporting the failure handling instructions to the database management platform effectively improves the switching efficiency of the primary and standby nodes of the database. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] Figure 1 The overall architecture diagram of the database node switching method based on hardware failure provided by this application;

[0041] Figure 2 A flowchart of a first embodiment of a database node switching method based on hardware failure provided by the present application;

[0042] Figure 3 This is a flow chart of Embodiment 2 of the database node switching method based on hardware failure proposed in the present application;

[0043] Figure 4 This is a flow chart of Embodiment 3 of the database node switching method based on hardware failure proposed in this application;

[0044] Figure 5 This is a flow chart of Embodiment 4 of the database node switching method based on hardware failure proposed in the present application;

[0045] Figure 6 A flowchart of a fifth embodiment of a database node switching method based on hardware failure provided by the present application;

[0046] Figure 7 A flowchart of the fault information processing for database node switching based on hardware failure provided by this application;

[0047] Figure 8 A schematic diagram of the structure of a database node switching device based on hardware failure provided by the present application;

[0048] Fig. 9 A schematic diagram of the structure of another switching device for database nodes based on hardware failure provided by the present application;

[0049] Fig.10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0050] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0051] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0052] The existing database is deployed in a one-master-two-slave architecture. It is a common operation and maintenance scenario that the failure of the physical machine where the database is located causes the database master node to switch. The current fault repair link is that the host failure causes the operating system failure, the operating system failure causes the database failure, and the database detection mechanism detects the database failure and switches the master node, and finally restores the database service. However, the database switching mechanism in the existing technology needs to wait for the hardware failure to be transmitted to the database layer before triggering the database switch. If the failure causes the database process or thread to fail, the database switch will take longer, which will greatly reduce the efficiency of the database switch.

[0053] In response to the above technical problems, the inventors have come up with the idea of ​​actively triggering the master-slave switching of the database from the early stage of the hardware failure, that is, establishing a fault management service platform, converting the hardware failure into resource alarm information and pushing it to the database management platform, so that the database can complete the master-slave switching in advance, thereby avoiding the impact of process and thread deadlocks on database switching and greatly improving the switching efficiency of database nodes.

[0054] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0055] Figure 1 This is the overall architecture diagram of the database node switching method based on hardware failure provided by this application. Figure 1 As shown, it includes a fault management service platform 101 and a database management platform 102, wherein the fault management service platform 101 includes a fault collection service 1011, a fault management service 1012 and a fault handling service 1013, and the database management platform 102 includes an automatic switching module 1021, an auxiliary switching module 1022 and an alarm notification module 1023.

[0056] Specifically, the information of each node of the database is registered in the fault management service 1012. The fault management service 1012 will also register the hardware information of each node of the database in the fault collection service 1011. The fault collection service 1011 subscribes to the corresponding node in the resource cloud according to the registration information, and records the subscription information in the database to complete the node registration process. After that, when a node fails, the resource cloud will report the fault. The fault collection service 1011 will convert the fault information into events, states, alarms, performance indicators and other elements, and then continue to report it to the fault management service 1012 and record it in the database. The fault management service 1012 performs fault impact assessment and fault event decision-making. After that, the fault event decision is sent to the fault handling service, which is coordinated and dispatched by the fault handling service 1013. Finally, the fault handling service 1013 sends the handling instruction to the database management platform 102 for execution.

[0057] For the database management platform 102, after receiving the disposal instruction sent by the fault management service platform 1011, it will perform corresponding processing according to the message type of the disposal instruction. That is, when the database management platform 102 receives the message of database instance switching, it will send the switching command to the database instance to switch the database. When the database management platform 102 receives the auxiliary switching message, it will force the main node where the database is located to shut down. When receiving the alarm notification message, the alarm information will be sent to the alarm notification module 1023.

[0058] In addition, the technical solution of this application is based on the existing cloud platform architecture. By building a new fault service platform 101, the hardware fault is converted into a cloud resource (English: Infrastructure as a Service, abbreviated as: IAAS) alarm, which will enter the fault management service platform 101 by region. The fault management service platform 101 processes and filters the alarm information and pushes it to the database management platform 102. The database management platform 102 processes the fault handling information into two information flows, one is sent to the alarm platform to realize the alarm notification, and the other is sent to the database to realize the master-slave node switching. Figure 1 As shown in , the IASS cloud is equipped with Kunpeng servers and all-flash flash storage (English: OceanStor Dorado, referred to as: Dorado). Hardware faults of Kunpeng servers and Dorado storage are discovered through hardware alarms and deep inspections, and hardware faults are converted into IAAS resource faults and reported to the IAAS cloud platform. The IAAS cloud platform enriches the hardware fault information, adds IAAS resource identifiers of hardware resources, fault event names and other resources, and forwards the enriched fault information to fault management service platforms 101 in different regions.

[0059] Figure 2The flowchart of the first embodiment of the database node switching method based on hardware failure provided by the present application is as follows. Figure 2 As shown, including:

[0060] S201. Obtain node failure information of at least one node of a database.

[0061] The database node refers to the server unit responsible for storing, processing and managing data in the database, and may be composed of multiple nodes in a distributed database. In the embodiment of the present application, it can be considered that there are three nodes in the database, including one master node and two backup nodes. Node hardware fault information is used to indicate the hardware fault information of the node, wherein the hardware part includes storage devices, processors, memory and network interfaces, etc.

[0062] In this step, the fault management service platform can obtain the database node hardware fault information from the resource cloud, where the resource cloud is used to manage the database node hardware resources. For example, for the resource cloud, hardware faults of Kunpeng servers and Dorado storage can be discovered through hardware alarms and deep inspections, and the hardware faults can be converted into cloud resource faults and reported to the resource cloud platform. The resource cloud platform enriches the hardware fault information, adds resources such as resource identifiers and fault event names of hardware resources, and forwards the enriched fault information to fault management service platforms in different regions. After receiving the node fault information, the fault management service platform can collect and organize it centrally for subsequent node fault processing.

[0063] S202 . For each node, determine a fault type according to the node fault information of each node, and determine a fault handling instruction according to the fault type.

[0064] In this step, after receiving the node fault information of each node in the database, the fault management service platform will clean the node hardware fault information, that is, analyze the node fault information, remove redundant or unwanted information, and extract key information, such as the fault type, the node where the fault occurred, and the severity of the fault.

[0065] The fault management service platform will then map the hardware failure to the physical device and the logical instance. For example, there may be a dependency between the hardware failure and the master node in the database instance. The fault management service platform will manage the fault information of the physical device and the status of the database combing to ensure that the availability of the database instance is taken into account when handling the failure.

[0066] Then, all node hardware fault information is classified and sorted to determine the node fault type. Finally, according to the type of node fault, the predefined processing rules are applied to each type of fault and fault processing instructions are issued.

[0067] S203: Report the fault handling instruction to the database management platform.

[0068] The database management platform is a tool or system for centralized management of the database, responsible for monitoring, managing and optimizing the operation of the database, including fault handling, resource allocation and other tasks. Node switching is simply switching the database workload from the failed node to the standby node or healthy node when a database node hardware failure occurs, to ensure the continuous availability of the database.

[0069] S204: Receive a fault handling instruction of at least one node reported by the fault management service platform.

[0070] Among them, the fault handling instructions of each node are used to indicate the content that needs to be backed up when the node is switched. For the database management platform, according to the instructions reported in the fault management service platform, the relationship between the hardware information of the faulty node and other nodes can be confirmed, such as which is the master node, what is the corresponding storage content on the master node, which is the standby node, and which node has a hardware failure, whether there is a standby node for node switching, whether the hardware regulations affect the normal operation or service of the database, and check the health of all nodes to ensure that the standby node has been synchronized and has the ability to take over the master node.

[0071] S205: For each node, perform node switching and content backup according to the node's fault handling instruction.

[0072] Before switching database nodes, you usually need to ensure data integrity. That is, if the primary node is still available, you can perform a backup first. If the primary node is completely unavailable, you may need to restore data from the most recent backup or node.

[0073] Specifically, if the failed node is the master node, the standby node needs to be promoted to the master node. This process usually includes executing a role switch in the database management platform to ensure that the new master node after the switch can take over all the content of the original master node, including read and write requests, and then switch the new working node to the working node of the database to ensure that the database service is not interrupted. After the master-slave node switch is completed, it is necessary to ensure that the data synchronization between the standby node (that is, the new master node) and other slave nodes is normal, that is, check the health status of the database after the switch to ensure that no data is lost and the synchronization process is completed. After the switch is completed, the hardware of the failed node can also be repaired. After the repair is completed, the repaired node can be redeployed to the database to make it have the function of a standby node.

[0074] The database node switching method based on hardware failure provided in the embodiment of the present application detects the hardware failure of the database node through the fault management service platform and issues processing instructions to clarify the fault type, node status and processing requirements. Then, the database management platform obtains the fault node information according to these instructions, confirms whether there is a spare node available for switching, and performs necessary operations, such as promoting the spare node to the main node, synchronizing data and ensuring the stable operation of the database. Finally, the fault management service platform and the database management platform jointly monitor the status of the node after switching, ensure that the database service is not interrupted and resume normal operation, and improve the switching efficiency of the database node.

[0075] Figure 3 This is a flow chart of Embodiment 2 of the database node switching method based on hardware failure proposed in this application. Figure 3 As shown, in Figure 2 Based on the embodiment, obtaining node failure information of at least one node of the database includes:

[0076] S301, each node and hardware information of each node corresponding to the database synchronized with the database management platform.

[0077] In an embodiment of the present application, the database management platform needs to collect the hardware information of all nodes, including the hardware configuration (such as memory, disk, network equipment, etc.) and running status of the nodes, and register and synchronize each node to the fault management service platform. After receiving the node registration synchronization information, the fault management service platform will synchronize and update the hardware information of each node. This step ensures that the fault management service platform has complete and up-to-date node hardware information for subsequent fault monitoring and processing. Then, the fault management service platform will further transmit or register the hardware information to the fault collection service, where the fault collection service is responsible for collecting and analyzing the running status of each node, and through the connection with the fault management service in the fault management service platform, ensure that all hardware information can be fed back to the fault management service platform in a timely manner to ensure a timely response to hardware failures. Once the node is successfully registered, the fault collection service will subscribe to the corresponding node in the resource cloud according to the registered hardware information, ensuring that the fault management service platform can monitor each database node in the cloud in real time and obtain its running status in a timely manner. Finally, the subscribed node information will be recorded in the database, which provides a basis for subsequent fault processing and ensures that the fault management service platform can accurately track the status of each node and related hardware data.

[0078] S302: Collect the operation status information of each node in real time.

[0079] In this step, the database management monitors the operating status of each database node through real-time monitoring and collection systems, including the node's memory usage, network connection status, database instance load, query response time, etc. This information is continuously collected through real-time data streams and transmitted to the fault management service platform to ensure that the fault management service platform obtains the latest node operation data.

[0080] S303: Obtain node fault information of at least one node according to the operation status information of each node.

[0081] In this step, the fault management service platform determines whether there is a hardware fault based on the collected operating status information of each node through analysis algorithms or threshold monitoring. For example, abnormal use of hardware nodes (such as overload, frequent errors, etc.), network delays or communication failures between nodes, signs of hardware failures (such as disk failures, device offline, etc.). Once a potential fault is identified, the fault management platform will generate an alarm or fault handling instruction and feed it back to the database management platform to start the corresponding troubleshooting and node switching process.

[0082] The database node switching method based on hardware failure proposed in the embodiment of the present application can ensure that the fault management platform can obtain the hardware information and operating status of each node in the database in real time, identify hardware failures through comparative analysis and trigger the fault handling mechanism in time, thereby achieving database high availability and fault recovery.

[0083] Figure 4 This is a flow chart of Embodiment 3 of the database node switching method based on hardware failure proposed in this application. Figure 4 As shown, in Figure 2 Based on the embodiment, the fault type is determined according to the node fault information of each node, and the fault handling instruction is determined according to the fault type, including:

[0084] S401. Classify the node fault information of the node and determine the fault type.

[0085] In this step, the fault management service in the fault management service platform will classify the fault information of each database node according to the different types of faults. The specific classification includes at least one of events, states, alarms and performance indicator information. Among them, events refer to the specific occurrence of hardware faults, such as a hard disk failure or memory abnormality in a node; states refer to the current state of the node, including whether it is running normally, whether there are abnormalities, etc.; alarms refer to the early warnings and warnings of faults by the fault management service platform, which may be because a node has an abnormality but may not have failed, and are early risk warnings; performance indicators refer to measurement data related to hardware performance, such as memory usage, disk input and output performance, etc. If these performance indicators exceed the preset threshold, it may indicate a potential hardware failure.

[0086] By classifying these hardware fault information, the fault handling service in the fault management service platform can adopt different processing strategies according to different types of data. For example, event information may require an immediate response, while alarm information may only be a trigger condition for monitoring.

[0087] S402: Determine fault severity information according to node fault information and fault type.

[0088] Based on the classified information, the fault management service platform needs to evaluate each type of information to determine the severity of the fault. For example, for event information, if a serious hardware fault occurs (such as hard disk damage, node downtime, etc.), the severity of the fault may be evaluated as high; for status information, if the node is in an abnormal state (such as excessive load, long-term non-response, etc.), the fault management service platform needs to evaluate the degree of the fault based on the health of the node; for alarm information, the alarm itself may indicate potential risks, and the level of the alarm will be considered during the evaluation. Low-level alarms may only require further monitoring, while high-level alarms may require immediate processing; for performance indicator information, if certain performance indicators exceed the set threshold, this may indicate that the hardware has a potential failure risk, and the fault management service platform will evaluate the severity of the fault based on these indicators. Finally, through comprehensive evaluation, the fault management service platform will derive the overall fault severity information based on different information categories, including mild faults (such as performance degradation, warning-level alarms, etc.), moderate faults (such as abnormal node status, performance indicators reaching critical values, etc.), and severe faults (such as node downtime, hardware failure, etc.).

[0089] S403: Determine a fault handling instruction according to the fault severity information.

[0090] In this step, the fault management service platform will generate corresponding fault handling instructions based on the assessed fault severity. For example, for minor faults, it may only be necessary to generate monitoring reminders or adjust the load, or mark the problem as a situation that requires observation, without taking immediate repair measures; for moderate faults, it may be necessary to partially repair the affected nodes, restart, optimize resource allocation, or notify operation and maintenance personnel for further inspection; for severe faults, emergency measures need to be taken immediately, which may include migrating data, starting backup nodes, etc., and may even require stopping services to prevent larger-scale faults. In some cases, the fault management service platform may automatically generate and execute processing instructions according to preset rules (such as automatically restarting nodes, switching to backup nodes, etc.), or it may notify operation and maintenance personnel to intervene manually.

[0091] The database node switching method based on hardware failure proposed in the embodiment of the present application ensures that the fault management service platform can effectively classify and process the hardware failures of the database nodes, and formulate corresponding fault handling plans according to the actual fault conditions, by classifying, evaluating and processing the hardware failure information.

[0092] Figure 5 This is a flow chart of Embodiment 4 of the database node switching method based on hardware failure proposed in this application. Figure 5 As shown, in Figure 2 Based on the embodiment, node switching and content backup are performed according to the node fault handling instruction, including:

[0093] S501: Determine a target node from backup nodes of nodes in a database.

[0094] In this step, it is necessary to evaluate the status of each node based on the hardware failure information of the node, so as to determine the relationship between the primary node and the backup node. Specifically, determine the failure information of each node in the database, including the failure type, failure degree (such as memory failure, disk failure, etc.) and the current status of the node (failure, recovery, normal). For example, if the disk of a node fails and cannot be recovered, the node may be marked as "failure". Then analyze the role of each node. For the primary node, it is usually the core node of the database, responsible for data reading and writing operations. If the primary node fails, it must be quickly switched to the target node. By replacing the primary node with the target node, the database service can be ensured to be uninterrupted; for the target node, it is the backup node of the database, responsible for disaster recovery and load balancing. When the primary node fails, the target node automatically takes over the responsibilities of the primary node. If the primary node fails and there is no suitable target node to take over, it may be necessary to select other healthy nodes as new target nodes.

[0095] Determine the failed node. Based on the severity of the hardware failure, first determine which nodes are in a "failed" state. For example, if the hard disk of a node fails and cannot be repaired, the node can be determined to be a failed node. Evaluate which nodes are still in a "normal" or "recovering" state and can be used as master nodes or backup nodes. Then, determine the relationship between the master node and the backup node. If the master node fails, you need to select one of the other healthy backup nodes as the new master node, that is, the target node. At this time, the target node will assume the responsibility of the master node when the master node fails. Therefore, the status of the target node needs to be checked to see if it is healthy and whether it can be promoted to a new master node.

[0096] In addition, the fault level needs to be determined. According to the level of the hardware fault, it is determined whether there is an emergency switching requirement. If the fault is a serious fault (such as hard disk damage), it is necessary to switch immediately. If it is a minor fault (such as excessive load), it may not be necessary to switch immediately.

[0097] S502: According to the fault handling instruction, the content that needs to be backed up in the node is backed up to the target node, and the target node is switched to serve as the working node.

[0098] After determining which nodes are the target nodes, the node switching is performed. Specifically, (1) confirm the target node. If the existing master node fails and the backup node is available, the backup node is used as the target node to be promoted to the new master node. Before switching, it is necessary to ensure that the data of the target node has been fully synchronized to the master node, otherwise there may be a risk of data loss or inconsistency after the switch. If there is no target node, it is necessary to select a healthy backup node as the new target node and synchronize the data. (2) Perform node switching. First, switch the master node and promote the target node to the new master node. The target node will take over all read and write operations and start processing newly written data. Then, the backup node, according to the load balancing requirements, designates the new healthy node as the new backup node, and the new backup node will start to replicate the new master node data. (3) After database synchronization and switching, it is necessary to ensure that the database between the new target node and the new backup node is synchronized. If the data of the backup node has not been fully synchronized with the new target node, there will be a risk of data loss during the switching process. Therefore, you need to ensure that data synchronization is complete before switching. If there is no real-time data synchronization mechanism (such as log-based replication or incremental synchronization), you need to manually synchronize data before switching, or temporarily suspend write operations until synchronization is complete.

[0099] Another point to note is that you also need to update the configuration of the database cluster to ensure that the new primary and standby node roles are recognized and applied; at the same time, configure the load balancer or proxy to ensure that external requests can be correctly routed to the new primary node.

[0100] After the node switch is completed, the health status of the new primary node and the standby node needs to be monitored. If a problem occurs with the new primary node, the database management platform can automatically roll back to the previous primary node or select another standby node.

[0101] The embodiment of the present application provides a database node switching method based on hardware failure, which analyzes the hardware status through fault information to determine which nodes have failed and which nodes can act as master nodes and backup nodes; then completes the switching of the master node to the backup node, including updating the database role, ensuring data synchronization, configuring load balancing and monitoring the system, ensuring that when hardware failure occurs, the database management platform automatically or manually completes the node switching, thereby ensuring the high availability and stability of the database service.

[0102] Figure 6 The flowchart of the fifth embodiment of the database node switching method based on hardware failure provided by this application is as follows. Figure 6 As shown, in Figure 2 Based on the embodiment, the method further includes:

[0103] S601: If the node switching of the database is not completed, an auxiliary switching request is sent to the fault management service platform, so that the fault management service platform assists in completing the node switching.

[0104] For the database management platform, if the severity of the fault is found to exceed the processing capacity of the database management platform during node switching, or the node switching fails for some reason (such as synchronization problems, configuration errors, etc.), a request will be sent to the fault management service platform to seek external help to complete the switch.

[0105] Specifically, the database management platform sends a request to the fault management service platform, indicating that the node switch cannot be completed and external support is needed. The request information may include the current faulty node information, such as which nodes are faulty and whether they are primary nodes or backup nodes; it may also include the reason for the switch failure, such as why the database management platform cannot complete the switch (for example, data synchronization delay, inability to select a healthy node, etc.).

[0106] In addition to requesting a switch, the database management platform also needs to provide necessary logs, error information, or configurations to help the fault management service platform quickly analyze the cause of the fault and take correct measures.

[0107] S602: If an auxiliary switching request sent by the database management platform is received, the database management platform is assisted to complete the node switching of the database according to the auxiliary switching request.

[0108] For the fault service management platform, after receiving the auxiliary switching request from the database management platform, it first parses the request content to understand the nature and cause of the fault. Then, based on the information in the request, it generates specific fault handling instructions, such as reselecting a new master node or backup node: if the node selection fails or the current node cannot take over the responsibilities of the master node, it may instruct the database management platform to select other backup nodes; or instruct the database management platform to perform necessary data synchronization operations to ensure data consistency; or if the database management platform fails to correctly identify healthy nodes, the fault management service platform may provide configuration repair instructions; it can also enable a backup fault handling mechanism. If the regular node switching cannot be completed, other disaster recovery mechanisms (such as data recovery, cold backup recovery, etc.) may be enabled. Finally, a new fault handling instruction is sent to the database management platform to ensure that the node switching can proceed smoothly.

[0109] After receiving the fault handling instructions sent by the fault management service platform, the database management platform will retry to complete the node switching according to the instructions of the fault management service platform. For example, when executing the node switching operation, the database management platform will select the node according to the new instructions. If the fault management service platform instructs to select a new primary node or backup node, the database management platform will perform the corresponding operation according to the instructions.

[0110] Specifically, if the instruction includes a data synchronization step, the database management platform needs to ensure that data synchronization between the new master node and the standby node is completed to avoid data loss. If the instruction is to update the configuration, then according to the instruction of the fault management service platform, it may be necessary to update the configuration of the database cluster, such as adjusting the master-slave relationship, updating the load balancing strategy, etc. After completing the node switching operation, the database management platform will perform a health check on the new master node and standby node to ensure that the database system can operate normally after the switch. If the switch is successful, the database management platform will record the operation log and report the success information to the fault management service platform. After the node switch is completed and the database is confirmed to be stable, the database management platform resumes normal operation and continues to handle daily database management tasks.

[0111] The database node switching method based on hardware failure proposed in the embodiment of the present application, when the database management platform cannot complete the node switching, it will send a request to the fault management service platform to request help. After receiving the request, the fault management service platform generates and sends a new fault handling instruction so that the database management platform can perform the correct switching operation. After receiving the instruction from the fault management service platform, the database management platform re-performs the node switching operation and ensures that the switching is successful. This process ensures that the database can receive timely support and recovery when a failure occurs, not only relying on the internal mechanism of the database management platform, but also completing more complex fault handling work with the assistance of the fault management service platform, thereby improving the fault tolerance and availability of the database.

[0112] Figure 7 This is a flowchart of the fault information processing of database node switching based on hardware failure provided by this application. Figure 7 As shown in the figure, the processing of fault information focuses on the fault management service platform, which is as follows:

[0113] After receiving the fault information, the fault management service platform first cleans the information by mapping the physical device and logical instance information to ensure that the fault information is accurate and consistent, and then transfers the cleaned information to the fault information center.

[0114] The fault information center matches the fault code and decides the corresponding action based on the preset fault decision library. There are three types of fault decisions: (1) Automatic switching of the database instance. When the decision is automatic switching, the fault information center will send the instruction to the fault information transmission module, which will directly issue the master-slave switching command to the fault instance. (2) Assisted switching by the management and control platform is required. If the automatic switching fails or is not applicable, the fault information center will initiate an assisted switching of the management and control platform and record the decision scenario for subsequent optimization. (3) No switching is required, only a fault notification is sent. If the fault situation does not require switching, the fault information center will only send an alarm notification to the relevant platform.

[0115] In addition, if the master-slave switch of the database instance fails, the failure information will be combined with the previous switch command to form new fault information, which will flow back to the information receiving module, be cleaned again, and reach the fault information center again. The fault information center will then initiate an auxiliary switch request to the management and control platform and record the scenario in the fault decision library.

[0116] In the case of a need for assisted switching by the control platform, the fault information center sends the command to the auxiliary action module of the control platform, which will perform a secondary check on the instance information to ensure the feasibility of the fault environment. After the check is completed, the control platform will perform the assisted switching operation. Regardless of the decision type, an alarm notification will be sent to the relevant platform after the switch is completed to ensure that the operation and maintenance personnel are aware of the fault handling results in a timely manner.

[0117] The database node switching method based on hardware failure provided in the embodiment of the present application regularly analyzes the data in the fault decision library through the fault information center, and optimizes based on the frequency and effect of fault processing. For scenarios where auxiliary switching is often required, the decision type may be changed from "automatic switching" to "auxiliary switching", thereby improving the switching efficiency of the database node.

[0118] Figure 8 This is a schematic diagram of the structure of the database node switching device based on hardware failure provided by this application. Figure 8As shown, the switching device 80 for database nodes based on hardware failure includes a node failure information acquisition module 801, a failure processing instruction determination module 802 and a failure processing instruction reporting module 803, wherein:

[0119] The node fault information acquisition module 801 is used to acquire node fault information of at least one node in the database. The fault information of each node is used to indicate the hardware fault condition of the node.

[0120] The fault handling instruction determination module 802 is used to determine the fault type for each node according to the node fault information of each node, and determine the fault handling instruction according to the fault type. The fault handling instruction is used to indicate the content that needs to be backed up when the node is switched.

[0121] The fault handling instruction reporting module 803 is used to report the fault handling instruction to the database management platform.

[0122] Furthermore, the node fault information acquisition module 801 is also specifically used for:

[0123] The database corresponding to each node and the hardware information of each node synchronized with the database management platform;

[0124] Collect the operation status information of each node in real time;

[0125] Node fault information of at least one node is obtained according to the operation status information of each node.

[0126] Furthermore, the fault handling instruction determination module 802 is further specifically configured to:

[0127] Classify the node fault information of the node to determine the fault type, where the fault type includes at least one of event, state, alarm or performance indicator information;

[0128] Determine the fault severity information based on the node fault information and fault type;

[0129] Determine the fault handling instructions based on the fault severity information.

[0130] Furthermore, the switching device 80 for database nodes based on hardware failure can also be used for:

[0131] If an auxiliary switching request sent by the database management platform is received, the database management platform is assisted to complete the node switching of the database according to the auxiliary switching request.

[0132] Fig. 9 This is a schematic diagram of the structure of another switching device for database nodes based on hardware failure provided by the present application. Fig. 9As shown, the switching device 90 for database nodes based on hardware failure includes a fault processing instruction receiving module 901 and a node switching module 902, wherein:

[0133] A fault handling instruction receiving module 901 is used to receive a fault handling instruction of at least one node reported by the fault management service platform, where the fault handling instruction of each node is used to indicate the content that needs to be backed up when the node is switched;

[0134] The node switching module 902 is used to perform node switching and content backup for each node according to the node fault handling instruction.

[0135] Furthermore, the node switching module 902 is also specifically used for:

[0136] Determine the target node from the backup nodes of the nodes in the database;

[0137] According to the fault handling instructions, the content that needs to be backed up in the node is backed up to the target node, and the target node is switched to serve as the working node.

[0138] Furthermore, the switching device 90 for database nodes based on hardware failure is also specifically used for:

[0139] If the node switching of the database is not completed, an auxiliary switching request is sent to the fault management service platform so that the fault management service platform assists in completing the node switching.

[0140] Fig.10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig.10 As shown, the electronic device 100 includes:

[0141] The electronic device 100 may include a processor 1001 with one or more processing cores, a memory 1002 with one or more computer-readable storage media, a communication component 1003 and other components. The processor 1001, the memory 1002 and the communication component 1003 are connected via a bus 1004.

[0142] In the specific implementation process, at least one processor 1001 executes the computer execution instructions stored in the memory 1002, so that at least one processor 1001 executes the above-mentioned abnormal number tracing method based on big data.

[0143] The specific implementation process of the processor 1001 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0144] In the above Fig.10In the illustrated embodiment, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0145] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.

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

[0147] The specific implementation of the above operations can be found in the previous embodiments, which will not be described in detail here.

[0148] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0149] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0150] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A database node switching method based on hardware failure, characterized in that: Applied to the fault management service platform, including: Acquire node fault information of at least one node of the database, where the fault information of each node is used to indicate a hardware fault condition of the node; For each node, determine the fault type according to the node fault information of each node, and determine a fault handling instruction according to the fault type, wherein the fault handling instruction is used to indicate the content that needs to be backed up when the node is switched; The fault handling instruction is reported to the database management platform.

2. The method according to claim 1, characterized in that The acquiring node failure information of at least one node of the database includes: Each node corresponding to the database and hardware information of each node synchronized with the database management platform; Collecting the operation status information of each node in real time; Node fault information of the at least one node is acquired according to the operation status information of each node.

3. The method according to claim 1 or 2, characterized in that: The determining of the fault type according to the node fault information of each node, and determining the fault handling instruction according to the fault type, includes: Classify the node fault information of the node to determine the fault type, where the fault type includes at least one of event, state, alarm or performance indicator information; Determining fault severity information according to the node fault information and the fault type; A fault handling instruction is determined according to the fault degree information.

4. The method according to claim 1 or 2, characterized in that: The method further comprises: If an auxiliary switching request sent by the database management platform is received, the database management platform is assisted to complete the node switching of the database according to the auxiliary switching request.

5. A database node switching method based on hardware failure, characterized in that: Applied to database management platforms, including: Receiving a fault handling instruction of at least one node reported by a fault management service platform, wherein the fault handling instruction of each node is used to indicate content that needs to be backed up when the node is switched; For each node, node switching and content backup are performed according to the fault handling instruction of the node.

6. The method according to claim 5, characterized in that The performing node switching and content backup according to the fault handling instruction of the node includes: Determine a target node from backup nodes of the node in the database; According to the fault handling instruction, the content that needs to be backed up in the node is backed up to the target node, and the target node is switched to serve as the working node.

7. The method according to claim 5 or 6, characterized in that: The method further comprises: If the node switching of the database is not completed, an auxiliary switching request is sent to the fault management service platform, so that the fault management service platform assists in completing the node switching.

8. A database node switching device based on hardware failure, characterized in that: include: A node fault information acquisition module, used to acquire node fault information of at least one node in the database, wherein the fault information of each node is used to indicate the hardware fault condition of the node; A fault handling instruction determination module, used to determine the fault type of each node according to the node fault information of each node, and determine the fault handling instruction according to the fault type, wherein the fault handling instruction is used to indicate the content that needs to be backed up when the node is switched; The fault handling instruction reporting module is used to report the fault handling instruction to the database management platform.

9. A database node switching device based on hardware failure, characterized in that: include: A fault handling instruction receiving module, used to receive a fault handling instruction of at least one node reported by the fault management service platform, wherein the fault handling instruction of each node is used to indicate the content that needs to be backed up when the node is switched; The node switching module is used to perform node switching and content backup for each node according to the fault handling instruction of the node.

10. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

Images