Database switching methods, devices, terminals and storage media

Abstract

This application discloses a database switching method, apparatus, terminal, and storage medium. The method includes: actively probing the databases in a database cluster to obtain a first probing result; based on the first probing result, performing bypass probing on the databases to obtain a second probing result; and based on the second probing result, performing a stop-loss operation on the databases. This application uses a combination of active and bypass probing to determine database anomalies, and then performs stop-loss operations on the abnormal databases by judging instance roles and weights. This approach is applicable not only to master-slave and distributed database scenarios but also to relational database failure scenarios with multiple business entry points based on role-based judgment.

Description

Technical Field

[0001] This application relates to the field of database cluster technology, and more specifically, to a database switching method, apparatus, terminal, and storage medium. Background Technology

[0002] Currently, major cloud vendors offer database products and services based on MySQL. To ensure high availability, MySQL is often built into a high-availability cluster. A high-availability cluster includes a service that protects the availability and stability of the entire MySQL cluster, minimizing the impact of failures caused by software, machine, or human error on the database. We call this service that ensures the high availability of the database cluster the database mitigation service.

[0003] In real-world database high availability and loss mitigation scenarios, common issues include machine failures and human error. These scenarios can lead to errors such as database connection failures and write failures for business applications. Currently, major cloud vendors offer MySQL-based database products and services. Since database instances are deployed on machines, server failures inevitably occur, causing database unavailability. To ensure the stability of database services, various database high availability and automatic loss mitigation technologies have emerged.

[0004] Currently, the basic principles of automatic stop-loss are as follows: Figure 1 As shown, specifically: business modules use a VIP or domain name to access the primary database and perform CRUD operations on data. The standby database plays a backup role; online businesses do not directly connect to or use the standby database. When the primary database becomes unavailable, the database failover service will determine whether the primary database is truly unavailable through methods such as port and process liveness detection. Then, it will perform a master-slave switch, changing the original standby database to the new primary database and pointing the VIP or domain name to the new primary database. At this point, business availability can be restored, and CRUD operations on data can be performed normally.

[0005] However, for medium- to large-scale internet technology industries, in order to provide greater storage and better performance for their businesses, various database architectures are used, including complex architectures such as master-slave and multi-master-multi-slave. Each type of architecture is further subdivided into database roles, providing access services for online and offline businesses and user queries through multiple entry points. Currently, there is no solution for switching between these complex database architectures. Summary of the Invention

[0006] The main objective of this application is to provide a database switching method, apparatus, terminal, and storage medium to address the lack of switching methods for complex database architectures in related technologies.

[0007] To achieve the above objectives, firstly, this application provides a database switching method, comprising:

[0008] Actively probe the databases in the database cluster to obtain the first probe results;

[0009] Based on the first detection result, a bypass detection is performed on the database to obtain the second detection result;

[0010] Based on the results of the second detection, a stop-loss operation was performed on the database.

[0011] In one possible implementation, active probing is performed on the databases in the database cluster to obtain the first probing results, including:

[0012] The database middleware agent periodically and proactively probes the databases in the database cluster;

[0013] Determine if the database is the primary database to obtain the first determination result;

[0014] Based on the first judgment result, the first detection result is obtained.

[0015] In one possible implementation, the first detection result includes at least a database anomaly;

[0016] Based on the first judgment result, the first detection result is obtained, including:

[0017] If the first judgment result is yes, and the database cannot write table data, then the database is determined to be abnormal;

[0018] If the first judgment result is negative, and the database cannot read the table data, then the database is determined to be abnormal;

[0019] If the first judgment result is yes, the database cannot write table data and the database cannot read table data, thus the database is determined to be abnormal;

[0020] If the first judgment result is negative, the database cannot read table data and cannot write files to the disk, indicating a database error.

[0021] In one possible implementation, the first detection result includes at least a heartbeat abnormality;

[0022] Based on the first judgment result, the first detection result is obtained, including:

[0023] If the first judgment result is negative, the database cannot read the table data, but the database can write files to the disk, thus confirming an abnormal heartbeat.

[0024] In one possible implementation, based on the first probe result, a bypass probe is performed on the database to obtain a second probe result, including:

[0025] Determine if the database is the primary database to obtain the second determination result;

[0026] Based on the second judgment result, the second detection result is determined.

[0027] In one possible implementation, the second detection result is determined based on the second judgment result, including:

[0028] If the second judgment result is negative, determine whether there is a binary storage thread for the slave database in the master database;

[0029] If the binary storage thread of the slave database does not exist in the master database, the absence of the binary storage thread of the slave database in the master database will be taken as the second detection result.

[0030] In one possible implementation, the second detection result is determined based on the second judgment result, including:

[0031] If the second judgment result is yes, determine whether the master-slave synchronization between the master database and the slave database is abnormal;

[0032] If the master-slave synchronization between the master and slave databases is abnormal, the abnormal master-slave synchronization between the master and slave databases will be used as the second detection result.

[0033] In one possible implementation, based on the second probe result, a stop-loss operation is performed on the database, including:

[0034] If the database cluster switching switch is turned on, the database cluster is locked, and it is determined whether the database is the primary database, thus obtaining the third judgment result;

[0035] Based on the third judgment result, a stop-loss operation is performed on the database.

[0036] In one possible implementation, based on the third judgment result, a stop-loss operation is performed on the database, including:

[0037] If the third judgment result is yes, a new master database is elected from the slave databases, and the new master database and the master database are switched.

[0038] In one possible implementation, if the third judgment result is yes, a new master database is elected from the slave databases, and a switchover is performed between the new master database and the master database, including:

[0039] Writes to the master database and proxy server are prohibited, and a new master database is elected based on the slave databases in the database cluster and their corresponding weights.

[0040] Remove the write ban on the new master database and proxy server.

[0041] In one possible implementation, based on the third judgment result, a stop-loss operation is performed on the database, including:

[0042] If the third judgment result is negative, a replacement slave is selected based on the slave's type and weight.

[0043] In one possible implementation, the database cluster includes a master database, online slave databases, offline slave databases, backup slave databases, subscription slave databases, and redundant slave databases.

[0044] Secondly, embodiments of the present invention provide a database switching device, comprising:

[0045] The active probing module is used to actively probe the databases in the database cluster and obtain the first probe results;

[0046] The bypass detection module is used to perform bypass detection on the database based on the first detection result to obtain the second detection result;

[0047] The stop-loss module is used to perform stop-loss operations on the database based on the results of the second probe.

[0048] Thirdly, embodiments of the present invention provide a terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above database switching methods.

[0049] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above database switching methods.

[0050] This invention provides a database switching method, apparatus, terminal, and storage medium, comprising: actively probing the databases in a database cluster to obtain a first probing result; then, based on the first probing result, performing bypass probing on the databases to obtain a second probing result; and finally, based on the second probing result, performing a stop-loss operation on the databases. This invention uses a combination of active and bypass probing to determine database anomalies, and then performs stop-loss operations on the abnormal databases by judging instance roles and weights. This is applicable not only to master-slave and distributed (multi-master-multi-slave) database scenarios, but also to relational database failure scenarios with multiple business entry points based on role-based judgment. Attached Figure Description

[0051] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings:

[0052] Figure 1 This is a flowchart illustrating the implementation of a database switching method according to an embodiment of the present invention;

[0053] Figure 2 This is a flowchart illustrating the implementation of a database switching method according to another embodiment of the present invention;

[0054] Figure 3 This is a flowchart illustrating the implementation of a database switching method according to another embodiment of the present invention;

[0055] Figure 4 This is a flowchart illustrating the implementation of a database probing method according to an embodiment of the present invention;

[0056] Figure 5 This is a flowchart illustrating the implementation of a database probing method according to another embodiment of the present invention;

[0057] Figure 6 This is a flowchart illustrating the implementation of an automatic loss-stopping method for databases provided in an embodiment of the present invention.

[0058] Figure 7 This is a flowchart illustrating the implementation of a database switching method according to another embodiment of the present invention;

[0059] Figure 8 This is a flowchart illustrating the implementation of a database switching method according to another embodiment of the present invention;

[0060] Figure 9 This is a schematic diagram of the structure of a database switching device provided in an embodiment of the present invention;

[0061] Figure 10 This is a schematic diagram of the terminal provided in an embodiment of the present invention. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0063] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in sequences other than those illustrated or described herein.

[0064] It should be understood that in the various embodiments of the present invention, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0065] It should be understood that in this invention, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0066] It should be understood that in this invention, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, "and / or B" can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0067] It should be understood that in this invention, "B corresponding to A", "B corresponding to A", "A and B correspond", or "B and A correspond" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0068] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0069] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0070] First, to make the present invention clear and easy to understand, the technical terms are explained as follows:

[0071] High Availability Cluster (HA Cluster) is a server clustering technology designed to reduce service downtime.

[0072] VIP: Virtual IP Address, mainly used for switching between different hosts, primarily for server master-slave switching.

[0073] Domain name: A domain name (English: DomainName), also known as a network domain, is a name of a computer or group of computers on the Internet consisting of a string of names separated by dots. It is used to locate and identify the computer during data transmission.

[0074] Automatic stop loss: refers to the automated operation performed by a program according to preset logic to restore an abnormal online database cluster to normal.

[0075] Master and slave databases: The master database refers to a writable database instance in the database cluster. The master database transmits data from the master database to the slave database (including backup slave databases, offline slave databases, subscription slave databases, etc.) in real time through binlog (binary log) to ensure data consistency between the master and slave databases.

[0076] Old Master: When the current master database undergoes a master-slave switch, the master database that is switched off becomes the old master.

[0077] New Master: When the current master database undergoes a master-slave switch, the master database that is switched off becomes the old master, and the new master database becomes the new master.

[0078] Furthermore, to make the objectives, technical solutions, and advantages of the present invention clearer, specific embodiments will be described below in conjunction with the accompanying drawings.

[0079] The database switching method in this application is mainly applied to Figure 2 In the architecture shown, the business modules access the dbproxy data middleware layer via BNS. BNS is our internal name service, analogous to DNS. Many dbproxy services are mounted under BNS, and the actual machine IP address can be obtained through the BNS name. (Business Networking Services)

[0080] For example, the following two dbproxy addresses can be accessed through the address test.tinker.bns.

[0081] -10.15.6.1:6100

[0082] -10.165.6.2:6100

[0083] dbproxy is a database proxy service that can identify and forward business traffic.

[0084] By configuring master-slave replication, and since only the master database in the cluster can perform data addition, modification, and deletion, write traffic needs to be forwarded to the master database and read traffic to the slave database. Because there are multiple online services, each with different response times, and offline services often perform large-scale query operations, which can impact the performance of the slave database and thus affect online services, we designed a grouping concept to isolate business traffic. For example, the topology configuration for multiple services is as follows:

[0085]

[0086]

[0087] When business traffic reaches dbproxy, dbproxy identifies which group the traffic belongs to. If it is an online group account, the traffic is forwarded to the node00 topology. The traffic type is then determined, with write traffic forwarded to 10.15.6.3:5100 and read traffic forwarded to 10.15.6.4:5100. Other groups are handled similarly.

[0088] Furthermore, based on the different traffic they handle, the databases in the database cluster in the above architecture can be divided into the roles shown in Table 1 below.

[0089] Table 1 Database Role Types in a Database Cluster

[0090]

[0091] As shown in Table 1, the database cluster includes a master database, online slave databases, offline slave databases, backup slave databases, subscription slave databases, and redundant slave databases.

[0092] The switching method in this application mainly includes two steps: probing the databases in the aforementioned database cluster and automatically stopping losses.

[0093] Among them, database instance liveness detection, also known as health awareness, can automatically detect whether a database instance is connectable, readable, and writable.

[0094] Common stop-loss scenarios and operations in automatic stop-loss include: when the master database is unreadable or unconnectable, automatically perform master-slave switchover and automatically switch the original master traffic to the new master; when the server or network where the master database is located is abnormal and the business cannot be accessed, automatically perform master-slave switchover and automatically switch the original master traffic to the new master; when the slave database is unreadable or unconnectable, automatically take the slave database offline and automatically switch the read traffic on the abnormal slave database to other slave databases; when the server or network where the slave database is located is abnormal and the business cannot be accessed, automatically take the slave database offline and automatically switch the read traffic on the abnormal slave database to other slave databases.

[0095] To address the aforementioned stop-loss operations, corresponding database stop-loss services can be provided. Specifically, the Tinker module maintains the topology of the managed MySQL cluster and makes stop-loss decisions and task distributions based on the status of the MySQL instances. It adopts a leader-follower distributed model, where the leader and followers can detect each other's anomalies and take over and execute unfinished stop-loss tasks in the faulty Tinker. The Mysql-agent module detects the liveness of MySQL instances and reports their status information to Tinker for stop-loss decisions. It also performs corresponding stop-loss or other operations based on the tasks issued by Tinker. The proxy-agent manages the configuration of DBproxy and DDBS and performs corresponding stop-loss or other operations based on the tasks issued by Tinker. A single agent can manage multiple DBproxy instances simultaneously, meeting the needs of scenarios where multiple DBproxy instances are distributed on a single online server.

[0096] In one embodiment, such as Figure 3 As shown, a database switching method is provided, including the following steps:

[0097] Step S301: Actively probe the databases in the database cluster to obtain the first probe result.

[0098] This application uses the MySQL liveness detection module to actively (automatically) detect databases in a database cluster and obtain the first detection result, which determines the accuracy of the stop loss.

[0099] Combination Figure 4 and Figure 5 Describe the process of actively probing databases in a database cluster:

[0100] Active probing requires a database intermediary agent (mysql-agent) to periodically probe the databases in the database cluster, determine whether the database is the primary database, obtain the first determination result, and then obtain the first probe result based on the first determination result. The first probe result includes database anomalies and heartbeat anomalies.

[0101] If the first detection result includes a database anomaly, the process of obtaining the first detection result based on the first judgment result is as follows: if the first judgment result is yes, and the database cannot write table data, a database anomaly is determined; if the first judgment result is no, and the database cannot read table data, a database anomaly is determined; if the first judgment result is yes, and the database cannot write table data, and the database cannot read table data, a database anomaly is determined; if the first judgment result is no, and the database cannot read table data, and the database cannot write files to the disk, a database anomaly is determined.

[0102] If the first detection result indicates an abnormal heartbeat, the process of obtaining the first detection result based on the first judgment result is as follows: if the first judgment result is negative, the database cannot read the table data, and the database can write files to the disk, thus confirming an abnormal heartbeat.

[0103] After each liveness detection cycle is completed, mysql-agent reports a message to tinker. If there are no abnormalities, it updates the heartbeat information of the database stored in tinker. If an abnormality is found, that is, at least one of the database abnormality and heartbeat abnormality mentioned above, tinker initiates a bypass probe.

[0104] Step S302: Based on the first detection result, perform bypass detection on the database to obtain the second detection result.

[0105] There is a problem with proactive liveness detection: if the mysql-agent process is accidentally shut down during an upgrade or other circumstances, it cannot report timestamp heartbeats to Tinker. Tinker has a heartbeat detection logic that subtracts the time of the reported heartbeat from the current time. For example, if the difference exceeds 1 minute, it is considered that the database is abnormal and the corresponding stop-loss operation will be initiated.

[0106] Therefore, other logic is needed to bypass the detection of heartbeats and help determine whether the heartbeat timeout is caused by a complete machine crash or by the mysql-agent being shut down.

[0107] Combination Figure 6 The execution steps of bypass probing are described, namely, first determining whether the database is the primary database, obtaining a second determination result, and then determining the second probing result based on the second determination result.

[0108] Specifically, if the second judgment result is negative, check whether the slave's binary storage thread exists in the master database; if the slave's binary storage thread does not exist in the master database, use the absence of the slave's binary storage thread in the master database as the second detection result. If the role with the abnormal heartbeat is the slave, we utilize the principle that a binlog dump thread is established during master-slave synchronization to probe whether the slave's binlog dump thread exists in the master database. If it exists, it means the slave is still alive, and no stop-loss operation is performed.

[0109] If the second judgment result is yes, then determine whether the master-slave synchronization between the master and slave databases is abnormal; if the master-slave synchronization between the master and slave databases is abnormal, then treat the abnormal master-slave synchronization between the master and slave databases as the second detection result. Specifically, if the database with the abnormal heartbeat is the master database, we utilize the synchronization status information that the slave database will have during master-slave synchronization. By judging whether the synchronization between the slave and master databases is normal, we can assist in determining whether the master database is alive.

[0110] Step S303: Based on the second detection result, perform a stop-loss operation on the database.

[0111] After the bypass detection is completed, combined with Figure 6 If the database cluster switching switch is turned on, the database cluster is locked, and it is determined whether the database is the primary database. A third determination result is obtained, and then a stop-loss operation is performed on the database based on the third determination result. It should be noted that the stop-loss operation process is different when the database is the primary database and when it is a secondary database.

[0112] Scenario 1: If the third judgment result is yes, meaning the database to be switched is the master database, then a new master database is elected from the slave databases, and the switchover is performed on the new master database and the new master database. Specifically, write operations to the master database and the proxy server are first disabled. Then, based on the slave databases in the database cluster and their corresponding weights, a new master database is elected. After that, the write restrictions on the new master database and the proxy server are lifted, and the other databases in the database cluster are redirected to the new master database. The topology of the proxy server is also modified.

[0113] Will Figure 2 The architecture shown is applied to Figure 6 In the stop-loss process shown, when the abnormal database instance is the master database, the master-slave switch is implemented as follows.

[0114] 1) The prerequisite for master-slave failover is that the master and slave databases in the entire cluster are consistent. Therefore, writes to the old master database need to be disabled during the failover process. First, issue the command `set global read_only = on;` to the old master database instance to disable write operations on the old master database.

[0115] 2) The previous step may fail because the instance or machine has crashed and cannot process requests normally. To avoid this "frozen" scenario where the instance or machine is intermittently unresponsive, Tinker will modify the master database configuration in dbproxy to a non-existent machine IP address. For example, the original configuration would be:

[0116]

[0117]

[0118] The configuration after disabling write access is as follows:

[0119]

[0120]

[0121] This way, when business write traffic is sent to dbproxy, it will report an error because the master database address does not exist, thus achieving the goal of preventing business traffic from writing to the database cluster during the switchover process.

[0122] 3) We elect a new master database based on the online slave database, standby database, offline database, and their weights.

[0123] If the data is consistent, we will first determine the role, and the role priority is as follows.

[0124] Redundant slave database > Online slave database > Offline slave database > Backup slave database > Subscribed slave database

[0125] When roles are the same, we will determine priority based on weight. The higher the weight, the higher the ranking. When the weights are the same, such as two online slave databases with a weight of 9, we will randomly select one as the new master database.

[0126] 4) Send the new master database information to other slave databases, and all slave databases point to the new master database to start synchronizing the data of the new master database.

[0127] Remove the write restriction from the existing proxy-agent and modify the topology to a new, online-available topology. For example, the new master database would be 10.15.6.4:5100.

[0128]

[0129]

[0130] 5) Switching complete.

[0131] The second scenario: If the third judgment result is negative, that is, the database that needs to be switched is a slave database, then a replacement slave database is selected based on the type and weight of the slave database.

[0132] Will Figure 2 The architecture shown is applied to Figure 6 In the stop-loss process shown, when the abnormal database instance is a slave database, the master-slave switch is implemented as follows.

[0133] When a faulty database instance is detected as a slave, a slave shutdown operation will be initiated. For example, if the faulty slave is 10.15.6.6:5100...

[0134] 1) First, determine that the faulty slave is a machine in the offline group.

[0135] 2) Select a slave database to handle traffic based on role or weight (same as the election logic in master-slave switching).

[0136] 3) If the redundant library (10.15.6.8:5100) is selected to handle the traffic, modify the topology information to the new topology, i.e., the original topology is:

[0137] / / Offline grouping

[0138] node02

[0139] -Master:10.15.6.4:5100

[0140] -Slave:10.15.6.6:5100

[0141] The new topology is:

[0142] / / Offline grouping

[0143] node02

[0144] -Master:10.15.6.4:5100

[0145] -Slave:10.15.6.8:5100

[0146] 4) Switching complete.

[0147] The above database switching method can be applied to Figure 2 The database cluster in the illustrated architecture is a master-slave type cluster. This application also provides a database switching method, which can be applied to… Figure 7 The distributed database system (cluster) shown is a multi-master, multi-slave system.

[0148] Figure 7 The architecture shown introduces two concepts: ddbs-proxy and sharding. ddbs-proxy is a distributed database middleware specifically developed for Distributed Database Systems (DDBS). It supports writing to specified shards according to certain rules, such as taking the modulo of a field. For example, if id = 2 % 2 = 0, it is written to shard 0; if id = 1 % 2 = 1, it is written to shard 2. Each shard represents a master-slave cluster architecture.

[0149] according to Figure 7As you can see, the underlying architecture of DDBS is actually composed of multiple shards, where each shard represents a database cluster. Therefore, whether it is stop loss or probing, the automatic stop loss logic of a master-slave database cluster can be reused. When one shard is performing stop loss, other shards do not need to perform operations. We use cluster locks to control the serial stop loss operations between each shard.

[0150] Combination Figure 8 The database switching methods in a distributed database system (cluster) are described in detail below:

[0151] 1) When fragment 0 is abnormal, report it to tinker;

[0152] 2) Trigger the Tinker automatic stop-loss logic and begin acquiring cluster locks;

[0153] 3) After acquiring the lock, sharding begins and sharding automatically stops at 0.

[0154] 4) At this point, shard 1 is faulty and reported to tinker;

[0155] 5) The Tinker automatic stop-loss logic is triggered, and an attempt is made to acquire the cluster lock. However, the cluster lock is found to be occupied, and the process waits for the cluster lock to be released.

[0156] 6) After the sharding process reaches zero loss, release the cluster lock;

[0157] 7) At this point in step 5, the lock is acquired, and automatic stop-loss begins;

[0158] 8) Stop loss completed.

[0159] This invention provides a database switching method, comprising: actively probing the databases in a database cluster to obtain a first probing result; then, based on the first probing result, performing a bypass probing of the databases to obtain a second probing result; and finally, based on the second probing result, performing a stop-loss operation on the databases. This invention uses a combination of active and bypass probing to determine database anomalies, and then performs stop-loss operations on the abnormal databases by judging instance roles and weights. This method is applicable not only to master-slave and distributed (multi-master-multi-slave) database scenarios, but also to relational database failure scenarios with multiple business entry points based on role-based judgment.

[0160] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0161] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.

[0162] Figure 9 A schematic diagram of a database switching device according to an embodiment of the present invention is shown. For ease of explanation, only the parts related to the embodiment of the present invention are shown. The database switching device includes an active detection module 91, a bypass detection module 92, and a loss prevention module 93, as detailed below:

[0163] Active probing module 91 is used to actively probe the databases in the database cluster and obtain the first probe result;

[0164] The bypass detection module 92 is used to perform bypass detection on the database based on the first detection result to obtain the second detection result;

[0165] The stop-loss module 93 is used to perform stop-loss operations on the database based on the second detection result.

[0166] In one possible implementation, the active probing module 91 is also used for the database intermediate agent to periodically actively probe the databases in the database cluster; determine whether the database is the primary database and obtain a first judgment result; and obtain a first probing result based on the first judgment result.

[0167] In one possible implementation, the first detection result includes at least a database anomaly;

[0168] The active detection module 91 is also used to determine that the database is abnormal if the first judgment result is yes and the database cannot write table data; if the first judgment result is no and the database cannot read table data; if the first judgment result is yes, the database cannot write table data and the database cannot read table data; if the first judgment result is no, the database cannot read table data and the database cannot write files to the disk; if the first judgment result is no, the database cannot read table data and the database cannot write files to the disk.

[0169] In one possible implementation, the first detection result includes at least a heartbeat abnormality;

[0170] The active detection module 91 is also used to determine the heartbeat abnormality if the first judgment result is negative, the database cannot read the table data, and the database can write files to the disk.

[0171] In one possible implementation, the bypass detection module 92 is also used to determine whether the database is the main database and obtain a second judgment result; based on the second judgment result, a second detection result is determined.

[0172] In one possible implementation, the bypass detection module 92 is further configured to determine whether there is a binary storage thread of the slave database in the master database if the second judgment result is negative; and if there is no binary storage thread of the slave database in the master database, take the absence of a binary storage thread of the slave database in the master database as the second detection result.

[0173] In one possible implementation, the bypass detection module 92 is further configured to determine whether the master-slave synchronization between the master database and the slave database is abnormal if the second judgment result is yes; if the master-slave synchronization between the master database and the slave database is abnormal, the abnormal master-slave synchronization between the master database and the slave database is taken as the second detection result.

[0174] In one possible implementation, the stop-loss module 93 is further configured to lock the database cluster if the database cluster switching switch is turned on, and determine whether the database is the primary database to obtain a third judgment result; based on the third judgment result, perform a stop-loss operation on the database.

[0175] In one possible implementation, the stop-loss module 93 is also used to elect a new master database from the slave database if the third judgment result is yes, and to switch the new master database and the master database.

[0176] In one possible implementation, the stop-loss module 93 is also used to prohibit writes to the master database and the proxy server, and elect a new master database based on the slave databases in the database cluster and their corresponding weights; and lift the write ban on the new master database and the proxy server.

[0177] In one possible implementation, the stop-loss module 93 is also used to select a replaceable slave database based on the type and weight of the slave database if the third judgment result is negative.

[0178] In one possible implementation, the database cluster includes a master database, online slave databases, offline slave databases, backup slave databases, subscription slave databases, and redundant slave databases.

[0179] Figure 10 This is a schematic diagram of a terminal provided in an embodiment of the present invention. Figure 10 As shown, the terminal 10 in this embodiment includes: a processor 1001, a memory 1002, and a computer program 1003 stored in the memory 1002 and executable on the processor 1001. When the processor 1001 executes the computer program 1003, it implements the steps in the various database switching method embodiments described above, for example... Figure 3 Steps 301 to 303 are shown. Alternatively, when processor 1001 executes computer program 1003, it implements the functions of each module / unit in the above-described database switching device embodiments, for example... Figure 9 The functions of modules / units 91 to 93 shown.

[0180] The present invention also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the database switching methods provided in the various embodiments described above.

[0181] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0182] The present invention also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and the execution of the executable instructions by the at least one processor causes the device to implement the database switching methods provided in the various embodiments described above.

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

[0184] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A database switching method, characterized in that, include: Actively probe the databases in the database cluster to obtain the first probe results; Based on the first detection result, which includes database anomaly and heartbeat anomaly, when at least one of the database anomaly and heartbeat anomaly occurs, a bypass detection is performed on the database to obtain the second detection result. Based on the second detection result, a stop-loss operation is performed on the database; The step of performing a stop-loss operation on the database based on the second detection result includes: If the switch for the database cluster is turned on, the database cluster is locked, and it is determined whether the database is the primary database, thus obtaining a third determination result. Based on the third judgment result, a stop-loss operation is performed on the database, including: If the third judgment result is yes, a new master database is elected from the slave database, and the new master database and the master database are switched. If the third judgment result is negative, a replacement slave is selected based on the slave's type and weight.

2. The database switching method as described in claim 1, characterized in that, The active probing of databases in the database cluster to obtain the first probing result includes: The database intermediary agent periodically and actively probes the databases in the database cluster; Determine whether the database is the primary database to obtain a first determination result; Based on the first judgment result, the first detection result is obtained.

3. The database switching method as described in claim 2, characterized in that, The first detection result includes at least database anomalies; The process of obtaining the first detection result based on the first judgment result includes: If the first determination result is yes, and the database cannot be written to table data, then the database is determined to be abnormal; If the first determination result is negative, and the database cannot read table data, the database is determined to be abnormal. If the first determination result is yes, the database cannot write table data and the database cannot read table data, thus determining that the database is abnormal; If the first determination result is negative, the database cannot read table data and cannot write files to the disk, thus determining that the database is abnormal.

4. The database switching method as described in claim 2, characterized in that, The first detection result includes at least heartbeat abnormalities; The process of obtaining the first detection result based on the first judgment result includes: If the first determination result is negative, the database cannot read table data, and the database can write files to the disk, thus confirming the heartbeat abnormality.

5. The database switching method as described in claim 1, characterized in that, The step of performing bypass probing on the database based on the first detection result to obtain a second detection result includes: Determine whether the database is the primary database to obtain a second determination result; Based on the second judgment result, the second detection result is determined.

6. The database switching method as described in claim 5, characterized in that, The step of determining the second detection result based on the second judgment result includes: If the second judgment result is negative, determine whether there is a binary storage thread of the slave database in the master database; If there is no binary storage thread for the slave database in the master database, then the absence of a binary storage thread for the slave database in the master database is taken as the second detection result.

7. The database switching method as described in claim 5, characterized in that, The step of determining the second detection result based on the second judgment result includes: If the second judgment result is yes, determine whether the master-slave synchronization between the master database and the slave database is abnormal; If the master-slave synchronization between the master and slave databases is abnormal, the abnormal master-slave synchronization between the master and slave databases will be used as the second detection result.

8. The database switching method as described in claim 1, characterized in that, If the third determination result is yes, a new master database is elected from the slave databases, and a switch is performed between the new master database and the master database, including: Writes to the master database and proxy server are prohibited, and a new master database is elected based on the slave databases in the database cluster and their corresponding weights. Remove the write restriction on the new master database and proxy server.

9. The database switching method as described in claim 1, characterized in that, The database cluster includes a master database, online slave databases, offline slave databases, backup slave databases, subscription slave databases, and redundant slave databases.

10. A database switching device, characterized in that, The apparatus for implementing the database switching method as described in any one of claims 1 to 9, the apparatus comprising: The active probing module is used to actively probe the databases in the database cluster and obtain the first probe results; A bypass detection module is used to perform bypass detection on the database based on the first detection result to obtain a second detection result; The stop-loss module is used to perform stop-loss operations on the database based on the second detection result.

11. A terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the database switching method as described in any one of claims 1 to 9.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the database switching method as described in any one of claims 1 to 9.

Images