Database host downtime fault handling method, device, electronic equipment and medium

Abstract

The embodiment of the present invention provides a method, device, electronic device and medium for handling a database host downtime, the method comprising: when it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold, obtaining a global transaction ID from a slave database that has a master-slave relationship with the target master database; determining a fault handling strategy based on the proportion of the number of slave databases that have obtained the global transaction ID; and handling the host downtime of the target master database based on the fault handling strategy. Thus, the host is reselected within the plan through the fault handling strategy, ensuring high system availability and data consistency, and improving fault repair efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of data storage, and in particular to a method for handling a database host downtime fault, a device for handling a database host downtime fault, an electronic device, and a computer-readable medium. Background Art

[0002] During the operation of the database, internal transaction failures, system failures, media failures, computer virus failures, such as power outages, disk damage, memory overflow, etc., may occur, resulting in the database being unavailable. Therefore, fault recovery is required, and the basic principle of recovery is to use redundant data stored elsewhere to rebuild the data in the database. The database can be viewed separately from the standby machine and the host machine. Because the business does not directly write to the standby machine, and the standby machine only provides queries, multiple sets of standby machines are deployed, and LVS (Linux Virtual Server) is used to make a cluster. When a database fails, the faulty standby machine can be automatically kicked out. However, due to the existence of concurrency, only one server can be used as the host at the same time. When the host goes down, a standby machine can be selected to be promoted to the host, but the data of the standby machine and the host are usually inconsistent. Summary of the invention

[0003] The embodiment of the present invention provides a database host downtime fault handling method, device, electronic device and readable medium to solve the problem that the existing database host downtime cannot quickly repair the fault and ensure system high availability and data consistency.

[0004] The embodiment of the present invention discloses a method for handling a database host downtime fault, which is characterized by comprising:

[0005] When it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold, a global transaction ID is obtained from a slave database that has a master-slave relationship with the target master database;

[0006] Determine the fault handling strategy based on the proportion of slave databases that have obtained the global transaction ID;

[0007] The host failure of the target primary database is handled based on the failure handling strategy.

[0008] In a possible implementation, the method further includes:

[0009] Calculate the ratio of the number of first slave databases that have obtained the global transaction ID to the total number of slave databases;

[0010] When the ratio is greater than or equal to a preset ratio threshold, determining that the fault handling strategy is to determine a new master database based on the priority and data volume of the slave database;

[0011] When the ratio is less than a preset ratio threshold, it is determined that the fault handling strategy is to stop switching databases.

[0012] In a possible implementation, the method further includes:

[0013] Setting a priority for each slave database in advance according to the distance from the target master database;

[0014] Get all the corresponding data from the database;

[0015] Determine whether the data volume of the slave database with the highest priority is the largest;

[0016] If so, the slave database with the highest priority and the largest amount of data is determined as the new master database;

[0017] If not, data synchronization is performed on the slave database with the highest priority based on the slave database with the largest data volume, and the slave database with the highest priority after the data synchronization is determined as the new master database.

[0018] In a possible implementation, the method further includes:

[0019] If it is determined that the fault handling strategy is to stop switching the database, an alarm message is generated and the instance state of the target primary database is set to be under maintenance.

[0020] In a possible implementation, the method further includes:

[0021] After determining the new primary database, set the data replication permission of the new primary database and bind the floating IP to the host of the new primary database;

[0022] The other slave databases are communicatively connected to the new master database.

[0023] In a possible implementation, the method further includes:

[0024] Repair the downtime host of the target master database and delete the target master database node in the database cluster;

[0025] After the downtime host of the target master database is repaired, a data consistency check and update is performed;

[0026] After the data consistency check is updated, the downtime host that has been repaired is rejoined to the database cluster as a slave database.

[0027] In a possible implementation, the method further includes:

[0028] When the global transaction ID of a slave database cannot be obtained after a preset time, it is determined that the corresponding slave database is unavailable, and the unavailable slave database node is deleted from the database cluster.

[0029] The embodiment of the present invention also discloses a database host downtime fault processing device, which may specifically include the following modules:

[0030] An acquisition module is used to acquire a global transaction ID from a slave database that has a master-slave relationship with the target master database when it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold;

[0031] A determination module, used to determine a fault handling strategy based on the proportion of slave databases that have obtained global transaction IDs;

[0032] A processing module is used to perform fault processing on the host crash of the target primary database based on the fault processing strategy.

[0033] The embodiment of the present invention further discloses an electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0034] The memory is used to store computer programs;

[0035] The processor is used to implement the database host crash fault handling method as described in the embodiment of the present invention when executing the program stored in the memory.

[0036] The embodiment of the present invention further discloses one or more computer-readable media on which instructions are stored, and when executed by one or more processors, the processors execute the database host downtime fault handling method as described in the embodiment of the present invention.

[0037] The embodiments of the present invention include the following advantages:

[0038] The fault handling solution for database host downtime provided by the embodiment of the present invention is to obtain the global transaction ID from the slave database that has a master-slave relationship with the target master database when it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold; determine the fault handling strategy based on the proportion of the number of slave databases that obtain the global transaction ID; and perform fault handling on the host downtime of the target master database based on the fault handling strategy. Compared with the existing method of selecting a backup machine to be promoted to the main machine when the main machine goes down, but the data of the backup machine and the main machine are usually inconsistent, resulting in the problem of being unable to quickly repair the fault and ensure high system availability and data consistency, this solution reselects the host within the plan through the fault handling strategy to ensure high system availability and data consistency, and improve fault repair efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 It is a flowchart of the steps of a method for handling a database host downtime provided in an embodiment of the present invention;

[0040] Figure 2 It is a flowchart of the steps of another method for handling a database host downtime provided in an embodiment of the present invention;

[0041] Figure 3 It is a flowchart of the steps of another method for handling a database host downtime provided in an embodiment of the present invention;

[0042] Figure 4 It is a structural block diagram of a database host downtime fault processing device provided in an embodiment of the present invention;

[0043] Figure 5 This is a system architecture diagram of a one-master and three-slave database provided in an embodiment of the present invention;

[0044] Figure 6 is a block diagram of an electronic device provided in an embodiment of the present invention;

[0045] Figure 7 is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0046] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0047] Reference Figure 1 , shows a flowchart of a method for troubleshooting a database host downtime provided in an embodiment of the present invention, which may specifically include the following steps:

[0048] Figure 1FIG. 1 is a flowchart of a method for troubleshooting a database host downtime provided in an embodiment of the present invention. Figure 1 As shown, the method specifically includes:

[0049] S11. When it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold, a global transaction ID is obtained from a slave database that has a master-slave relationship with the target master database.

[0050] In the embodiment of the present invention, the data replication mode between the master and the backup machine adopts semi-synchronous replication, and different backup machines are configured with different priorities, such as Figure 5 As shown, the backup machine in the same computer room as the host has the highest priority, such as the backup machine in IDC1 in the figure. The backup machine in the same city has the second highest priority, such as the backup machine in IDC2 in the figure. The priority of the backup machine across cities is lower, such as the backup machine in IDC3 in the figure. The priority of the backup machine can be configured in advance according to the principle of distance. In this way, when the host fails and the backup machine is re-selected as the host, the backup machine with a high priority is selected based on the network delay of database access and the principle of proximity.

[0051] The following describes how to troubleshoot the problem:

[0052] The embodiment of the present invention can detect host downtime through heartbeat. The downtime may be detected through the heartbeat reported by the host agent, or it may be due to network jitter and detected through the heartbeat of the standby machine. If it is detected through the heartbeat of the standby machine, you can wait for a certain time (for example, 24 seconds) before starting processing. During the 24 seconds of waiting, if the network is restored, no processing is required. Detecting host downtime through heartbeat refers to determining whether the host is operating normally by monitoring the heartbeat signal sent by the host. The heartbeat mechanism is usually performed by the host regularly sending specific heartbeat packets, which contain timestamps or other status information. The server determines whether the host is down by monitoring these heartbeat packets.

[0053] Furthermore, the global transaction ID (GTID) is obtained from all slave databases (Slaves). At this time, it should be noted that if the system is a cross-computer room architecture with one master and three slaves, the entire computer room may go down. If the entire computer room goes down, it is very likely that the main machine and the backup machine with the highest priority go down at the same time. At this time, obtaining the GTID from all slaves may fail. Therefore, when obtaining the GTID, a timeout period (for example, 60 seconds) needs to be set. If it is not successfully obtained after the timeout, the current node is considered unavailable and kicked out of the cluster.

[0054] S12. Determine a fault handling strategy based on the proportion of slave databases that have obtained the global transaction ID.

[0055] Calculate the ratio of the number of first slave databases that have obtained the global transaction ID to the total number of slave databases; when the ratio is greater than or equal to the preset ratio threshold, determine the fault handling strategy as determining a new master database based on the priority and data volume of the slave database; when the ratio is less than the preset ratio threshold, determine the fault handling strategy as stopping switching databases.

[0056] Specifically, determine whether more than half of the slaves (the ratio of the number of first slave databases to the total number of slave data) have correctly obtained the GTID. If it is a one-master-one-slave architecture, you must obtain the GTID before you can perform fault recovery. If it is a one-master-two-slave architecture, you still need to obtain the GTID of two slaves before you can continue processing; if it is a one-master-three-slave architecture, it supports the simultaneous failure of the master and one slave, and you can perform fault recovery. In summary, more than half of the slaves need to obtain the GTID before you can continue to perform fault recovery, otherwise, the master-slave switch cannot be completed. If the switch cannot be completed, you can directly alarm and set the instance to maintenance.

[0057] S13: Perform fault handling on the host crash of the target primary database based on the fault handling strategy.

[0058] If the fault handling strategy is determined to be to determine the new master database based on the priority and data volume of the slave database, then obtain the data volume corresponding to all the slave databases respectively; determine whether the slave database with the highest priority has the largest data volume; if so, determine the slave database with the highest priority and the largest data volume as the new master database; if not, perform data synchronization processing on the slave database with the highest priority based on the slave database with the largest data volume, and determine the slave database with the highest priority after the data synchronization processing as the new master database.

[0059] If the fault handling strategy is determined to stop switching the database, an alarm message is generated and the instance status of the target primary database is set to maintenance.

[0060] The method for handling a database host downtime provided by an embodiment of the present invention obtains a global transaction ID from a slave database that has a master-slave relationship with the target master database when it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold; determines a fault handling strategy based on the proportion of the number of slave databases that obtain the global transaction ID; and handles the host downtime of the target master database based on the fault handling strategy. Compared with the existing method of selecting a backup machine to be the master when the host is down, but the data of the backup machine and the host are usually inconsistent, resulting in the inability to quickly repair the fault and ensure high system availability and data consistency, this method reselects the host within the plan through a fault handling strategy to ensure high system availability and data consistency, and improve fault repair efficiency.

[0061] Figure 2 FIG. 1 is a flowchart of another method for troubleshooting a database host downtime provided in an embodiment of the present invention. Figure 1 As shown, the method specifically includes:

[0062] S21. When it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold, a global transaction ID is obtained from a slave database that has a master-slave relationship with the target master database.

[0063] Embodiments of the present invention are combined Figure 3 The data replication between the master and slave is done in detail. Semi-synchronous replication is used, and different slaves are configured with different priorities. For example, Figure 5 As shown, the backup machine in the same computer room as the host has the highest priority, such as the backup machine in IDC1 in the figure. The backup machine in the same city has the second highest priority, such as the backup machine in IDC2 in the figure. The priority of the backup machine across cities is lower, such as the backup machine in IDC3 in the figure. The priority of the backup machine can be configured in advance according to the principle of distance. In this way, when the host fails and the backup machine is re-selected as the host, the backup machine with a high priority is selected based on the network delay of database access and the principle of proximity.

[0064] The following describes how to troubleshoot the problem:

[0065] The embodiment of the present invention can detect host downtime through heartbeat. The downtime may be detected through the heartbeat reported by the host agent, or it may be due to network jitter and detected through the heartbeat of the standby machine. If it is detected through the heartbeat of the standby machine, you can wait for a certain time (for example, 24 seconds) before starting processing. During the 24 seconds of waiting, if the network is restored, no processing is required. Detecting host downtime through heartbeat refers to determining whether the host is operating normally by monitoring the heartbeat signal sent by the host. The heartbeat mechanism is usually performed by the host regularly sending specific heartbeat packets, which contain timestamps or other status information. The server determines whether the host is down by monitoring these heartbeat packets.

[0066] Furthermore, the global transaction ID (GTID) is obtained from all slave databases (Slaves). At this time, it should be noted that if the system is a cross-computer room architecture with one master and three slaves, the entire computer room may go down. If the entire computer room goes down, it is very likely that the main machine and the backup machine with the highest priority go down at the same time. At this time, obtaining the GTID from all slaves may fail. Therefore, when obtaining the GTID, a timeout period (for example, 60 seconds) needs to be set. If it is not successfully obtained after the timeout, the current node is considered unavailable and kicked out of the cluster.

[0067] S22. Calculate the ratio of the number of first slave databases that have obtained the global transaction ID to the total number of slave databases.

[0068] Determine whether more than half of the slaves (the ratio of the number of first slave databases to the total number of slave data) have correctly obtained the GTID. If it is a one-master-one-slave architecture, you must obtain the GTID before you can perform fault recovery. If it is a one-master-two-slave architecture, you still need to obtain the GTID of two slaves before you can continue processing; if it is a one-master-three-slave architecture, it supports the simultaneous failure of the master and one slave, and you can perform fault recovery. In summary, more than half of the slaves need to obtain the GTID before you can continue to perform fault recovery, otherwise, the master-slave switch cannot be completed. If the switch cannot be completed, you can directly alarm and set the instance to maintenance.

[0069] S23: When the ratio is greater than or equal to a preset ratio threshold, determining the fault handling strategy to be a new master database based on the priority and data volume of the slave database.

[0070] If the fault handling strategy is determined to be to determine the new master database based on the priority and data volume of the slave database, then obtain the data volume corresponding to all the slave databases respectively; determine whether the slave database with the highest priority has the largest data volume; if so, determine the slave database with the highest priority and the largest data volume as the new master database; if not, perform data synchronization processing on the slave database with the highest priority based on the slave database with the largest data volume, and determine the slave database with the highest priority after the data synchronization processing as the new master database.

[0071] Specifically, the GTIDs of more than half of the slaves have been correctly obtained. Next, from these nodes, select the node with the highest priority as the new master. Determine whether the new master has the largest amount of data. If it has the largest amount of data, it can be directly promoted to the master. If the new master does not have the largest amount of data, that is, the amount of data of other slaves is more than that of the new master, it is necessary to connect to the slave with the most data to synchronize data.

[0072] Furthermore, the slave with the highest priority and the largest amount of data is promoted to the master, the replication information of the new master is removed, and the Super Read Only option is removed. The instance is set to the available state, and an alarm is sent for the instance to be online.

[0073] S24: When the ratio is less than a preset ratio threshold, determining that the fault handling strategy is to stop switching databases.

[0074] If the number of first slave databases accounts for less than half of the total number of slave databases, the master-slave switch cannot be completed. If the switch cannot be completed, you can directly alarm and set the instance to maintenance.

[0075] S25. After determining the new primary database, set the data replication permission of the new primary database, and bind the floating IP to the host of the new primary database.

[0076] Switch the high-availability database to synchronous replication to prevent secondary attacks (only for the architecture of one master and two slaves and one master and three slaves). Then, bind the floating IP to the new host. At this point, the service is restored. This step is very critical. If the process does not proceed to this step, it is considered that the master-slave switch has failed. The switch failure is very likely to cause the database service to be unavailable, and the database administrator (Database Administrator, DBA) needs to handle it immediately.

[0077] S26. Establish communication connection between other slave databases and the new master database.

[0078] Furthermore, other slaves are connected to the new host for data replication. For a one-master-one-slave architecture, this situation does not exist; for a one-master-two-slave architecture or a one-master-three-slave architecture, other available slaves need to be connected to the new host for replication first.

[0079] S27: Repair the downed host of the target master database, and delete the target master database node in the database cluster.

[0080] S28: After the downtime host of the target master database is repaired, a data consistency check is performed and updated.

[0081] S29. After the data consistency check is updated, the downtime host that has been repaired is added back to the database cluster as a slave database.

[0082] The following is a unified description of S27-S29:

[0083] After the service is restored, you can still try to repair the downed host. Regardless of whether the repair is successful or not, the node will be kicked out of the cluster, and the database architecture of one master and three slaves will be downgraded to one master and two slaves. The purpose of this is that if the host repair fails, it cannot be added to the cluster. If the host repair is successful, data consistency verification is still required. Therefore, the database is first downgraded to a one master and two slaves database architecture. If the database fails again, it can still be switched.

[0084] The key to repairing a node is not to pull up the database and connect it to a new host for replication. The key is how to ensure data consistency. Since the current system uses the after_commit mode of MySQL 5.7, there may be some transactions that have been committed but have not yet been synchronized to the backup machine, resulting in multiple transactions on the old host. In order to deal with this situation, the database is restored, but it will not be put online immediately after restoration, and a second check is required.

[0085] The method for handling a database host downtime provided by an embodiment of the present invention obtains a global transaction ID from a slave database that has a master-slave relationship with the target master database when it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold; determines a fault handling strategy based on the proportion of the number of slave databases that obtain the global transaction ID; and handles the host downtime of the target master database based on the fault handling strategy. This method reselects the host within the plan through the fault handling strategy, ensures high system availability and data consistency, and improves fault repair efficiency.

[0086] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0087] Combine the following Figure 3 The following is a detailed description of the method for troubleshooting a database host crash:

[0088] Step 1: Detect host downtime through heartbeat and start fault recovery. It should be noted that downtime may be detected through the heartbeat reported by the host agent, or it may be due to network jitter and detected through the heartbeat of the slave. If it is detected through the heartbeat of the slave, refer to the existing database architecture and wait for 24 seconds before starting processing. During the 24-second waiting period, if the network is restored, no processing is required.

[0089] Step 2: Get GTID from all slaves. At this time, it should be noted that if it is a cross-computer room solution with one master and three slaves, the entire computer room may go down. If the entire computer room goes down, it is very likely that the master and the slave with the highest priority go down at the same time. At this time, getting GTID from all slaves may fail. Therefore, when getting GTID, a timeout needs to be set. If it is not successfully obtained after the timeout, the current node is considered unavailable and kicked out of the cluster.

[0090] Step 3: Check whether more than half of the slaves have correctly obtained the GTID. If it is a one-master-one-slave architecture, you must obtain the GTID before you can perform fault recovery. If it is a one-master-two-slave architecture, you still need to obtain the GTIDs of two slaves before you can continue processing. If it is a one-master-three-slave architecture, it supports the simultaneous failure of the master and one slave, and you can perform fault recovery. In summary, more than half of the slaves need to obtain the GTID before you can continue to perform fault recovery, otherwise, the switch cannot be completed. If the switch cannot be completed, you can directly alarm and set the instance to maintenance.

[0091] In step 4, the GITD of more than half of the slaves has been correctly obtained. Next, from these nodes, the node with the highest priority is selected as the new master. Therefore, it is determined whether the new master has the most data. If it has the most data, it can be directly promoted to the master (step 5). If the new master does not have the most data, that is, the data of other slaves is more than that of the new master, it is necessary to connect to the slave with the most data to synchronize the data.

[0092] Step 5: Promote the highest priority slave to master. The so-called promotion to master means removing the copy information and the Super Read Only option.

[0093] Step 6: First connect other slaves to the new master for data replication. This situation does not exist for a one-master-one-slave architecture. For a one-master-two-slave architecture or a one-master-three-slave architecture, other available slaves need to be connected to the new master for replication.

[0094] Step 7: Switch the high-availability database to synchronous replication to prevent secondary attacks (only for the architecture of one master and two slaves and one master and three slaves). Then, bind the floating IP to the new master, and the service will be restored. Step 7 is very critical. If the process does not proceed to step 7, it is considered that the switch has failed. The switch failure is very likely to cause the database service to be unavailable, and the DBA (Database Administrator, referred to as DBA) needs to handle it immediately. After step 7, the database switch is successful and the impact on the business is small. After the service is restored, try to repair the original host. Regardless of whether the repair is successful, the node will be kicked out of the cluster, and the database architecture of one master and three slaves will be downgraded to a database architecture of one master and two slaves. The purpose of this is that if the host repair fails, it cannot join the cluster. If the host repair is successful, data consistency verification is still required. Therefore, the database is downgraded to a database architecture of one master and two slaves first. If the database fails again next, it can still be switched.

[0095] Step 8, try to repair the downed node. The key to repairing a node is not to pull up the database and connect to the new master for replication. The key point is how to ensure data consistency. Since the current system uses the after_commit mode of MySQL 5.7, there may be some transactions that have been committed but have not been synchronized to the slave, resulting in the situation where the old master has multiple transactions. In order to deal with this situation, the database is restored. After the recovery, it will not be put online immediately, and a second check is required.

[0096] Step 9 is just to execute Change master to connect to the new host for replication.

[0097] Step 10: Set the instance to available status and send an alarm for the instance to go online.

[0098] At this point, the master election within the host downtime plan has been completed, the host provides services normally, and data consistency is guaranteed.

[0099] Reference Figure 4 , shows a structural block diagram of a database host downtime fault processing device provided in an embodiment of the present invention, which may specifically include the following modules:

[0100] The acquisition module 401 is used to acquire a global transaction ID from a slave database that has a master-slave relationship with the target master database when it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold;

[0101] A determination module 402 is used to determine a fault handling strategy based on a proportion of the number of slave databases that have obtained a global transaction ID;

[0102] The processing module 403 is used to perform fault processing on the host crash of the target primary database based on the fault processing strategy.

[0103] In one possible implementation, the determination module 402 is specifically used to calculate the ratio of the number of first slave databases that have obtained the global transaction ID to the total number of slave databases; when the ratio is greater than or equal to a preset ratio threshold, the fault handling strategy is determined to be to determine a new master database based on the priority and data volume of the slave database; when the ratio is less than the preset ratio threshold, the fault handling strategy is determined to stop switching databases.

[0104] In a possible implementation, the determination module 402 is further used to pre-set a priority for each slave database based on the distance from the target master database; obtain the data volume corresponding to all slave databases respectively; determine whether the data volume of the slave database with the highest priority is the largest; if so, determine the slave database with the highest priority and the largest data volume as the new master database; if not, perform data synchronization processing on the slave database with the highest priority based on the slave database with the largest data volume, and determine the slave database with the highest priority after the data synchronization processing as the new master database.

[0105] In a possible implementation manner, the determination module 402 is further configured to generate an alarm message and set the instance state of the target primary database to under maintenance if it is determined that the fault handling strategy is to stop switching the database.

[0106] In a possible implementation, the processing module 403 is specifically used to set data replication permissions for the new master database after determining the new master database, and bind a floating IP to the host of the new master database; and establish communication connections between other slave databases and the new master database.

[0107] In a possible implementation, the processing module 403 is also used to repair the downtime host of the target master database and delete the target master database node in the database cluster; perform a data consistency check update after the repair of the downtime host of the target master database is completed; and re-add the repaired downtime host after the data consistency check update to the database cluster as a slave database.

[0108] In a possible implementation, the processing module 403 is further configured to, when a global transaction ID of a slave database cannot be obtained after a preset time, determine that the corresponding slave database is unavailable, and then delete the unavailable slave database node from the database cluster.

[0109] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0110] In addition, an embodiment of the present invention further provides an electronic device, such as Figure 6 As shown, it includes a processor 1301, a communication interface 1302, a memory 1303 and a communication bus 1304, wherein the processor 1301, the communication interface 1302, and the memory 1303 communicate with each other through the communication bus 1304.

[0111] Memory 1303, used for storing computer programs;

[0112] The processor 1301 is used to implement the following steps when executing the program stored in the memory 1303:

[0113] When it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold, a global transaction ID is obtained from a slave database that has a master-slave relationship with the target master database; a fault handling strategy is determined based on the proportion of the number of slave databases that have obtained the global transaction ID; and fault handling is performed on the host downtime of the target master database based on the fault handling strategy.

[0114] In one possible implementation, the ratio of the number of first slave databases that have obtained the global transaction ID to the total number of slave databases is calculated; when the ratio is greater than or equal to a preset ratio threshold, the fault handling strategy is determined to be to determine a new master database based on the priority and data volume of the slave database; when the ratio is less than the preset ratio threshold, the fault handling strategy is determined to stop switching databases.

[0115] In one possible implementation, a priority is set in advance for each slave database according to the distance from the target master database; the data volume corresponding to all the slave databases is obtained; it is determined whether the slave database with the highest priority has the largest data volume; if so, the slave database with the highest priority and the largest data volume is determined as the new master database; if not, data synchronization processing is performed on the slave database with the highest priority based on the slave database with the largest data volume, and the slave database with the highest priority after the data synchronization processing is determined as the new master database.

[0116] In a possible implementation manner, if it is determined that the fault handling strategy is to stop switching the database, an alarm message is generated and the instance state of the target primary database is set to be under maintenance.

[0117] In a possible implementation, after determining the new master database, data replication permissions for the new master database are set, and a floating IP is bound to the host of the new master database; and other slave databases are connected to the new master database for communication.

[0118] In one possible implementation, the downtime host of the target master database is repaired, and the target master database node is deleted from the database cluster; after the repair of the downtime host of the target master database is completed, a data consistency check is updated; and the repaired downtime host after the data consistency check update is re-added to the database cluster as a slave database.

[0119] In a possible implementation, when the global transaction ID of a slave database cannot be obtained after a preset time, it is determined that the corresponding slave database is unavailable, and the unavailable slave database node is deleted from the database cluster.

[0120] The communication bus mentioned in the above terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0121] The communication interface is used for communication between the above terminal and other devices.

[0122] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0123] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0124] like Figure 7 As shown, in another embodiment provided by the present invention, a computer-readable storage medium 1401 is also provided, in which instructions are stored. When the computer-readable storage medium 1401 is run on a computer, the computer executes the database host crash fault handling method described in the above embodiment.

[0125] In another embodiment of the present invention, a computer program product including instructions is provided. When the computer program product is run on a computer, the computer executes the XX method described in the above embodiment.

[0126] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0127] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0128] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0129] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A method for handling a database host downtime, characterized in that: include: When it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold, a global transaction ID is obtained from a slave database that has a master-slave relationship with the target master database; Determine the fault handling strategy based on the proportion of slave databases that have obtained the global transaction ID; The host failure of the target primary database is handled based on the failure handling strategy.

2. The method according to claim 1, characterized in that The fault handling strategy is determined based on the proportion of the number of slave databases that obtain the global transaction ID, including: Calculate the ratio of the number of first slave databases that have obtained the global transaction ID to the total number of slave databases; When the ratio is greater than or equal to a preset ratio threshold, determining that the fault handling strategy is to determine a new master database based on the priority and data volume of the slave database; When the ratio is less than a preset ratio threshold, it is determined that the fault handling strategy is to stop switching databases.

3. The method according to claim 2, characterized in that When the ratio is greater than or equal to a preset ratio threshold, determining the fault handling strategy is to determine a new master database based on the priority and data volume of the slave database, including: Setting a priority for each slave database in advance according to the distance from the target master database; Get all the corresponding data from the database; Determine whether the data volume of the slave database with the highest priority is the largest; If so, the slave database with the highest priority and the largest amount of data is determined as the new master database; If not, data synchronization is performed on the slave database with the highest priority based on the slave database with the largest data volume, and the slave database with the highest priority after the data synchronization is determined as the new master database.

4. The method according to claim 2, characterized in that: When the ratio is less than a preset ratio threshold, determining that the fault handling strategy is to stop switching the database includes: If it is determined that the fault handling strategy is to stop switching the database, an alarm message is generated and the instance state of the target primary database is set to be under maintenance.

5. The method according to claim 3, characterized in that: The performing fault handling on the host crash of the target primary database based on the fault handling strategy includes: After determining the new primary database, set the data replication permission of the new primary database and bind the floating IP to the host of the new primary database; The other slave databases are communicatively connected to the new master database.

6. The method according to claim 1, characterized in that The method further comprises: Repair the downtime host of the target master database and delete the target master database node in the database cluster; After the downtime host of the target master database is repaired, a data consistency check and update is performed; After the data consistency check is updated, the downtime host that has been repaired is rejoined to the database cluster as a slave database.

7. The method according to claim 2, characterized in that The method further comprises: When the global transaction ID of a slave database cannot be obtained after a preset time, it is determined that the corresponding slave database is unavailable, and the unavailable slave database node is deleted from the database cluster.

8. A database host downtime fault handling device, characterized in that: include: An acquisition module is used to acquire a global transaction ID from a slave database that has a master-slave relationship with the target master database when it is determined that the host of the target master database is down and the downtime duration reaches a preset time threshold; A determination module, used to determine a fault handling strategy based on the proportion of slave databases that have obtained global transaction IDs; A processing module is used to perform fault processing on the host crash of the target primary database based on the fault processing strategy.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is used to store computer programs; The processor is used to implement the database host crash fault handling method as described in any one of claims 1-7 when executing the program stored in the memory.

10. A computer-readable medium having instructions stored thereon, which, when executed by one or more processors, causes the processors to execute the database host crash fault handling method according to any one of claims 1 to 7.

Images