A multi-dimensional based database disaster recovery method and device

Abstract

The embodiment of the application discloses a kind of based on multi-dimension database disaster recovery method and device, collect the network connectivity data of each node in database, database log, operating system kernel log and database event;Wherein, each node includes master node and backup node;According to the network connectivity data of each node, judge whether it meets preset master backup switching condition;If it meets preset master backup switching condition, then trigger master backup switching action;According to the database log of each node, operating system kernel log and database event, predict the failure rate of database in future period;If failure rate exceeds preset threshold, then execute database maintenance task;The application can reach the availability of master and backup nodes by business network card, management network card multi-link detection, avoid the abnormal switching of master and backup simple mutual ping, continuously monitor and predict the probability of master and backup node failure, automatically trigger initiative maintenance.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a multi-dimensional database disaster recovery method and apparatus. Background Technology

[0002] With the development of open-source Structured Query Language (SQL) databases, such as PostgreSQL (also known as PG database), the high concurrency and massive data of Internet applications have made the database load increasingly heavy. As the only "single point" in the entire application system, the ability of the database to reliably provide services to the application has become increasingly important.

[0003] In high-availability scenarios, PG databases offer various solutions, including single-point, master-slave, and one-master-multiple-slave configurations. Among these, the master-slave configuration is the preferred deployment option. There are two master-slave solutions: one is to bind the core account (VIP) via a plugin, and the other is to elect a sentinel (Redis process).

[0004] However, the plug-in-VIP binding method can lead to continuous VIP drift and a split-brain state under network fluctuations, causing the database to become read-only and jeopardizing application system availability. In the sentinel election method, the sentinel cluster requires at least multiple servers to complete the election process. Including the master and slave database nodes, the entire database cluster requires at least five servers to build a high-availability scenario, resulting in resource waste in resource-constrained situations. Furthermore, both of these master-slave solutions passively handle failures in the master-slave link, failing to predict database downtime to trigger proactive maintenance. Summary of the Invention

[0005] In view of the above problems, this application proposes a multi-dimensional database disaster recovery method, device, computing equipment and computer storage medium to solve the following problems: existing high availability solutions are all passive handling when failures occur, and there is no problem of predicting database downtime to trigger proactive maintenance actions.

[0006] According to one aspect of the embodiments of this application, a multi-dimensional database disaster recovery method is provided, including:

[0007] The system collects network connectivity data, database logs, operating system kernel logs, and database events from each node in the database; wherein each node includes a primary node and a backup node.

[0008] Based on the network connectivity data of each node, determine whether the preset primary / backup switchover conditions are met; if the preset primary / backup switchover conditions are met, then trigger the primary / backup switchover action.

[0009] Based on the database logs of each node, the operating system kernel logs, and the database events, predict the failure rate of the database in the future period;

[0010] If the failure rate exceeds a preset threshold, a database maintenance task will be performed.

[0011] According to another aspect of the embodiments of this application, a multi-dimensional database disaster recovery device is provided, comprising:

[0012] The acquisition module is used to collect network connectivity data, database logs, operating system kernel logs, and database events from various nodes in the database; wherein, the various nodes include a primary node and a backup node;

[0013] The judgment module is used to determine whether the preset master-slave switchover conditions are met based on the network connectivity data of each node.

[0014] The triggering module is used to trigger a primary / standby switchover action if the preset primary / standby switchover conditions are met.

[0015] The prediction module is used to predict the failure rate of the database in a future period based on the database logs of each node, the operating system kernel logs, and the database events.

[0016] The processing module is used to perform database maintenance tasks if the failure rate exceeds a preset threshold.

[0017] According to another aspect of the embodiments of this application, a computing device is provided, including: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus;

[0018] The memory is used to store at least one executable instruction, which causes the processor to perform the operation corresponding to the multi-dimensional database disaster recovery method described above.

[0019] According to another aspect of the embodiments of this application, a computer storage medium is provided, wherein at least one executable instruction is stored in the storage medium, and the executable instruction causes a processor to perform the operation corresponding to the above-described multi-dimensional database disaster recovery method.

[0020] According to an embodiment of this application, a multi-dimensional database disaster recovery method and apparatus are provided. This method collects network connectivity data, database logs, operating system kernel logs, and database events from each node in the database. Each node includes a primary node and a backup node. Based on the network connectivity data of each node, it determines whether preset primary / backup switchover conditions are met. If the preset primary / backup switchover conditions are met, a primary / backup switchover action is triggered. Based on the database logs, operating system kernel logs, and database events of each node, the database failure rate in a future period is predicted. If the failure rate exceeds a preset threshold, a database maintenance task is executed. This invention uses multi-link detection of primary and backup node reachability via service network cards and management network cards to avoid abnormal switching due to simple mutual ping between primary and backup nodes. It continuously monitors and predicts the probability of primary and backup node failures and automatically triggers proactive maintenance.

[0021] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of the embodiments of this application are described below. Attached Figure Description

[0022] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0023] Figure 1 A flowchart illustrating a multi-dimensional database disaster recovery method according to an embodiment of this application is shown.

[0024] Figure 2 A schematic diagram of the architecture of a multi-dimensional database disaster recovery method according to an embodiment of this application is shown;

[0025] Figure 3a This diagram illustrates a probe-initiated bidirectional service network interface card (NIC) probe operation according to an embodiment of this application.

[0026] Figure 3b A schematic diagram illustrating the interaction between the probe acquisition container and the sample library container according to an embodiment of this application is shown;

[0027] Figure 3c A schematic diagram illustrating the interaction between the sample library container and the database crash prediction container according to an embodiment of this application is shown;

[0028] Figure 4 A structural block diagram of a multi-dimensional database disaster recovery device according to an embodiment of this application is shown;

[0029] Figure 5 A schematic diagram of the structure of a computing device according to an embodiment of this application is shown. Detailed Implementation

[0030] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0031] This invention first performs connectivity detection from multiple dimensions from an application perspective. When the detection fails, it triggers a switchover action between the master node and the backup node, and records the switchover time and reason. At the same time, it collects multi-dimensional performance data samples, performs statistical analysis using the Naive Bayes classification algorithm, predicts whether the database will fail in the future, and triggers proactive maintenance.

[0032] Figure 1 A flowchart illustrating a multi-dimensional database disaster recovery method according to an embodiment of this application is shown, such as... Figure 1 As shown, the method includes the following steps:

[0033] Step S110: Collect network connectivity data, database logs, operating system kernel logs, and database events for each node in the database.

[0034] Each node includes a master node (PG master) and a standby node (PG standby); in an optional manner, step S110 further includes: directly connecting each node with a probe, sending instructions to each node to enable each node to perform bidirectional service NIC detection operations and bidirectional management NIC detection operations; and collecting network connectivity data generated by each node through performing bidirectional service NIC detection operations and bidirectional management NIC detection operations.

[0035] This embodiment uses the PG database as an example. Figure 2 A schematic diagram of the architecture of a multi-dimensional database disaster recovery method according to an embodiment of this application is shown, such as... Figure 2 As shown, the probes of the probe acquisition container are directly connected to the master node and the backup node to collect network connectivity data, database logs, operating system kernel logs, and database events from multiple network cards on the master and backup nodes of the PG database. The collected feature data is written into the sample library container. The sample library container is composed of a time-series database (such as a TSDB database) and is responsible for storing the data collected by the probe acquisition container.

[0036] Furthermore, Figure 2 The database outage prediction container is used to classify and statistically analyze sample features in the sample database based on the Bayesian classification algorithm, and calculate the probability of database outage caused by various database events. The arbitration container arbitrates in two ways: firstly, it determines whether the current database is connected based on real-time multi-dimensional network connectivity data; if multiple links fail to connect, it performs a switchover between the primary and backup nodes; secondly, based on the outage probability calculated by the database outage prediction container, it predicts the probability of database failure within a future period (e.g., one day) and performs proactive maintenance.

[0037] Based on error information from database logs, operating system kernel logs, and database events, the system can proactively predict the failure probability of master and standby nodes and trigger proactive maintenance actions, thereby improving the availability of the database cluster. Specifically, error information from the operating system kernel logs is generated based on the experience of operations and maintenance personnel. A rule base is formed based on the error information from the operating system kernel logs. The rule base is used to match key error information that is valuable for fault prediction. The data is then preprocessed to obtain the input data format required by the classifier. The classifier predicts the failure probability of master and standby nodes based on the model and accumulated sample data. The arbitration module determines whether to perform proactive failover to avoid faults based on probability. The cluster fault monitoring and recording module regularly monitors the cluster status and continuously updates the sample data collected in each period, the prediction results, and whether a fault actually occurred to the classifier's sample library. The continuously enriched sample library will continuously improve the prediction probability of the classifier, thereby improving the availability of the cluster.

[0038] Specifically, Figure 3a This diagram illustrates a probe-initiated bidirectional service network interface card (NIC) probe operation according to an embodiment of this application. Figure 3a As shown, the PG database master node and backup node generate public / private key files and distribute them to the probe nodes of the probe collection container. The probe nodes of the probe collection container connect to the master node and backup node to collect network connectivity data, database logs, operating system kernel logs, and database events and write them to the Time Series Database (TSDB). To ensure the accuracy and real-time nature of the data, network connectivity data can be probed once at a preset time granularity (e.g., 15 seconds), and database logs, operating system kernel logs, and database events can be collected in real time.

[0039] In one optional approach, network connectivity data includes: interconnection data between the two service NIC nodes, interconnection data between the two management NIC nodes, and probe-connected database detection data. Specifically, the probe collects network connectivity data from the application perspective by directly connecting to the primary and backup nodes using Java Database Connect (JDBC). The probe sends commands to the primary and backup nodes, and initiates bidirectional service NIC probe operations through virtual NICs (e.g., veth) by calling the psql clients of the primary and backup nodes to obtain interconnection data between the two service NIC nodes. It then executes a simple query using the select command (select 1) and creates a temporary table file (i.e., the tmp_ file) with timestamps.

[0040] Similarly, the probe sends commands to the PG master node and PG standby node, and uses the front end (psql client) of the PG database master and standby nodes to initiate a bidirectional management network card probe operation to obtain the interconnection data between the two management network card nodes, and executes a simple select 1 query and creates a temporary table tmp_timestamp respectively.

[0041] It should be noted that database events are obtained from the kernel logs and database logs of the primary and standby nodes, respectively. Specifically, database events are obtained by sending event collection instructions to the data collection engine (such as Logstash) via User Datagram Protocol (UDP). After obtaining the database events, the filtering plugin extracts keywords from the database event logs according to multiple filtering rules, and outputs the filtered database events into the time-series database. Specifically, the filtering plugin performs an initial filtering based on database log levels and filtering rules. For example, the default filtering rule is to extract warning-level logs, such as ERROR, FATAL, and PANIC level logs. For instance, ERROR logs are used to extract 32 semaphores into the sample database based on the keyword "server process was terminated by signal". FATAL and PANIC level logs can also be matched with keywords in a similar way, and warning-level logs are imported into the time-series database sample database as database events. Kernel logs can directly send warning-level logs, such as warning, error, crit, alert, and emerg level logs. The filtering plugin extracts warning logs based on these warning levels and imports them into the time-series database sample database as database events.

[0042] Step S120: Based on the network connectivity data of each node, determine whether the preset primary / backup switchover conditions are met; if the preset primary / backup switchover conditions are met, proceed to step S130; if the preset primary / backup switchover conditions are not met, return to step S110.

[0043] Step S130: Trigger the primary / standby switchover action.

[0044] Specifically, the network connectivity of the primary and backup nodes is determined based on the network connectivity data of each node. If any of the interconnection data between the two nodes of the service network card, the interconnection data between the two nodes of the management network card, or the probe connection data to the database is connected, the task ends. If none of the interconnection data between the two nodes of the service network card, the interconnection data between the two nodes of the management network card, or the probe connection data to the database are connected, it is determined that the primary / backup switchover conditions are met, and the primary / backup switchover action is triggered.

[0045] Step S140: Based on the database logs, operating system kernel logs, and database events of each node, predict the database failure rate in the future.

[0046] In an alternative embodiment, step S140 further includes the following steps 1-3:

[0047] Step 1: Process the database logs, operating system kernel logs, and database events of each node to obtain the characteristic data of each node, and write the characteristic data of each node into the time series database.

[0048] In one optional approach, step 1 further includes: filtering the database logs, operating system kernel logs, and database events of each node using preset filtering rules, and then matching the database logs, operating system kernel logs, and database events with keywords to obtain processed database logs, processed operating system kernel logs, and processed database events; for each node in each node, using the processed database logs, processed operating system kernel logs, and processed database events of that node as the feature data of that node.

[0049] Step 2: Extract feature data of each node in the current time period from the time series database.

[0050] Step 3: Based on the characteristic data of each node in the current time period, predict the failure rate of the database in future time periods.

[0051] In an optional approach, step 3 further includes: processing the feature data of each node in the current time period to obtain sample data of each node, and writing the sample data of each node into the sample database; classifying and statistically analyzing the sample data of each node in the sample database according to the Bayesian classification algorithm, and calculating the failure rate of the database in future time periods.

[0052] Figure 3b A schematic diagram illustrating the interaction between the probe acquisition container and the sample library container according to an embodiment of this application is shown, such as... Figure 3bAs shown, specifically, the database failure prediction container extracts sample data from the master node and the backup node from the sample library container to calculate the database failure rate in the future period. The two sets of sample data are processed independently, and the output plugin is written to the time series database by matching them with preset database keyword indicators. The sample library container extracts the keyword indicators for the current day from the TSDB. If a match is found, the result set is 1; otherwise, it is 0. A set [No, Yes, No, Yes, No, Yes.....No] is generated and written to the sample library of the sample library container, where Yes = 1 and No = 0. As the sample library is continuously updated, the prediction results can be made more accurate.

[0053] Figure 3c This diagram illustrates the interaction between the sample library container and the database downtime prediction container according to an embodiment of this application. Figure 3c As shown, based on the network connectivity data of each node collected by the probe and the characteristic data of previous database crashes or switches, the probability of a database crash on that day is calculated using the Bayesian formula as follows (1):

[0054]

[0055] Wherein, P(A|B) is the probability of A occurring given that B has occurred; P(A) is the prior probability or marginal probability of A; P(B|A) is the conditional probability of B given that A has occurred, and P(B) is the prior probability or marginal probability of B.

[0056] Taking the 354 types of sample data collected by the probe as an example, such as: in the past week, there were three days of database failure. Assuming that the failure occurred as 1 and the absence of failure is 0, the result is set as variable Y = [0,0,1,0,1,0,1]. Table 1 shows the sample data of the warning log collected in the past week. As shown in Table 1, the warning levels 1-4 can correspond to different levels of logs such as ERROR, FATAL, PANIC, alert, and emerg.

[0057] Warning Level 1 Warning Level 2 Warning Level 3 Warning Level 4 on Monday no no yes no Tuesday no no yes no Wednesday yes yes no no Thursday no no no no Friday yes no no yes Saturday no no no yes Sunday yes no no no Predict today's failure rate yes no no yes

[0058] Table 1 Sample data of early warning logs collected in the past week

[0059] Based on the calculation using the Bernoulli Bayes classifier library, today's database failure result is [[0.167318090.83268191]]; the probability that the database will fail in the future (e.g., within one day) is 0.83268191; the probability that the database will not fail in the future is 0.16731809; that is, the predicted failure rate of the database in the future is 0.83268191.

[0060] Step S150: If the failure rate exceeds the preset threshold, execute the database maintenance task.

[0061] In an optional manner, step S150 further includes: detecting whether the primary-standby switchover has been completed; if the primary-standby switchover has been completed, performing a VIP switchover operation, updating the configuration information of the original primary node, detecting the primary-standby relationship, and sending a primary-standby switchover notification to the database administrator.

[0062] Specifically, the arbitration module is used to arbitrate the container through two aspects. On the one hand, it determines whether the current database is connected based on real-time multi-dimensional network connectivity data. If the multi-link judgment fails to determine connectivity, it will switch the master node and the backup node. On the other hand, it predicts the probability of database failure within a certain period of time (e.g., one day) based on the failure probability calculated by the database failure prediction container, and performs proactive maintenance.

[0063] In summary, the arbitration module performs the primary / standby switchover action through the following steps 1-8:

[0064] Step 1: Retrieve the network connectivity metrics of the current primary and backup nodes.

[0065] Step 2: Retrieve the database for the predicted failure rate for the day.

[0066] Specifically, the arbitration container pulls the current network connectivity metrics of the primary and backup nodes and the probability of database failure for the day from the TSDB. The arbitration container also pulls the current network connectivity data of the primary and backup nodes and the failure rate of the database for the day from the TSDB. It should be noted that steps 1 and 2 can be executed simultaneously or sequentially according to any given order; there is no fixed execution order.

[0067] Step 3: Simultaneously determine the connectivity of the three connections. If any one of the three connections is connected, the task ends; if none of the three connections are connected, proceed to step 5.

[0068] Simultaneously, the connection status of network connectivity data (interconnection data between two nodes of the service network card, interconnection data between two nodes of the management network card, and probe connection database detection data) determines whether to trigger the master node and backup node switching action. If all three network connectivity data are unavailable, the master node and backup node switching action is triggered.

[0069] Step 4: Determine if the predicted failure rate is greater than the preset threshold. If yes, proceed to step 5; otherwise, the task ends.

[0070] Specifically, the failure rate preset threshold can be pre-set, for example, to 0.8. In this embodiment, the execution order of steps 3 and 4 is not limited; steps 3 and 4 can be executed simultaneously or sequentially.

[0071] Step 5: The arbitration container performs a primary / standby switchover.

[0072] Specifically, the punching module switches to the backup node by sending a switching command (promoteSQL command) to the backup node.

[0073] Step 6: After the switch is completed, perform the VIP switch operation.

[0074] Specifically, the arbitration module checks whether the new master node has been successfully switched, and if so, switches the VIP.

[0075] Step 7: Update the configuration information of the original master node.

[0076] Specifically, the original primary database is synchronized as a backup database, the original primary database recovery configuration is changed as a backup database, and the original primary node configuration information is updated according to the PG_WAL command.

[0077] Step 8: Detect the primary / standby relationship and send a primary / standby switchover notification to the database administrator.

[0078] Specifically, the primary / standby relationship is re-examined, and a notification is sent to the database administrator (DBA) to inform them that a primary / standby switchover has been triggered.

[0079] The method in this embodiment uses multi-link probing of primary and backup nodes via service network cards and management network cards to avoid abnormal switching due to simple mutual ping between primary and backup nodes. It continuously monitors and predicts the probability of primary and backup node failures and automatically triggers proactive maintenance. This not only solves the problem of continuous VIP switching caused by resource pool network instability, leading to split-brain, but also predicts the probability of failures in advance based on samples of past database events and machine learning prediction results, proactively performing switching and maintenance actions on the database to avoid PG database failures. It improves the arbitration mechanism for PG database primary and backup nodes and reduces the risk of abnormal switching of primary and backup nodes due to instantaneous service network card access latency and packet loss under network fluctuation conditions.

[0080] Figure 4 A structural block diagram of a multi-dimensional database disaster recovery device according to an embodiment of this application is shown, such as... Figure 4 As shown, the device includes: a data acquisition module 410, a judgment module 420, a triggering module 430, a prediction module 440, and a processing module 450.

[0081] The acquisition module 410 is used to acquire network connectivity data, database logs, operating system kernel logs, and database events from each node in the database; the nodes include the primary node and the backup node.

[0082] In an alternative embodiment, the acquisition module 410 is further configured to: connect directly to each node via probes, send instructions to each node to enable each node to perform bidirectional service NIC detection operations and bidirectional management NIC detection operations; and acquire network connectivity data generated by each node through the execution of bidirectional service NIC detection operations and bidirectional management NIC detection operations.

[0083] In one alternative approach, network connectivity data includes: interconnection data between two nodes of the service network interface card (NIC), interconnection data between two nodes of the management NIC, and probe connection database detection data.

[0084] The judgment module 420 is used to determine whether the preset master / slave switchover conditions are met based on the network connectivity data of each node.

[0085] Trigger module 430 is used to trigger a primary / standby switchover action if the preset primary / standby switchover conditions are met.

[0086] The prediction module 440 is used to predict the failure rate of the database in the future based on the database logs of each node, the operating system kernel logs, and database events.

[0087] In an optional manner, the prediction module 440 is further configured to: process the database logs, operating system kernel logs, and database events of each node to obtain the feature data of each node, and write the feature data of each node to the time series database; extract the feature data of each node in the current time period from the time series database; and predict the failure rate of the database in future time periods based on the feature data of each node in the current time period.

[0088] In an optional manner, the prediction module 440 is further configured to: filter the database logs, operating system kernel logs, and database events of each node using preset filtering rules, and then match the database logs, operating system kernel logs, and database events with keywords to obtain processed database logs, processed operating system kernel logs, and processed database events; and for each node, use the processed database logs, processed operating system kernel logs, and processed database events of that node as feature data for that node.

[0089] In an alternative approach, the prediction module 440 is further configured to: process the feature data of each node in the current time period to obtain sample data of each node, and write the sample data of each node into the sample library; classify and statistically analyze the sample data of each node in the sample library according to the Bayesian classification algorithm, and calculate the failure rate of the database in future time periods.

[0090] The processing module 450 is used to perform database maintenance tasks if the failure rate exceeds a preset threshold.

[0091] In an optional manner, the processing module 450 is further configured to: detect whether the master-slave switchover has been completed; if the master-slave switchover has been completed, perform a VIP switchover operation, update the configuration information of the original master node, detect the master-slave relationship, and send a master-slave switchover notification to the database administrator.

[0092] The descriptions of the above modules refer to the corresponding descriptions in the method embodiments, and will not be repeated here.

[0093] According to the multi-dimensional database disaster recovery device provided in this application embodiment, network connectivity data, database logs, operating system kernel logs, and database events of each node in the database are collected. Each node includes a primary node and a backup node. Based on the network connectivity data of each node, it is determined whether a preset primary / backup switchover condition is met. If the preset primary / backup switchover condition is met, a primary / backup switchover action is triggered. Based on the database logs, operating system kernel logs, and database events of each node, the database failure rate in the future period is predicted. If the failure rate exceeds a preset threshold, a database maintenance task is executed. This invention uses multi-link detection of primary and backup node reachability via service network cards and management network cards to avoid abnormal switching due to simple mutual ping between primary and backup nodes, continuously monitors and predicts the probability of primary and backup node failures, and automatically triggers proactive maintenance.

[0094] This invention provides a non-volatile computer storage medium storing at least one executable instruction that can execute a multi-dimensional database disaster recovery method from any of the above method embodiments.

[0095] Executable instructions can specifically be used to cause the processor to perform the following operations:

[0096] Collect network connectivity data, database logs, operating system kernel logs, and database events from each node in the database; each node includes a master node and a backup node.

[0097] Based on the network connectivity data of each node, determine whether the preset primary / backup switchover conditions are met; if the preset primary / backup switchover conditions are met, then trigger the primary / backup switchover action.

[0098] Based on the database logs, operating system kernel logs, and database events of each node, predict the database failure rate in the future period;

[0099] If the failure rate exceeds a preset threshold, a database maintenance task will be executed.

[0100] Figure 5The diagram shows a structural schematic of an embodiment of the computing device of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the computing device.

[0101] like Figure 5 As shown, the computing device may include:

[0102] Processor, Communications Interface, Memory, and Communications Bus.

[0103] The processor, communication interface, and memory communicate with each other via a communication bus. The communication interface is used to communicate with other network elements, such as clients or other servers. The processor executes programs, specifically the steps described in the embodiment of the multi-dimensional database disaster recovery method.

[0104] Specifically, the program may include program code, which includes computer operation instructions.

[0105] The processor may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The server may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0106] Memory is used to store programs. Memory may include high-speed RAM, and may also include non-volatile memory, such as at least one disk drive.

[0107] Specifically, the program can be used to cause the processor to perform the following operations:

[0108] Collect network connectivity data, database logs, operating system kernel logs, and database events from each node in the database; each node includes a master node and a backup node.

[0109] Based on the network connectivity data of each node, determine whether the preset primary / backup switchover conditions are met; if the preset primary / backup switchover conditions are met, then trigger the primary / backup switchover action.

[0110] Based on the database logs, operating system kernel logs, and database events of each node, predict the database failure rate in the future period;

[0111] If the failure rate exceeds a preset threshold, a database maintenance task will be executed.

[0112] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0113] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0114] Similarly, it should be understood that, in order to simplify the invention and aid in understanding one or more of the various inventive aspects, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0115] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0116] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0117] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0118] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A multi-dimensional database disaster recovery method, characterized in that, include: The system collects network connectivity data, database logs, operating system kernel logs, and database events from each node in the database; wherein each node includes a primary node and a backup node. Based on the network connectivity data of each node, determine whether the preset primary / backup switchover conditions are met; if the preset primary / backup switchover conditions are met, then trigger the primary / backup switchover action. Based on the database logs of each node, the operating system kernel logs, and the database events, predict the failure rate of the database in the future period; If the failure rate exceeds a preset threshold, a database maintenance task will be executed. The step of predicting the database failure rate in a future period based on the database logs of each node, the operating system kernel logs, and the database events further includes: The database logs, operating system kernel logs, and database events of each node are processed to obtain the feature data of each node, and the feature data of each node is written into the time series database. Extract feature data of each node within the current time period from the time-series database; The feature data of each node in the current time period are processed to obtain sample data of each node, and the sample data of each node is written into the sample library. Based on the Bayesian classification algorithm, the sample data of each node in the sample database are classified and statistically analyzed to calculate the failure rate of the database in future time periods.

2. The method according to claim 1, characterized in that, The network connectivity data of each node in the collected database further includes: By directly connecting to each node with probes, commands are sent to each node to enable each node to perform bidirectional service network card detection operations and bidirectional management network card detection operations. Collect network connectivity data generated by each node through bidirectional service NIC detection operations and bidirectional management NIC detection operations.

3. The method according to claim 1, characterized in that, The network connectivity data includes: interconnection data between two nodes of the service network interface card, interconnection data between two nodes of the management network interface card, and probe connection database detection data.

4. The method according to claim 1, characterized in that, The process of processing the database logs, operating system kernel logs, and database events of each node to obtain the feature data of each node further includes: Using preset filtering rules, the database logs, operating system kernel logs, and database events of each node are filtered. Then, the database logs, operating system kernel logs, and database events are matched with keywords to obtain processed database logs, processed operating system kernel logs, and processed database events. For each node, the processed database logs, processed operating system kernel logs, and processed database events are used as the node's characteristic data.

5. The method according to any one of claims 1-4, characterized in that, The execution of the database maintenance task further includes: Check if the master-slave switchover is complete. If it is, perform the VIP switchover operation, update the configuration information of the original master node, check the master-slave relationship, and send a master-slave switchover notification to the database administrator.

6. A multi-dimensional database disaster recovery device, characterized in that, include: The acquisition module is used to collect network connectivity data, database logs, operating system kernel logs, and database events from various nodes in the database; wherein, the various nodes include a primary node and a backup node; The judgment module is used to determine whether the preset master-slave switchover conditions are met based on the network connectivity data of each node. The triggering module is used to trigger a primary / standby switchover action if the preset primary / standby switchover conditions are met. The prediction module is used to predict the failure rate of the database in a future period based on the database logs of each node, the operating system kernel logs, and the database events. The processing module is used to execute a database maintenance task if the failure rate exceeds a preset threshold. The prediction module is further used for: The database logs, operating system kernel logs, and database events of each node are processed to obtain the feature data of each node, and the feature data of each node is written into the time series database. Extract feature data of each node within the current time period from the time-series database; The feature data of each node in the current time period are processed to obtain sample data of each node, and the sample data of each node is written into the sample library. Based on the Bayesian classification algorithm, the sample data of each node in the sample database are classified and statistically analyzed to calculate the failure rate of the database in future time periods.

7. A computing device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform an operation corresponding to the multi-dimensional database disaster recovery method as described in any one of claims 1-5.

8. A computer storage medium, characterized in that, The storage medium stores at least one executable instruction, which causes the processor to perform the operation corresponding to the multi-dimensional database disaster recovery method as described in any one of claims 1-5.

Images