Database Fault Handling Method and Device

Abstract

The present invention discloses a method and apparatus for database fault handling. The database fault handling method includes: when it is detected that a target standby database fails, obtaining a server address identifier corresponding to the target standby database; determining an upstream node address identifier and a downstream node address identifier corresponding to the target standby database according to the server address identifier; detecting whether the upstream service database corresponding to the upstream node address identifier is normal and detecting whether the downstream service database corresponding to the downstream node address identifier is normal; if both the upstream service database and the downstream service database are normal, performing a link restoration configuration operation on the upstream service database and the downstream service database. Thus, when the target standby database fails, the link is automatically restored according to the connectivity of the upstream service database and the downstream service database, ensuring the normal operation of the entire link and avoiding the inability to perform data backup transmission to the downstream due to the interruption of the intermediate standby database.

Description

Technical Field

[0001] The present invention relates to the field of network technology, and in particular to a database fault processing method and device. Background Art

[0002] In order to ensure the disaster recovery capability of the business system, most companies usually adopt the architecture of multi-location disaster recovery deployment services. That is, for a set of databases, there will be several backup databases in the local, same-city and remote locations. This ensures the possibility of rapid failover and recovery of business services when a database fails or a disaster occurs in a city. In addition, all business read and write operations are concentrated in the local master database, which will cause excessive pressure on the master database and waste a lot of resources in the disaster recovery database. Therefore, some read operations can be placed on the same-city and remote disaster recovery databases. This requires that when the link of a set of databases is interrupted, the synchronization link needs to be restored as soon as possible to ensure the normal operation of the entire link, and all downstream data transmission services will not be impossible due to interruptions in the middle.

[0003] In the related art, when using a MySQL database, in the event of a local backup database or a backup database in the same city failing, the database administrator needs to manually modify the synchronization relationship of the downstream database, verify the data consistency between the primary and backup databases, remove the faulty database from the architecture, and establish a new topology architecture, resulting in low operating efficiency. Summary of the invention

[0004] The present invention aims to solve one of the technical problems in the related art at least to a certain extent.

[0005] To this end, an object of the present invention is to propose a database failure processing method to automatically restore the link according to the connectivity between the upstream business database and the downstream business database when the target standby database fails, thereby ensuring the normal effect of the entire link.

[0006] The second objective of the present invention is to provide a database fault processing device.

[0007] A third object of the present invention is to provide a computer device.

[0008] A fourth object of the present invention is to provide a non-transitory computer-readable storage medium.

[0009] To achieve the above object, a first aspect of the present invention provides a method for handling database failures, including:

[0010] When a target standby database fails, obtaining a server address identifier corresponding to the target standby database;

[0011] Determine the upstream node address identifier and the downstream node address identifier corresponding to the target standby database according to the server address identifier;

[0012] Detect whether the upstream business database corresponding to the upstream node address identifier is normal, and detect whether the downstream business database corresponding to the downstream node address identifier is normal;

[0013] If both the upstream business database and the downstream business database are normal, perform a link recovery configuration operation on the upstream business database and the downstream business database.

[0014] To achieve the above object, an embodiment of the second aspect of the present invention provides a database failure handling device, including:

[0015] An acquisition module, configured to detect a failure of a target standby database and acquire a server address identifier corresponding to the target standby database;

[0016] A determination module, configured to determine an upstream node address identifier and a downstream node address identifier corresponding to the target standby database according to the server address identifier; a detection module, configured to detect whether the upstream business database corresponding to the upstream node address identifier is normal, and detect whether the downstream business database corresponding to the downstream node address identifier is normal; a repair module, configured to perform a link recovery configuration operation on the upstream business database and the downstream business database when both the upstream business database and the downstream business database are normal.

[0017] To achieve the above object, an embodiment of the third aspect of the present invention provides a computer device, including: a processor; a memory for storing executable instructions of the processor; wherein, the processor is configured to implement the database failure handling method as described in the foregoing method embodiment.

[0018] To achieve the above object, an embodiment of the fourth aspect of the present invention provides a non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of a computer device, enabling the computer device to execute a database failure handling method.

[0019] The technical solution provided by the embodiment of the present invention may include the following beneficial effects:

[0020] When a failure of the target standby database is detected, obtain the server address identifier corresponding to the target standby database. Furthermore, based on the server address identifier, determine the upstream node address identifier and the downstream node address identifier corresponding to the target standby database. Finally, detect whether the upstream business database corresponding to the upstream node address identifier is normal, and detect whether the downstream business database corresponding to the downstream node address identifier is normal. If both the upstream business database and the downstream business database are normal, perform a link recovery configuration operation on the upstream business database and the downstream business database. Thus, when the target standby database fails, the link is automatically restored according to the connectivity of the upstream business database and the downstream business database, ensuring the normal operation of the entire link and avoiding the inability to transmit data downstream due to the interruption of the intermediate standby database.

[0021] Additional aspects and advantages of the present invention will be given in part in the following description, become apparent in part from the following description, or be understood through the practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The above and / or additional aspects and advantages of the present invention will become apparent and be readily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0023] Figure 1 is a schematic flowchart of a method for processing database failures provided by an embodiment of the present invention;

[0024] Figure 2 is a schematic flowchart of a method for detecting a failure of a target standby database provided by an embodiment of the present invention;

[0025] Figure 3 is a schematic flowchart of a method for detecting whether an upstream business database and a downstream business database fail provided by an embodiment of the present invention;

[0026] Figure 4 is a flowchart of a method for data synchronization repair of a target standby database provided by an embodiment of the present invention;

[0027] Figure 5 is a flowchart of another method for data synchronization repair of a target standby database provided by an embodiment of the present invention; and

[0028] Figure 6 is a schematic structural diagram of a database failure processing device provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0029] Embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to explain the present invention, and should not be construed as limiting the present invention.

[0030] The following describes a database failure handling method and apparatus according to an embodiment of the present invention with reference to the accompanying drawings.

[0031] Figure 1 It is a schematic flowchart of a database failure handling method provided by an embodiment of the present invention.

[0032] In view of the technical problems mentioned in the above technical background, when a database failure occurs, the link is interrupted, which takes a long time and manual operations are prone to errors, and there is also a certain waste of human resources. Embodiments of the present invention provide a database failure handling method to achieve the functions of actively detecting and repairing database data and actively restoring the upstream and downstream links in real time when a target standby database fails, as Figure 1 shown, the method includes the following steps:

[0033] Step 101, detecting that a target standby database fails, and obtaining a server address identifier corresponding to the target standby database;

[0034] Among them, the failure of the target standby database can be understood as any one of different types of target standby database failures caused by various reasons, including but not limited to network failures, data loss, data overflow, etc.

[0035] In this embodiment, each target standby database is in an uninterrupted monitoring state. When it is detected that any target standby database fails, the corresponding address identifier can be obtained by applying to the target standby database server, or the corresponding server address identifier can be obtained by querying the server address identifier list corresponding to the target standby database.

[0036] It should be noted that there may be many kinds of failure problems of the target standby database, and the methods for detecting that the target standby database fails are also different. The following explains with examples. The examples are as follows:

[0037] Example 1:

[0038] In this example, as Figure 2 shown, the corresponding data in the primary database and the target standby database are extracted and compared respectively.

[0039] Step 201, obtaining first target data carrying a data identifier that the primary database is about to transmit to the target standby database, and generating a first code according to the target data;

[0040] Among them, the first target data can be understood as specified data or data segments, or can also be understood as specified program function segments, etc. The data identifier can be understood as an identifier that uniquely corresponds to the first target data, such as the address, serial number, or name of the exclusive data or function of the first target data. In addition, the first encoding can be understood as the encoded data that is uniquely corresponding to the first data and generated after the first target data undergoes encryption, transformation, or mapping. The first encoding can also obtain the first target data through reverse operation.

[0041] In this embodiment, during the communication between the primary database and the target standby database, the first target data carrying the data identifier that the primary database is about to transmit to the target standby database is collected and obtained in real time or at a specified period, and then the corresponding first encoding is generated using the first target data according to the specified processing rules.

[0042] Step 202, obtain the second target data from the target standby database according to the data identifier, and generate the second encoding according to the second target data;

[0043] In this embodiment, according to the first target data or the first encoding, the data identifier of the first target data is parsed, and the corresponding second target data is applied from the target standby database according to the data identifier, and the second target data corresponding to the data identifier is obtained. The corresponding second encoding is generated using the second target data according to the specified processing rules. Among them, the processing rules used to generate the second encoding and the processing rules used to generate the first encoding can be the same or different.

[0044] Step 203, calculate the first encoding and the second encoding according to a preset algorithm. If the calculation result is a preset first identifier, it is determined that the failure of the target standby database is an application failure. If the calculation result is a preset second identifier, it is determined that the failure of the target standby database is a server failure.

[0045] Among them, the preset algorithm can be understood as a pre-trained neural network model. The input data of this neural network model is the first encoding and the second encoding, and the output data is a calculation result that can judge the failure type of the target standby database. In addition, the application failure can be understood as the operation failure of the data, program, or algorithm process stored in the server. This preset algorithm can also be a digital logic algorithm such as exclusive OR, etc.

[0046] In this embodiment, the first encoding and the second encoding are calculated according to a preset algorithm to obtain a calculation result. The calculation result is used to match with a preset first identifier and a preset second identifier. If the calculation result matches the first identifier successfully, it is determined that the target standby database failure is an application failure. If the calculation result matches the second identifier successfully, it is determined that the target standby database failure is a server failure. Wherein, the first identifier and the second identifier are respectively used to indicate the application failure and the server failure of the target standby database. The specific contents of the first identifier and the second identifier are related to the preset algorithm. For example, when the preset algorithm is digital logic operation, the first identifier can be "001" and the second identifier can be "010", etc.

[0047] Example 2:

[0048] In this example, the system sends a first test data to all target standby databases according to a specified period, and then obtains the second test data returned by each database based on the first test data, and compares the second test data and the first test data of each database to determine whether there is a database failure and the type of the failure.

[0049] In this example, the system sends the first test data to each database according to a preset period, and then within a specified time, obtains the second test data corresponding to the first test data received by each database after feedback. Among them, the second test data corresponding to the first test data can be determined based on the timestamp or signature of the first test data, etc. If there is a target standby database that does not send the second test data within the specified time, it is determined that the target standby database has a server failure. If the second test data sent back by a target standby database is different from the first test data and different from the second test data sent back by the primary database, it is determined that the target standby database has an application failure.

[0050] Step 102, determine the upstream node address identifier and the downstream node address identifier corresponding to the target standby database according to the server address identifier;

[0051] In some possible examples, the sequence numbers of all node identifiers in the service chain can be pre-saved. When the server address identifier is obtained, the previous sequence number and the next sequence number are determined according to the sequence number of the server identifier, and the corresponding upstream node address identifier and downstream node address identifier are determined according to the previous sequence number and the next sequence number.

[0052] In some other possible examples, a network topology map is constructed based on the new business communication relationships between nodes. The nodes in the network topology map are connected based on business relationships to form a network topology. Among them, the nodes in the network topology map can be represented in the form of node address identifiers, or other unique information such as node codes that uniquely identify the nodes.

[0053] In this embodiment, according to the server address identifier of the target standby database that has failed, query the preset network topology map to obtain the information of the unique identifier nodes of the upstream node and the downstream node corresponding to the target standby database that has failed. If the information of the unique identifier node is in the form of a node address identifier, the corresponding upstream node address identifier and downstream node address identifier can be directly obtained. If it is in other forms of node address identifiers, the corresponding relationship between the preset constructed information of the unique identifier nodes and the node address identifiers can be queried to obtain the address identifiers of the upstream node address identifier and the downstream node address identifier. Among them, the upstream node address identifier and the downstream node address identifier in this embodiment can correspond to the physical address of the node, etc.

[0054] In this embodiment, multiple nodes are connected to form a service chain to jointly back up service data. During the actual backup process, each downstream node backs up the service data of its upstream node. When the service data of the upstream node is backed up to the downstream node, even if the upstream node fails, since the downstream node stores the service data of the upstream node, it can provide relevant services on behalf of the upstream node, etc. Step 103: Detect whether the corresponding upstream service database is normal according to the upstream node address identifier, and detect whether the corresponding downstream service database is normal according to the downstream node address identifier;

[0055] As mentioned above, the upstream node address identifier and the downstream node address identifier in this embodiment can correspond to the physical address of the node. Therefore, in this embodiment, detecting whether the corresponding upstream service database is normal according to the upstream node address identifier and detecting whether the corresponding downstream service database is normal according to the downstream node address identifier, it is easy to understand that the failure of the current target standby database may be its own failure, or it may be caused by the failure of the upstream and downstream nodes. Therefore, it is necessary to detect whether the corresponding upstream service database is normal based on the upstream node address identifier to locate whether there is a failure in the backup database.

[0056] It should be noted that in different application scenarios, the methods for detecting whether the upstream service database and the downstream service database have failed are different. The following examples illustrate, the examples are as follows:

[0057] Example 1:

[0058] Such as Figure 3As shown, in this example, it is detected whether the upstream and downstream business databases are working properly through a preset monitoring page. Among them, the monitoring page can be understood as the front-end representation of the monitoring program.

[0059] Step 301: Obtain the upstream server corresponding to the upstream node address identifier and obtain the downstream server corresponding to the downstream node address identifier.

[0060] Step 302: Query the preset business link topology, obtain the upstream business database corresponding to the standby business database on the upstream server, and obtain the downstream business database corresponding to the standby business database on the downstream server.

[0061] In this embodiment, according to the upstream node address identifier and the downstream node address identifier corresponding to the target standby database of the current node with a fault, the upstream server corresponding to the upstream node address identifier and the downstream server corresponding to the downstream node address identifier are obtained. Since the business support of the server requires business interaction with the database, the preset business link topology is queried to obtain the upstream business database corresponding to the standby business database with a fault on the upstream server and the downstream business database corresponding to the standby business database with a fault on the downstream server.

[0062] Step 303: Detect the running status of the upstream business database according to the preset first monitoring page and detect the running status of the downstream business database according to the preset second monitoring page.

[0063] Among them, the front-end display of the monitoring page may include multiple display modules for displaying the running status of the upstream business database and the downstream business database. Among them, each module is used to display different running statuses. In addition, the data of the running status of each database in the system can be displayed on such a page, including the above-mentioned target standby database with a fault.

[0064] In this embodiment, a monitoring program for monitoring the upstream business database is preset, and a first monitoring page corresponding to the detection program is set. Through the first monitoring page corresponding to the upstream business database, it is detected whether the running status of the upstream business database is normal. Among them, the detection program corresponding to the first monitoring page is used to monitor different function functions of the upstream business database. In specific monitoring, it can be implemented based on the setting of hook functions, etc. The first monitoring page is used to display the detection results of the detection program. The first monitoring page is used to display whether the running statuses of the first monitoring page corresponding to the detection program are normal, etc.

[0065] Meanwhile, through the second monitoring page corresponding to the downstream service database, detect whether the operation status of the downstream service database is normal. It can be understood that if the operation status of the upstream and downstream service databases is normal, it indicates that the failure of the current backup database is mainly its own failure, and there is no need to repair the upstream and downstream service databases. Just keep detecting until the faulty target standby database is repaired; if the operation status of the upstream and downstream service databases is abnormal, the management personnel can be reminded to intervene by sending text messages, sounding alarms or page jittering, etc.

[0066] Example 2:

[0067] In this example, after the target standby database of the current node fails, the corresponding server will send a failure alarm to the upstream server and the downstream server. After receiving the failure alarm, the upstream server and the downstream server will start to actively monitor the operation status of each corresponding service database. During this period, if it is detected that the service database corresponding to the upstream server or the downstream server fails, the management personnel can be reminded to intervene by sending text messages, sounding alarms or page jittering, etc.; if it is detected that the service databases corresponding to the upstream server and the downstream server are operating normally, keep monitoring until receiving the information that the corresponding server of the target standby database of the current node has resumed normal operation, and then stop monitoring.

[0068] Step 104, if both the upstream service database and the downstream service database are normal, perform a link recovery configuration operation on the upstream service database and the downstream service database.

[0069] In this embodiment, when it is detected that both the upstream service database and the downstream service database are normal, data synchronization repair is performed on the target standby database that has failed at the current node. Moreover, the failure of the target standby database will inevitably lead to the failure of the service link. Therefore, after performing data synchronization repair on the target standby database, link recovery is performed on the upstream service database, the target standby database, and the downstream service database.

[0070] It should be noted that in different application scenarios, there are different methods for performing link recovery configuration operations on the upstream service database and the downstream service database. The following examples illustrate, as follows:

[0071] Example 1:

[0072] As Figure 4 shown, in this example, the data of the target standby database is restored using the data of the primary database.

[0073] Step 401, obtain the fault time period of the target standby database;

[0074] It should be understood that operation logs are generated when the server and the database complete any operation. The operation logs record the operation time, operation object, operation method, etc. of any operation. Among them, the fault time period of the target standby database can be understood as the time period after the target standby database is found to have a fault through the operation logs, or the time period when the information received, processed, and sent by the target standby database does not meet the format requirements.

[0075] In an embodiment of the present invention, the time period when the target standby database fails is obtained by retrieving the content of the operation logs.

[0076] Step 402, send a secondary synchronization instruction carrying the fault time period to the primary database corresponding to the target standby database;

[0077] Step 403, obtain the information corresponding to the fault time period sent by the primary database, and perform data synchronization repair on the target standby database according to the information.

[0078] Among them, the secondary synchronization instruction can be understood as a type of instruction sent by the target standby database to the primary database. This instruction carries information such as the address of the target standby database, the time period of the fault, and the data identifier. After receiving this type of instruction, the primary database will retrieve the corresponding data according to the time period of the fault and the data identifier, and send the data to the target standby database corresponding to the address identifier carried in the secondary synchronization instruction.

[0079] In this embodiment, the target standby database sends a secondary synchronization instruction carrying information such as the fault time period to the corresponding primary database. After receiving the secondary synchronization instruction, the corresponding primary database determines the data that needs to be sent to the target standby database according to the various information carried in it and sends it. After receiving the sent data, the target standby database repairs the data that needs to be repaired.

[0080] Of course, the above embodiments are based on the premise that the primary database corresponding to the target standby database does not fail. In some possible examples, when the primary database corresponding to the target standby database fails, the target standby database can also be restored based on the data logs of the upstream service database and the downstream service database. For example, if it is found from the data log of the upstream service database that the data sent to the target standby database during the fault time period, the data can also be resent to the target standby database, etc.

[0081] Example 2:

[0082] Such as Figure 5As shown, in this example, the data of the malfunctioning target standby database is repaired using the data of the upstream business data that is working properly.

[0083] Step 501, obtain the upstream business data of the upstream business database;

[0084] It should be understood that the target standby database performs backup processing based on the business data obtained from the upstream business database. Therefore, in order to determine whether the server corresponding to the target standby database has successfully received data from the upstream business database, the upstream business data of the upstream business database is obtained, and the upstream business data includes the data sent from the upstream business database to the node corresponding to the target standby database.

[0085] Step 502, compare the upstream business data with the business data of the target standby database;

[0086] It should be understood that the standby data backs up the data sent by the upstream business data to the current node. Therefore, whether the business link between the upstream business data and the node corresponding to the target standby database is normal can be known by comparing the upstream business data with the business data of the target standby database.

[0087] Step 503, if the comparison result is inconsistent, clear the downstream business data and copy the upstream business data.

[0088] Step 504, connect the upstream business database and the downstream business database according to the upstream node address identifier and the downstream node address identifier.

[0089] In this embodiment, if the comparison result is inconsistent, it indicates that the backup link between the upstream business data and the node corresponding to the target standby database is abnormal. Then, this abnormality will inevitably affect the backup of data from the node corresponding to the target standby database to the downstream business database. Therefore, when the comparison result is inconsistent, the business data of the target standby database and the downstream business database is re-backed up according to the upstream business data.

[0090] In some possible examples, the upstream business data is re-obtained. Since the corresponding upstream business data needs to be sent to the target standby database for backup, at this time, the upstream business data is copied and the downstream business data is cleared. Since the downstream node will back up the data of the upstream node, after clearing the downstream business data, the downstream node re-backs up the data of the upstream node, realizing link recovery.

[0091] In this embodiment, the upstream service database and the downstream service data path are connected according to the upstream node address identifier and the downstream node address identifier. Therefore, it is possible to trigger the upstream service data to be resent from the upstream node to the corresponding downstream node, realizing the restoration of the data backup link. Obviously, even if the target service database in the middle fails, data backup can be quickly performed.

[0092] Thus, when the server address identifier contains both the corresponding upstream node address identifier and the corresponding downstream node address identifier, that is, when the target database corresponding to the server address identifier is not the first node or the last node in the link, but an intermediate node with an upstream node and a downstream node, the database fault handling method of the embodiments of the present disclosure can connect the upstream service database and the downstream service data path according to the upstream node address identifier and the downstream node address identifier, and in the case of an intermediate node failure, it is also possible to back up data from the upstream node to the downstream node.

[0093] In an embodiment of the present disclosure, when the server address identifier only contains the upstream node address identifier and does not contain the downstream node address identifier, that is, when the failed node is the last node in the service link, since other upstream nodes have backed up the relevant data, the relevant services of the last node can be transferred to any one of the other upstream nodes for execution.

[0094] In an embodiment of the present disclosure, when the server address identifier only contains the downstream node address identifier and does not contain the upstream node address identifier, that is, when the failed node is the first node in the service link, since other downstream nodes have backed up the relevant data, the relevant services of the first node can be transferred to any one of the other downstream nodes for execution.

[0095] In summary, according to the database fault handling method of the embodiments of the present disclosure, when it is detected that the target standby database fails, the server address identifier corresponding to the target standby database is obtained. Furthermore, according to the server address identifier, the upstream node address identifier and the downstream node address identifier corresponding to the target standby database are determined. Finally, it is detected whether the upstream service database corresponding to the upstream node address identifier is normal, and whether the downstream service database corresponding to the downstream node address identifier is normal. If both the upstream service database and the downstream service database are normal, a link restoration configuration operation is performed on the upstream service database and the downstream service database. Thus, when the target standby database fails, the link is automatically restored according to the connectivity of the upstream service database and the downstream service database, ensuring the normal operation of the entire link and avoiding the inability to perform data backup transmission to the downstream due to the interruption of the intermediate standby database.

[0096] To implement the above embodiments, the present invention also proposes a database fault handling device.

[0097] Figure 6 This is a schematic structural diagram of a database fault handling device provided by an embodiment of the present invention.

[0098] As Figure 5 shown, the database fault handling device includes: an acquisition module 601, a determination module 602, a detection module 603, and a repair module 604.

[0099] Among them, the acquisition module 601 is used to detect a fault in the target standby database and acquire the server address identifier corresponding to the target standby database;

[0100] The determination module 602 is used to determine the upstream node address identifier and the downstream node address identifier corresponding to the target standby database according to the server address identifier;

[0101] The detection module 603 is used to detect whether the upstream service database corresponding to the upstream node address identifier is normal and detect whether the downstream service database corresponding to the downstream node address identifier is normal;

[0102] The repair module 604 is used to perform a link recovery configuration operation on the upstream service database and the downstream service database when both the upstream service database and the downstream service database are normal.

[0103] In an embodiment of the present invention, the acquisition module 601 is specifically used for:

[0104] Acquire the first target data carrying a data identifier that the primary database is about to transmit to the target standby database, and generate a first code according to the target data;

[0105] Acquire second target data from the target standby database according to the data identifier, and generate a second code according to the second target data;

[0106] Calculate the first code and the second code according to a preset algorithm. If the calculation result is a preset first identifier, it is determined that the target standby database fault is an application fault. If the calculation result is a preset second identifier, it is determined that the target standby database fault is a server fault.

[0107] In an embodiment of the present invention, the detection module 603 is specifically used for:

[0108] Acquire the upstream server corresponding to the upstream node address identifier and acquire the downstream server corresponding to the downstream node address identifier;

[0109] Query the preset service link topology, obtain the upstream service database corresponding to the standby service database on the upstream server, and obtain the downstream service database corresponding to the standby service database on the downstream server;

[0110] Detect the running status of the upstream service database according to the preset first monitoring page, and

[0111] Detect the running status of the downstream service database according to the preset second monitoring page.

[0112] In one embodiment of the present invention, the repair module 604 is specifically configured to:

[0113] Obtain the upstream service data of the upstream service database;

[0114] Compare the upstream service data with the downstream service data of the downstream service database;

[0115] If the comparison result is inconsistent, clear the downstream service data and copy the upstream service data;

[0116] Connect the upstream service database and the downstream service database according to the upstream node address identifier and the downstream node address identifier.

[0117] In one embodiment of the present invention, the repair module 604 is specifically configured to:

[0118] Obtain the fault time period of the target standby database;

[0119] Send a secondary synchronization instruction carrying the fault time period to the primary database corresponding to the target standby database;

[0120] Obtain the information corresponding to the fault time period sent by the primary database, and perform data synchronization repair on the target standby database according to the information.

[0121] It should be noted that the foregoing explanation of the embodiments of the database fault handling method also applies to the database fault handling device of this embodiment, and will not be repeated here.

[0122] In summary, according to the database failure handling device of the embodiments of the present disclosure, when a failure of a target standby database is detected, the server address identifier corresponding to the target standby database is obtained. Furthermore, according to the server address identifier, the upstream node address identifier and the downstream node address identifier corresponding to the target standby database are determined. Finally, it is detected whether the upstream service database corresponding to the upstream node address identifier is normal and whether the downstream service database corresponding to the downstream node address identifier is normal. If both the upstream service database and the downstream service database are normal, a link recovery configuration operation is performed on the upstream service database and the downstream service database. Thus, when a failure occurs in the target standby database, the link is automatically restored according to the connectivity of the upstream service database and the downstream service database, ensuring the normal operation of the entire link and avoiding the inability to perform data backup transmission to the downstream due to the interruption of the intermediate standby database.

[0123] To implement the above embodiments, the present invention also provides a computer device, including: a processor, and a memory for storing executable instructions of the processor.

[0124] Wherein, the processor is configured to implement the above database failure handling method.

[0125] To implement the above embodiments, the present invention also provides a non-transitory computer-readable storage medium. When the instructions in the storage medium are executed by the processor of the computer device, the computer device can execute a database failure handling method.

[0126] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc. indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus should not be construed as a limitation of the present invention.

[0127] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of the present invention, "a plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0128] In the present invention, unless otherwise clearly defined or limited, terms such as "installed", "connected", "joined", "fixed", etc. shall be understood in a broad sense. For example, it may be a fixed connection, a detachable connection, or integrated; it may be a mechanical connection or an electrical connection; it may be directly connected or indirectly connected through an intermediate medium, and it may be the communication inside two components or the interaction relationship between two components, unless otherwise clearly defined. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0129] In the present invention, unless otherwise clearly defined or limited, the first feature being "on" or "under" the second feature may be that the first and second features are in direct contact, or the first and second features are indirectly in contact through an intermediate medium. Moreover, the first feature being "above", "over" and "on top of" the second feature may be that the first feature is directly above or obliquely above the second feature, or merely indicates that the first feature has a higher horizontal height than the second feature. The first feature being "under", "below" and "beneath" the second feature may be that the first feature is directly below or obliquely below the second feature, or merely indicates that the first feature has a lower horizontal height than the second feature.

[0130] In the description of this specification, the descriptions with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic descriptions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0131] Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for processing database failures, characterized in that, Including the following steps: When a failure of the target standby database is detected, obtain the server address identifier corresponding to the target standby database; According to the server address identifier, determine the upstream node address identifier and the downstream node address identifier corresponding to the target standby database; Detect whether the upstream business database corresponding to the upstream node address identifier is normal, and detect whether the downstream business database corresponding to the downstream node address identifier is normal; If both the upstream business database and the downstream business database are normal, perform a link recovery configuration operation on the upstream business database and the downstream business database; The detection of the failure of the target standby database includes: Obtain the first target data carrying the data identifier that the primary database is about to transmit to the target standby database, and generate a first code according to the target data; Obtain the second target data from the target standby database according to the data identifier, and generate a second code according to the second target data; Calculate the first code and the second code according to a preset algorithm. If the calculation result is a preset first identifier, determine that the failure of the target standby database is an application failure. If the calculation result is a preset second identifier, determine that the failure of the target standby database is a server failure.

2. The method according to claim 1, characterized in that, The detection of whether the upstream business database corresponding to the upstream node address identifier is normal and the detection of whether the downstream business database corresponding to the downstream node address identifier is normal include: Obtain the upstream server corresponding to the upstream node address identifier, and obtain the downstream server corresponding to the downstream node address identifier; Query the preset service link topology, obtain the upstream business database corresponding to the target standby database on the upstream server, and obtain the downstream business database corresponding to the target standby database on the downstream server; Detect the running state of the upstream business database according to a preset first monitoring page, and Detect the running state of the downstream business database according to a preset second monitoring page.

3. The method according to claim 1, characterized in that, Performing a link recovery configuration operation on the upstream business database and the downstream business database includes: Obtain the upstream business data of the upstream business database; Compare the upstream business data with the downstream business data of the downstream business database; If the comparison result is inconsistent, clear the downstream business data and copy the upstream business data; Connect the upstream business database and the downstream business database according to the upstream node address identifier and the downstream node address identifier.

4. The method according to claim 1, characterized in that, After performing the link recovery configuration operation on the upstream business database and the downstream business database, it further includes: Obtain the failure time period of the target standby database; Send a secondary synchronization instruction carrying the failure time period to the primary database corresponding to the target standby database; Obtain the information corresponding to the failure time period sent by the primary database, and perform data synchronization repair on the target standby database according to the information.

5. A device for processing database failures, characterized in that, Including: An acquisition module, configured to detect a failure of a target standby database and acquire a server address identifier corresponding to the target standby database; A determination module, configured to determine an upstream node address identifier and a downstream node address identifier corresponding to the target standby database according to the server address identifier; A detection module, configured to detect whether an upstream business database corresponding to the upstream node address identifier is normal and detect whether a downstream business database corresponding to the downstream node address identifier is normal; A repair module, configured to perform a link restoration configuration operation on the upstream business database and the downstream business database when both the upstream business database and the downstream business database are normal; The acquisition module is specifically configured to: Acquire first target data carrying a data identifier that the primary database is about to transmit to the target standby database, and generate a first code according to the target data; Acquire second target data from the target standby database according to the data identifier, and generate a second code according to the second target data; Calculate the first code and the second code according to a preset algorithm. If the calculation result is a preset first identifier, it is determined that the failure of the target standby database is an application failure. If the calculation result is a preset second identifier, it is determined that the failure of the target standby database is a server failure.

6. The device according to claim 5, characterized in that, The detection module is specifically configured to: Acquire an upstream server corresponding to the upstream node address identifier and acquire a downstream server corresponding to the downstream node address identifier; Query a preset service link topology, acquire an upstream business database corresponding to the target standby database on the upstream server, and acquire a downstream business database corresponding to the target standby database on the downstream server; Detect the running status of the upstream business database according to a preset first monitoring page, and Detect the running status of the downstream business database according to a preset second monitoring page.

7. The device according to claim 5, wherein, The repair module is specifically configured to: Acquire upstream business data of the upstream business database; Compare the upstream business data with downstream business data of the downstream business database; If the comparison result is inconsistent, clear the downstream business data and copy the upstream business data; Connect the upstream business database and the downstream business database according to the upstream node address identifier and the downstream node address identifier.

8. The device according to claim 5, wherein, The repair module is further configured to: Acquire a failure time period of the target standby database; Send a secondary synchronization instruction carrying the failure time period to the primary database corresponding to the target standby database; Acquire information corresponding to the failure time period sent by the primary database, and perform data synchronization repair on the target standby database according to the information.

9. A computer device, wherein, It includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the database failure handling method according to any one of claims 1-4.

10. A non - transitory computer - readable storage medium, on which a computer program is stored, wherein, When the computer program is executed by the processor, it implements the database failure handling method according to any one of claims 1-4.

Images