Database node switching method and apparatus based on hardware failure, and device

Abstract

The application provides a database node switching method and device based on hardware failure and equipment. The method comprises the following steps: acquiring node failure information of at least one node of a database, wherein the failure information of each node is used for indicating the hardware failure condition of the node; for each node, determining a failure type according to the node failure information of the node, and determining a failure processing instruction according to the failure type; and reporting the failure processing instruction to a database management platform. The technical scheme improves the switching efficiency of the database failure node and ensures the continuity of the database service.

Description

Technical Field

[0001] This application relates to the field of database processing technology, and in particular to a method, apparatus, and device for switching database nodes based on hardware failure. Background Technology

[0002] In modern information systems, databases serve as critical infrastructure, widely used for data storage and management in various business systems. To improve system stability and business continuity, databases are typically deployed using a distributed architecture. One common deployment pattern is the master-slave architecture, where one node acts as the master, responsible for handling write operations and critical transactions, while the remaining nodes act as slave nodes, sharing the workload for read operations and data redundancy.

[0003] In existing technologies, when the physical machine where the primary node resides becomes unavailable due to hardware failure, the service can be transferred to the backup node through a primary-backup switchover mechanism, and the backup node can be promoted to primary, ensuring business continuity and high availability.

[0004] However, the aforementioned primary / standby node switching mechanism is time-consuming, resulting in low switching efficiency for database primary / standby nodes. Summary of the Invention

[0005] This application provides a database node switching method, apparatus, and device based on hardware failure, to solve the technical problem of long time consumption and low efficiency in database primary and backup node switching caused by node hardware failure.

[0006] Firstly, this application proposes a database node switching method based on hardware failure, applied to a fault management service platform, including:

[0007] Obtain node fault information for at least one node in the database, whereby the fault information for each node is used to indicate the hardware fault status of the node.

[0008] For each node, the fault type is determined based on the node fault information of each node, and a fault handling instruction is determined based on the fault type. The fault handling instruction is used to indicate the content that needs to be backed up during node switching.

[0009] The fault handling instructions are reported to the database management platform.

[0010] Furthermore, obtaining node fault information of at least one node in the database includes:

[0011] Based on the database management platform, the corresponding nodes of the database and the hardware information of each node are synchronized;

[0012] Real-time collection of the operating status information of each node;

[0013] Based on the operating status information of each node, obtain the node fault information of at least one node.

[0014] Further, the step of determining the fault type based on the node fault information of each node, and determining the fault handling instruction based on the fault type, includes:

[0015] The fault types are determined by classifying the node fault information of the nodes. The fault types include at least one of event, status, alarm or performance indicator information.

[0016] Based on the node fault information and the fault type, determine the fault severity information;

[0017] Based on the fault severity information, determine the fault handling instructions.

[0018] Furthermore, the method also includes:

[0019] If an auxiliary switching request is received from the database management platform, then the database management platform is assisted in completing the node switching of the database according to the auxiliary switching request.

[0020] Secondly, this application proposes a database node switching method based on hardware failure, applied to a database management platform, including:

[0021] Receive fault handling instructions from at least one node reported by the fault management service platform. The fault handling instructions for each node are used to indicate the 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 instructions of the node.

[0023] Furthermore, based on the fault handling instructions of the node, node switching and content backup are performed, including:

[0024] The target node is determined from the backup nodes of the node in the database;

[0025] 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 then used as the working node.

[0026] Furthermore, the method also includes:

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

[0028] Thirdly, this application proposes a database node switching device based on hardware failure, comprising:

[0029] The node fault information acquisition module is used to acquire node fault information of at least one node in the database, and the fault information of each node is used to indicate the hardware fault status of the node.

[0030] The fault handling instruction determination module is used to determine the fault type for each node based on the node fault information of each node, and to determine the fault handling instruction based on the fault type. The fault handling instruction is used to indicate the content that needs to be backed up during node switching.

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

[0032] Fourthly, this application proposes a database node switching device based on hardware failure, comprising:

[0033] The fault handling instruction receiving module is used to receive fault handling instructions from at least one node reported by the fault management service platform. The fault handling instruction for 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 instructions of the node.

[0035] Fifthly, this application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0036] The memory stores computer-executed instructions;

[0037] The processor executes computer execution instructions stored in the memory to implement the method as described in either the first or second aspect.

[0038] The database node switching method, apparatus, and device provided in this application based on hardware failure obtain node failure information of at least one node of the database, with the failure information of each node indicating the hardware failure status of the node; for each node, the failure type is determined based on the node failure information of each node, and a failure handling instruction is determined based on the failure type, with the failure handling instruction indicating the content that needs to be backed up during node switching; and the failure handling instruction is reported to the database management platform, which effectively improves the switching efficiency of the database primary and backup nodes. Attached Figure Description

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

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

[0041] Figure 2 A flowchart illustrating an embodiment of the database node switching method based on hardware failure provided in this application;

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

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

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

[0045] Figure 6 A flowchart illustrating Embodiment 5 of the database node switching method based on hardware failure provided in this application;

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

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

[0048] Figure 9 A schematic diagram of the structure of another switching device for a database node based on hardware failure provided in this application;

[0049] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

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

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

[0052] Existing databases are deployed using a master-slave architecture. A common operational scenario is the failure of the physical machine hosting the database, leading to master node failover. The current fault recovery process involves a host failure causing an operating system failure, which in turn causes a database failure. The database liveness detection mechanism detects the failure and switches the master node, ultimately restoring the database service. However, existing database failover mechanisms require waiting for the hardware failure to be reported to the database layer before triggering the failover. Furthermore, if the failure causes a process or thread failure within the database, the failover time will be even longer, significantly reducing efficiency.

[0053] To address the aforementioned technical issues, the inventors devised a method to proactively trigger the database master-slave switchover from the early stages of hardware failure. This involves establishing a fault management service platform that transforms hardware failures into resource alarm information and pushes it to the database management platform. This allows the database to complete the master-slave switchover in advance, thereby avoiding the impact of process and thread deadlock on the database switchover and significantly improving the switching efficiency of database nodes.

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

[0055] Figure 1 The overall architecture diagram of the database node switching method based on hardware failure provided in this application is shown below. Figure 1 As shown, it includes a fault management service platform 101 and a database management platform 102. The fault management service platform 101 includes a fault collection service 1011, a fault management service 1012 and a fault handling service 1013. 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 in the database is registered with the fault management service 1012. The fault management service 1012 also registers the hardware information of each node with the fault collection service 1011. The fault collection service 1011 subscribes to the corresponding nodes in the resource cloud based on the registration information, and records the subscription information in the database, completing the node registration process. Afterwards, when a node fails, the resource cloud reports the fault. The fault collection service 1011 converts the fault information into elements such as events, statuses, alarms, and performance indicators, and then reports it to the fault management service 1012 while recording it in the database. The fault management service 1012 performs fault impact assessment and fault event decision-making. Then, the fault event decision is sent to the fault handling service 1013 for overall coordination and scheduling. Finally, the fault handling service 1013 sends the handling instructions to the database management platform 102 for execution.

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

[0058] Furthermore, the technical solution of this application is based on the existing cloud platform architecture. By establishing a new fault service platform 101, hardware faults are transformed into cloud resource (Infrastructure as a Service, IaaS) alarms, which are then sent to the fault management service platform 101 according to the region. After the fault management service platform 101 processes and filters the alarm information, it is pushed to the database management platform 102. The database management platform 102 processes the fault handling information into two information streams: one is sent to the alarm platform for alarm notification, and the other is sent to the database for primary / backup node switching. Figure 1 As shown, the IASS cloud is equipped with Kunpeng servers and OceanStor Dorado all-flash storage (abbreviated as Dorado). Hardware faults in the Kunpeng servers and Dorado storage are detected through hardware alarms and in-depth inspections. These hardware faults are then transformed into IaaS resource faults and reported to the IaaS cloud platform. The IaaS cloud platform enriches the hardware fault information by adding IaaS resource identifiers, fault event names, and other resources, and forwards the enriched fault information to fault management service platforms 101 in different regions.

[0059] Figure 2This is a flowchart illustrating an embodiment of the database node switching method based on hardware failure provided in this application. Figure 2 As shown, it includes:

[0060] S201. Obtain node fault information for at least one node in the database.

[0061] In this context, a database node refers to a server unit within the database responsible for storing, processing, and managing data. A distributed database may consist of multiple nodes. In this embodiment, the database can be considered to have three nodes, including one primary node and two backup nodes. Node hardware fault information indicates hardware failures of the nodes. The hardware components include storage devices, processors, memory, and network interfaces, among others.

[0062] In this step, the fault management service platform can obtain node hardware fault information of the database from the resource cloud, where the resource cloud manages the node hardware resources of the database. For example, the resource cloud can discover hardware faults in Kunpeng servers and Dorado storage through hardware alarms and in-depth inspections, transforming these hardware faults into cloud resource faults and reporting them to the resource cloud platform. The resource cloud platform enriches the hardware fault information by adding resources such as resource identifiers and fault event names, and then 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 centrally collect and organize it for subsequent node fault handling.

[0063] S202. For each node, determine the fault type based on the node fault information of each node, and determine the fault handling instruction based on the fault type.

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

[0065] Then, the fault management service platform will map hardware faults to physical devices and logical instances. For example, there may be a dependency between hardware faults 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 instance to ensure that the availability of the database instance is taken into account when handling faults.

[0066] Then, all node hardware fault information is categorized and organized to determine the fault type of each node. Finally, based on the fault type, predefined processing rules are applied to each type of fault, and fault handling instructions are issued.

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

[0068] The database management platform is a tool or system for centralized management of databases, responsible for monitoring, managing, and optimizing database operations, including tasks such as fault handling and resource allocation. Node switching simply involves transferring the database workload from the failed node to a standby or healthy node when a hardware failure occurs, ensuring continued database availability.

[0069] S204. Receive fault handling instructions from at least one node reported by the fault management service platform.

[0070] Each node's fault handling instructions indicate the content that needs to be backed up during node failover. For the database management platform, based on the instructions reported from the fault management service platform, it can confirm the hardware information of the faulty node and its relationship to other nodes, such as which node is the primary node, what the corresponding storage content on the primary node is, and which node is the backup node. It can also determine which node experienced a hardware failure, whether there is a backup node available for node failover, whether the hardware failure affects the normal operation or service of the database, and check the health status of all nodes to ensure that the backup node is synchronized and capable of taking over the primary node.

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

[0072] Before performing a database node switch, it is usually necessary to ensure data integrity. If the primary node is still available, a backup can be performed first. If the primary node is completely unavailable, it may be necessary to restore the data from the most recent backup or node.

[0073] Specifically, if the failed node is the primary node, the standby node needs to be promoted to primary. This process typically involves switching roles within the database management platform to ensure the new primary node can take over all the content of the original primary node, including read and write requests. Then, the new worker node is switched to become the database's worker node to ensure uninterrupted database service. After the primary / standby switch is complete, it's crucial to ensure that the standby node (the new primary node) and other slave nodes are synchronized correctly. This involves checking the database's health after the switch to ensure no data loss and that the synchronization process is complete. After the switch, hardware repair can be performed on the failed node. Once repaired, the repaired node can be redeployed into the database, enabling it to function as a standby node.

[0074] The database node switching method based on hardware failure provided in this application detects hardware failures in database nodes through a fault management service platform and issues processing instructions, specifying the fault type, node status, and processing requirements. Next, the database management platform obtains faulty node information based on these instructions, confirms whether a backup node is available for switching, and performs necessary operations, such as promoting the backup node to the primary node, synchronizing data, and ensuring stable database operation. Finally, the fault management service platform and the database management platform jointly monitor the status after node switching to ensure uninterrupted database service and restoration of normal operation, thereby improving the efficiency of database node switching.

[0075] Figure 3 This is a flowchart illustrating 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 implementation example, node fault information of at least one node in the database is obtained, including:

[0076] S301. Based on the database management platform, synchronize the data of each node and the hardware information of each node.

[0077] In this embodiment, the database management platform needs to collect hardware information of all nodes, including node hardware configurations (such as memory, disks, network devices, etc.) and operating status, and register and synchronize each node to the fault management service platform. Upon receiving the node registration and synchronization information, the fault management service platform synchronizes and updates 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 handling. Then, the fault management service platform further transmits or registers the hardware information to the fault collection service. The fault collection service is responsible for collecting and analyzing the operating status of each node, and through its interface with the fault management service within the fault management service platform, ensures that all hardware information is promptly fed back to the fault management service platform, ensuring timely response to hardware faults. Once a node is successfully registered, the fault collection service subscribes to the corresponding nodes in the resource cloud based on 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 operating status promptly. Finally, the subscribed node information is recorded in the database, providing a basis for subsequent fault handling and ensuring that the fault management service platform can accurately track the status and related hardware data of each node.

[0078] S302. Real-time collection of operating status information of each node.

[0079] In this step, database management monitors the operational status of each database node through real-time monitoring and data acquisition systems, including node memory usage, network connectivity, database instance load, and query response time. This information is continuously collected via real-time data streaming and transmitted to the fault management service platform to ensure that the platform receives the latest node operational data.

[0080] S303. Based on the operating status information of each node, obtain the node fault information of at least one node.

[0081] In this step, the fault management service platform uses collected operational status information from each node to analyze algorithms or threshold monitoring to determine if a hardware fault exists. This includes abnormal hardware node usage (such as overload, frequent errors, etc.), network latency or inter-node communication failures, and signs of hardware failure (such as disk failure, device offline, etc.). Once a potential fault is identified, the fault management platform generates an alarm or fault handling instruction and feeds it back to the database management platform to initiate the corresponding fault troubleshooting and node switching processes.

[0082] The database node switching method based on hardware failure proposed in this 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 a timely manner, thereby achieving high availability and fault recovery of the database.

[0083] Figure 4 This is a flowchart illustrating 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 implementation example, 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 faults based on the node fault information to 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 node in the database according to different fault types. Specific classifications include at least one of the following: events, status, alarms, and performance metrics. Events refer to the specific occurrence of a hardware fault, such as a hard drive failure or memory anomaly on a node; status refers to the current state of the node, including whether it is running normally and whether there are any anomalies; alarms refer to the warnings and alerts issued by the fault management service platform, which may indicate that a node has experienced an anomaly but not necessarily a fault, serving as an early risk warning; performance metrics refer to metrics related to hardware performance, such as memory usage and disk I / O performance. If these performance metrics exceed preset thresholds, it may indicate a potential hardware fault.

[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 monitoring trigger.

[0087] S402. Determine the degree of fault information based on the node fault information and fault type.

[0088] Based on the categorized 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 failure occurs (such as hard drive failure, node crash, etc.), the severity of the fault may be assessed as high. For status information, if a node is in an abnormal state (such as excessive load, prolonged unresponsiveness, etc.), the fault management service platform needs to assess the degree of the fault based on the node's health status. For alarm information, alarms themselves may indicate potential risks, and the assessment will consider the alarm level; low-level alarms may only require further monitoring, while high-level alarms may require immediate handling. For performance indicator information, if certain performance indicators exceed set thresholds, this may indicate a potential hardware failure risk, and the fault management service platform will assess the severity of the fault based on these indicators. Finally, through comprehensive evaluation, the fault management service platform will derive overall fault severity information based on different information categories, including minor 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 crashes, hardware failures, etc.).

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

[0090] In this step, the fault management service platform generates corresponding fault handling instructions based on the assessed fault severity. For example, for minor faults, it may only require generating monitoring alerts or adjusting the load, or marking the problem as requiring observation without immediate remedial action; for moderate faults, it may require partial repair, restarting, optimizing resource allocation on affected nodes, or notifying operations personnel for further inspection; for severe faults, immediate emergency measures are required, which may include migrating data, starting standby nodes, or even stopping services to prevent a wider range of failures. In some cases, the fault management service platform may automatically generate and execute handling instructions according to preset rules (such as automatically restarting nodes or switching to standby nodes), or it may notify operations personnel for manual intervention.

[0091] The database node switching method based on hardware faults proposed in this application ensures that the fault management service platform can effectively classify and process hardware faults of database nodes and formulate corresponding fault handling solutions based on the actual fault situation by classifying, evaluating and processing hardware fault information.

[0092] Figure 5 This is a flowchart illustrating 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 implementation example, node switching and content backup are performed according to the node's fault handling instructions, including:

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

[0094] This step involves assessing the status of each node based on its hardware failure information to determine the relationship between the primary and backup nodes. Specifically, it involves identifying the failure information of each node in the database, including the failure type, severity (e.g., memory failure, disk failure), and the node's current status (failed, recovering, normal). For example, if a node's disk fails and cannot be recovered, that node might be marked as "failed." Next, the role of each node is analyzed. The primary node, typically the core node of the database, is responsible for data read and write operations. If the primary node fails, a rapid switch to a target node is necessary to ensure uninterrupted database service. The target node is the backup node for the database, responsible for disaster recovery and load balancing. When the primary node fails, the target node automatically takes over its responsibilities. If the primary node fails and no suitable target node is available, another healthy node may need to be selected as the new target node.

[0095] First, identify the faulty node. Based on the severity of the hardware failure, determine which nodes are in a "faulty" state. For example, if a node's hard drive fails and cannot be repaired, that node can be identified as a faulty node. Next, assess which nodes are still in a "normal" or "recovering" state and can serve as the primary or backup node. Then, determine the relationship between the primary and backup nodes. If the primary node fails, a new primary node, the target node, needs to be selected from other healthy backup nodes. The target node will assume the responsibility of the primary node in the event of its failure; therefore, its status needs to be checked to ensure it is healthy and eligible for promotion to the new primary node.

[0096] In addition, it is necessary to determine the level of the fault to ascertain whether an emergency switchover is required. If the fault is severe (e.g., hard drive failure), an immediate switchover is necessary; if the fault is minor (e.g., excessive load), an immediate switchover may not be necessary.

[0097] S502. According to the fault handling instructions, back up the content that needs to be backed up in the node to the target node, and switch the target node as the working node.

[0098] After determining which nodes will be the target nodes, the node switch will be performed. Specifically, (1) Confirm the target node. If the existing master node fails and the standby node is available, the standby node will be 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, a healthy standby node needs to be selected as the new target node and the data will be synchronized. (2) Perform the node switch. 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 the newly written data. Then, according to the load balancing requirements, the new healthy node will be designated as the new standby node. The new standby node will start replicating the data of the new master node. (3) Database synchronization. After the switch, it is necessary to ensure that the database is synchronized between the new target node and the new standby node. If the data of the standby node has not been fully synchronized with the new target node, there is a risk of data loss during the switch. Therefore, it is necessary to ensure that data synchronization is completed before switching. If there is no real-time data synchronization mechanism (such as log-based replication or incremental synchronization), data synchronization needs to be performed manually before switching, or write operations need to be temporarily suspended until synchronization is completed.

[0099] Another point to note is that the database cluster configuration also needs to be updated to ensure that the roles of the new master node and standby node are identified and applied; at the same time, a load balancer or proxy should be configured to ensure that external requests can be correctly routed to the new master node.

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

[0101] This application provides a database node switching method based on hardware failure. By analyzing the hardware status through fault information, it determines which nodes have failed and which nodes can act as primary and backup nodes. Then, it completes the switch from primary to backup node, including updating database roles, ensuring data synchronization, configuring load balancing and monitoring systems. This ensures that when hardware failure occurs, the database management platform can automatically or manually complete the node switch, guaranteeing the high availability and stability of the database service.

[0102] Figure 6 This is a flowchart illustrating Embodiment 5 of the database node switching method based on hardware failure provided in this application. Figure 6 As shown, in Figure 2 Based on the embodiments, the method further includes:

[0103] S601. If the database node switch is not completed, send an auxiliary switch request to the fault management service platform so that the fault management service platform can assist in completing the node switch.

[0104] For a database management platform, if the severity of the fault exceeds the platform's processing capacity during node switching, or if the node switching fails for some reason (such as synchronization problems, configuration errors, etc.), it will send a request to the fault management service platform to seek external assistance to complete the switch.

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

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

[0107] S602. If an auxiliary switching request is received from the database management platform, the database management platform shall be assisted in completing the node switching of the database according to the auxiliary switching request.

[0108] For the fault service management platform, upon receiving an assisted switchover 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 primary or standby node. If node selection fails or the current node cannot take over the primary node's responsibilities, it may instruct the database management platform to select another standby node; 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 may also enable backup fault handling mechanisms, such as data recovery or cold backup recovery, if a conventional node switchover cannot be completed. Finally, it sends new fault handling instructions to the database management platform to ensure a smooth node switchover.

[0109] After receiving a fault handling instruction from the fault management service platform, the database management platform will retry the node switchover according to the guidance of the fault management service platform. For example, when performing a node switchover operation, the platform will select a node based on the new instruction. If the fault management service platform instructs the selection of a new primary or standby node, the database management platform will perform the corresponding operation according to the instruction.

[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 configuration, it may be necessary to update the database cluster configuration, such as adjusting the master-slave relationship or updating the load balancing strategy, depending on the instructions from the fault management service platform. After the node switchover operation is completed, the database management platform will perform health checks on the new master node and standby node to ensure that the switched database system can operate normally. If the switchover is successful, the database management platform will record the operation log and report the success information to the fault management service platform. Once the node switchover is complete 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 this application involves sending a request to a fault management service platform for assistance when the database management platform is unable to complete the node switch. Upon receiving the request, the fault management service platform generates and sends new fault handling instructions to enable the database management platform to perform the correct switching operation. After receiving the instructions from the fault management service platform, the database management platform re-performs the node switch operation and ensures a successful switch. This process ensures timely support and recovery of the database in the event of a failure. It relies not only on the internal mechanisms of the database management platform but also on the assistance of the fault management service platform to complete more complex fault handling tasks, thereby improving the database's fault tolerance and availability.

[0112] Figure 7 This application provides a flowchart for fault information processing in database node switching based on hardware failure. Figure 7 As shown, the key to processing fault information lies in the fault management service platform, as detailed below:

[0113] After receiving fault information, the fault management service platform first performs information cleaning. By mapping physical device and logical instance information, it ensures 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 fault codes and decides on corresponding actions based on the preset fault decision database. There are three types of fault decisions: (1) Automatic database instance switching: When the decision is automatic switching, the fault information center will send the instruction to the fault information transmission module, which will directly issue a primary / standby switching command to the fault instance. (2) Switching with the assistance of the management platform: If automatic switching fails or is not applicable, the fault information center will initiate an assisted switching with the management platform and record the decision scenario for subsequent optimization. (3) No switching required, only fault notification sent: If the fault situation does not require switching, the fault information center will only send an alarm notification to the relevant platform.

[0115] Additionally, if the database instance fail to switch over from primary to standby, the failure information, along with the previous switchover command, will form new fault information. This information will then flow back to the information receiving module, undergo further information cleaning, and finally reach the fault information center again. The fault information center will then initiate an auxiliary switchover request to the management platform and record the scenario in the fault decision database.

[0116] For situations requiring assisted failover from the management platform, the fault information center sends instructions to the management platform's auxiliary action module. This module performs a secondary verification of the instance information to ensure the feasibility of the faulty environment. After verification, the management platform executes the assisted failover operation. Regardless of the decision type, an alarm notification is sent to the relevant platforms upon completion of the failover, ensuring that operations and maintenance personnel are promptly informed of the fault handling results.

[0117] The database node switching method based on hardware failure provided in this application involves a fault information center periodically analyzing data in the fault decision database and optimizing it based on the frequency and effectiveness of fault handling. For scenarios that frequently require assisted switching, the decision type may be changed from "automatic switching" to "assisted switching," thereby improving the switching efficiency of database nodes.

[0118] Figure 8 A schematic diagram of the hardware fault-based database node switching device provided in this application. Figure 8As shown, the database node switching device 80 based on hardware failure includes a node failure information acquisition module 801, a failure handling instruction determination module 802, and a failure handling 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 status of the node.

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

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

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

[0123] Based on the database management platform, the corresponding nodes and hardware information of each node are synchronized.

[0124] Real-time collection of operational status information from each node;

[0125] Based on the operating status information of each node, obtain the node fault information of at least one node.

[0126] Furthermore, the fault handling instruction determination module 802 is also specifically used for:

[0127] The fault types are classified based on the node fault information. The fault types include at least one of the following: event, status, alarm or performance indicator information.

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

[0129] Based on the fault severity information, determine the fault handling instructions.

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

[0131] If an auxiliary switch request is received from the database management platform, the database management platform will be assisted in completing the node switch of the database according to the auxiliary switch request.

[0132] Figure 9 A schematic diagram of another switching device for a database node based on hardware failure, provided in this application. Figure 9As shown, the database node switching device 90 based on hardware failure includes a fault handling instruction receiving module 901 and a node switching module 902, wherein,

[0133] The fault handling instruction receiving module 901 is used to receive fault handling instructions from at least one node reported by the fault management service platform. The fault handling instructions for each node are used to indicate the content that needs to be backed up during node switching.

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

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

[0136] The target node is determined from the backup nodes of the nodes in the database;

[0137] According to the fault handling instructions, back up the content that needs to be backed up in the node to the target node, and then switch the target node as the working node.

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

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

[0140] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 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, memory 1002, and communication component 1003 are connected via a bus 1004.

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

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

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

[0145] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[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. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0147] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0148] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

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

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

Claims

1. A database node switching method based on hardware failure, characterized in that, Applications to fault management service platforms include: Obtain node fault information for at least one node in the database. The fault information for each node is used to indicate the hardware fault condition of the node, including hardware network latency, inter-node communication failure, disk failure, and / or device offline. For each node, the node fault information is classified to determine the fault type, which includes at least one of event, status, alarm or performance indicator information; based on the node fault information and the fault type, the fault severity information is determined, wherein the fault severity information includes severe faults, which can be determined based on node downtime or hardware failure. Based on the fault severity information, fault handling instructions are determined. The fault handling instructions for each node are used to indicate the content that needs to be backed up during node switching. For severe faults, emergency measures need to be taken immediately, including data migration and starting a backup node. The fault handling instructions are reported to the database management platform so that the database management platform can receive the fault handling instructions and perform node switching and content backup for each node according to the node's fault handling instructions, thereby proactively triggering the primary-backup switch of the database in the early stage of hardware failure; the database management platform is a tool or system for centralized management of the database. The method further includes: When an auxiliary switching request is received from the database management platform, an auxiliary switching operation is performed to assist in completing the node switching. The request information of the auxiliary switching request includes new fault information, which can be obtained based on the failure information and the previous switching command.

2. The method according to claim 1, characterized in that, The step of obtaining node failure information for at least one node in the database includes: Based on the database management platform, the corresponding nodes of the database and the hardware information of each node are synchronized; Real-time collection of the operating status information of each node; Based on the operating status information of each node, obtain the node fault information of at least one node.

3. A database node switching method based on hardware failure, characterized in that, Applied to a database management platform, wherein the database management platform is a tool or system for centralized management of databases, the method includes: The system receives fault handling instructions from at least one node reported by the fault management service platform. Each node's fault handling instruction indicates the content that needs to be backed up during node switching. For severe faults, immediate emergency measures are required, including data migration and activating a backup node. The fault handling instructions can be determined based on fault severity information, which includes severe faults. Severe faults can be determined based on node downtime or hardware failure. The fault severity information can be determined based on node fault information and fault type. The fault type includes at least one of event, status, alarm, or performance indicator information. The fault type can be obtained by classifying node fault information in the database. Each node's fault information indicates the node's hardware failure status, including hardware network latency, inter-node communication failure, disk failure, and / or device offline. For each node, node switching and content backup are performed according to the fault handling instructions of the node, thereby proactively triggering the primary-backup switch of the database in the early stages of hardware failure. The method further includes: A request for assisted switching is sent to the fault management service platform so that the fault management service platform can perform an assisted switching operation to assist in completing the node switching. The request information for the assisted switching request includes new fault information, which can be obtained based on the failure information and the previous switching command.

4. The method according to claim 3, characterized in that, The step of switching nodes and backing up content according to the fault handling instructions of the node includes: The target node is determined from the backup nodes of the node in the database; 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 then used as the working node.

5. A database node switching device based on hardware failure, characterized in that, Applied to a fault management service platform for performing the method as described in claim 1 or 2, the apparatus comprises: The node fault information acquisition module 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. The hardware fault condition includes hardware network latency, inter-node communication failure, disk failure and / or device offline. The fault handling instruction determination module is used to classify and determine the fault type based on the node fault information of the node. The fault type includes at least one of event, status, alarm, or performance indicator information. Based on the node fault information and the fault type, it determines the fault severity information, wherein the fault severity information includes severe faults, which can be determined based on node downtime or hardware failure. Based on the fault severity information, it determines the fault handling instruction, wherein the fault handling instruction for each node is used to indicate the content that needs to be backed up during node switching. For severe faults, immediate emergency measures are required, including data migration and starting a backup node. The fault handling instruction reporting module is used to report the fault handling instructions to the database management platform, so that the database management platform can receive the fault handling instructions and perform node switching and content backup for each node according to the node's fault handling instructions, thereby proactively triggering the primary-backup switch of the database in the early stage of hardware failure; the database management platform is a tool or system for centralized management of the database. The device is also used to: when receiving an auxiliary switching request sent by the database management platform, perform an auxiliary switching operation to assist in completing the node switching. The request information of the auxiliary switching request includes new fault information, which can be obtained based on the failure information and the previous switching command.

6. A database node switching device based on hardware failure, characterized in that, For performing the method as described in claim 3 or 4, applied to a database management platform, said database management platform being a tool or system for centralized database management, the apparatus comprising: The fault handling instruction receiving module is used to receive fault handling instructions from at least one node reported by the fault management service platform. The fault handling instruction for each node is used to indicate the content that needs to be backed up during the node switchover. For severe faults, emergency measures need to be taken immediately, including data migration and starting a backup node. The fault handling instruction can be determined based on fault severity information, which includes severe faults. Severe faults can be determined based on node downtime or hardware failure. The fault severity information can be determined based on node fault information and fault type. The fault type includes at least one of event, status, alarm, or performance indicator information. The fault type can be obtained by classifying the node fault information in the database. The fault information for each node is used to indicate the hardware failure status of the node, including hardware network latency, inter-node communication failure, disk failure, and / or device offline. The node switching module is used to perform node switching and content backup for each node according to the fault handling instructions of the node, thereby proactively triggering the primary-backup switch of the database in the early stage of hardware failure. The device is further configured to: send an auxiliary switching request to the fault management service platform so that the fault management service platform performs an auxiliary switching operation to assist in completing the node switching. The request information of the auxiliary switching request includes new fault information, which can be obtained based on the failure information and the previous switching command.

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

Images