Method and storage medium for automatic data recovery of a database cluster

Abstract

The application provides an automatic data recovery method of a database cluster and a storage medium. The automatic data recovery method comprises the following steps: acquiring a master database signal of the database cluster; acquiring a starting point of a redo log stream returned by a switching target database and a terminal point of a redo log stream returned by a switching source database in the case that the switching target database and the switching source database are both normally connected with a trusted gateway; setting a redo recovery point of a backup database; and determining a recovery data area according to the starting point of the redo log stream returned by the switching target database, the terminal point of the redo log stream returned by the switching source database and the redo recovery point of the backup database, so as to realize automatic data recovery.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of databases, and in particular to an automatic data recovery method for a database cluster and a storage medium. BACKGROUND

[0002] Cluster technology is a relatively new technology, through which relatively high benefits in performance, reliability, flexibility, etc. can be obtained at a low cost, and task scheduling is a core technology in a cluster system. A cluster is a group of independent computers interconnected through a high-speed network, which constitutes a group and is managed in a single system mode. When a client interacts with the cluster, the cluster acts as an independent server. Cluster configuration is used to improve availability and scalability.

[0003] In a database master-slave cluster, the master database is the only node that provides complete read and write services to the outside world, and the others are backup databases and can only provide read services. When the master database fails to provide services, failover needs to be performed to enable the backup database to be promoted to the master database to continue providing services. Because the occurrence of failures is uncertain, in order to minimize the impact of the master database failure on the application, automatic failover and automatic data recovery need to be performed.

[0004] Figure 1 FIG. 1 is a schematic diagram of a master-slave cluster deployment architecture in the prior art. It shows a master database 100, a server 200, and a third-party service server 300. In a traditional master-slave cluster deployment architecture, a third-party service (for example, Observer) is introduced, the third-party service is located on a separate server, and is located in the same network partition as the master-slave cluster. All databases and the third-party service establish TCP connections to exchange information.

[0005] In a database cluster, when the master database fails to handle transactions, automatic failover occurs, the backup database is promoted to a new master database to continue handling transactions, and the old master database that failed is restored as a backup database and rejoins the cluster.

[0006] In a traditional database cluster, a third-party service (Observer, arbitration node, etc.) is introduced to perform arbitration, and the master and backup databases establish connections with the third-party service to exchange information.

[0007] Therefore, in the existing database cluster, the third-party service needs to be relied on to complete automatic failover and automatic data recovery, but there is a problem that the third-party service will separately occupy a device, at which time the customer cannot provide an extra device to deploy the third-party service, so that automatic failover and automatic data recovery cannot be achieved.

[0008] Based on the above considerations, how to provide automatic failover and automatic data recovery without third-party services is a technical problem of interest in the art. SUMMARY

[0009] An object of the present application is to provide an automatic data recovery method for a database cluster and a storage medium capable of solving any of the above technical problems.

[0010] A further object of the present application is to implement a data recovery function.

[0011] In particular, the present application provides an automatic data recovery method for a database cluster, the database cluster comprising a primary database, a standby database and a trust gateway, the trust gateway being a gateway device of a network segment where the database cluster is located, the automatic data recovery method comprising:

[0012] obtaining a switching signal of the primary database of the database cluster;

[0013] determining the communication states of the switching target database and the switching source database with the trust gateway, respectively;

[0014] in the case where the communication states of the switching target database and the switching source database with the trust gateway are both normal, obtaining the start point of the redo log stream returned by the switching target database and the end point of the redo log stream returned by the switching source database;

[0015] setting a redo recovery point of the standby database;

[0016] determining a recovery data region according to the start point of the redo log stream returned by the switching target database, the end point of the redo log stream returned by the switching source database and the redo recovery point of the standby database.

[0017] Further, the step of determining the recovery data region according to the start point of the redo log stream returned by the switching target database, the end point of the redo log stream returned by the switching source database and the redo recovery point of the standby database comprises:

[0018] comparing the time sequence relationship of the redo recovery point of the standby database, the start point of the redo log stream returned by the switching target database and the end point of the redo log stream returned by the switching source database;

[0019] determining the recovery data region according to the comparison result.

[0020] Further, the step of determining the recovery data region according to the comparison result comprises:

[0021] If the redo recovery point of the standby database is located between the start point of the redo log stream returned by the target database of the switchover and the end point of the redo log stream returned by the source database of the switchover, it is determined that the area between the start point of the redo log stream returned by the target database of the switchover and the redo recovery point of the standby database is the recovery data area.

[0022] Further, the step of determining the recovery data area according to the comparison result further comprises:

[0023] If the redo recovery point of the standby database is located before the start point of the redo log stream returned by the target database of the switchover, it is determined that the area between the redo recovery point of the standby database and the end point of the redo log stream returned by the source database of the switchover is the recovery data area.

[0024] Further, the step of determining the recovery data area according to the comparison result further comprises:

[0025] If the redo recovery point of the standby database is located after the end point of the redo log stream returned by the source database of the switchover, it is determined that the area between the redo recovery point of the standby database and the end point of the redo log stream returned by the source database of the switchover is the recovery data area.

[0026] Further, the step of determining the area between the start point of the redo log stream returned by the target database of the switchover and the redo recovery point of the standby database as the recovery data area further comprises:

[0027] Flushing the recovery data area into the source database of the switchover.

[0028] Further, the step of flushing the recovery data area into the source database of the switchover further comprises:

[0029] Deleting the data of the source database of the switchover except the recovery data area and the archived redo log.

[0030] Further, the step of deleting the data of the source database of the switchover except the recovery data area and the archived redo log further comprises:

[0031] Configuring the source database of the switchover as the standby database and rejoining the database cluster.

[0032] Further, the step of obtaining the switchover signal of the master database of the database cluster further comprises:

[0033] Obtaining an abnormal event occurring in any other database in the database cluster where the current database is located;

[0034] Obtaining the master-standby state of the current database;

[0035] sending a probe packet to a trust gateway of the database cluster, and confirming the connection state between the current database and the trust gateway according to a response of the trust gateway;

[0036] In the case that the current database is a standby database, if the connection state is normal connection, a switchover signal of a master database of the database cluster is obtained.

[0037] According to another aspect of the present application, there is also provided a machine readable storage medium having stored thereon a machine executable program which, when executed by a processor, implements any of the above automatic data recovery methods for a database cluster.

[0038] The automatic data recovery method for a database cluster of the present application, the database cluster comprising a master database, a standby database and a trust gateway, the trust gateway being a gateway device of a network segment where the database cluster is located, the automatic data recovery method comprising: obtaining a switchover signal of the master database of the database cluster; determining connection states between the switchover target database and the switchover source database and the trust gateway; in the case that the connection states between the switchover target database and the switchover source database and the trust gateway are normal, obtaining a start point of a redo log stream returned by the switchover target database and an end point of a redo log stream returned by the switchover source database; setting a redo recovery point of the standby database; determining a recovery data region according to the start point of the redo log stream returned by the switchover target database, the end point of the redo log stream returned by the switchover source database and the redo recovery point of the standby database, so as to realize an automatic data recovery function.

[0039] The above and other objects, advantages and features of the present application will become more apparent from the following detailed description of some embodiments thereof, when taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0040] Some embodiments of the present application will be described in detail with reference to the drawings, wherein the same or like components have the same reference numerals, and wherein:

[0041] Figure 1 is a schematic diagram of a master-standby cluster deployment architecture in the prior art;

[0042] Figure 2 is a schematic architecture diagram of an automatic data recovery method for a database cluster according to an embodiment of the present application;

[0043] Figure 3 is a step flowchart of an automatic data recovery method for a database cluster according to an embodiment of the present application;

[0044] Figure 4is a flow chart of a step of determining a data recovery area in an automatic data recovery method of a database cluster according to an embodiment of the present application;

[0045] Figure 5 is a schematic diagram of determining a data recovery area in a first case in an automatic data recovery method of a database cluster according to an embodiment of the present application;

[0046] Figure 6 is a schematic diagram of determining a data recovery area in a second case in an automatic data recovery method of a database cluster according to an embodiment of the present application;

[0047] Figure 7 is a schematic diagram of determining a data recovery area in a third case in an automatic data recovery method of a database cluster according to an embodiment of the present application;

[0048] Figure 8 is a flow chart of a step of recovering data of a switchover source database in an automatic data recovery method of a database cluster according to an embodiment of the present application;

[0049] Figure 9 is a flow chart of a step of acquiring a switchover signal of a master database of a database cluster in an automatic data recovery method of a database cluster according to an embodiment of the present application;

[0050] Figure 10 is a schematic flow chart of an automatic data recovery method of a database cluster according to an embodiment of the present application in a case where a current database is a master database;

[0051] Figure 11 is a schematic flow chart of an automatic data recovery method of a database cluster according to an embodiment of the present application in a case where a current database is a standby database; and

[0052] Figure 12 is a schematic diagram of a machine readable storage medium according to an embodiment of the present application. DETAILED DESCRIPTION

[0053] Figure 2 is a schematic architecture diagram of an automatic data recovery method of a database cluster according to an embodiment of the present application. The architecture of the database cluster of the present application comprises a master database server 100, a standby database server 200 and a trust gateway 400. The trust gateway 400 is a gateway device of a network segment where the database cluster is located. The gateway device is a router or a switch. The database cluster first identifies any gateway device in the network segment where the database cluster is located as the trust gateway 400, and the master database and the standby database both rely on the trust gateway 400 for interaction. Once it is found in the subsequent check that the connection with the trust gateway 400 is disconnected, i.e. simultaneously disconnected with all other devices in the network.

[0054] The database cluster regards the existing device in the network segment as the trusted gateway 400, provides the IP or host of the trusted gateway 400, and then all databases in the database cluster send an ICMP (Internet Control Message Protocol) message to the trusted gateway 400 through ping and judge the connection state with the trusted gateway 400 through the message returned. When a normal response message is returned by ping, the trusted gateway 400 is a normal response at this time. When an error message is returned by ping, the trusted gateway 400 is an abnormal response at this time. When timeout information is returned by ping, the trusted gateway 400 is a timeout response at this time. When no message is received by ping, the trusted gateway 400 is a non-response at this time. In the case that the response of the trusted gateway 400 is a normal response, it is determined that the connection state is a normal connection; in the case that the response of the trusted gateway 400 is an abnormal response, it is determined that the connection state is a connection exception.

[0055] After automatic failover, no third-party service is available, and no data recovery can be performed through a command such as a database recovery and start / stop command. Therefore, an automatic recovery module needs to be introduced, that is, a module is added in cluster management software, and data recovery is performed through a recovery command and a recovery point to complete automatic recovery operation.

[0056] A configuration item reinstatement_enable_flag is added in cluster and management software, which is used to open or close the automatic recovery data function and takes a value of 1 or 0. The automatic recovery module sets the configuration item to 1, indicating that automatic recovery data is needed. The automatic recovery module sends a command EINSTATE-ENABLE to the target database, and specifies the source database to be recovered.

[0057] Figure 3 FIG. 1 is a step flow chart of an automatic data recovery method of a database cluster according to an embodiment of the present application. As shown in FIG. 1, the steps of the automatic data recovery method of the database cluster include: Figure 3

[0058] In step S302, a switchover signal of a master database of the database cluster is acquired.

[0059] In step S304, connection states of a target database and a source database with a trusted gateway are determined.

[0060] ​Step S306: Assuming both the target database and the source database have normal connectivity with the trusted gateway, obtain the starting point of the redo log stream returned by the target database and the ending point of the redo log stream returned by the source database. After a normal connection is established, the automatic recovery module sends a STARUP command to start the target database. Once the target database is running normally, it sends a NEW-REINSTATE-ENABLE recovery command to the target database. Upon receiving the recovery command, the target database returns the starting point of the redo log stream to the automatic recovery module. Similarly, the STARUP command is sent to the source database. Once the source database is running normally, it sends an OLD-REINSTATE-ENABLE recovery command to the source database. Upon receiving the recovery command, the source database returns the ending point of the redo log stream to the automatic recovery module.

[0061] Step S308: Set the redo recovery point for the backup database.

[0062] Step S310: Determine the recovery data area based on the starting point of the redo log stream returned by the target database, the ending point of the redo log stream returned by the source database, and the redo recovery point of the backup database.

[0063] Figure 4 This is a flowchart of the steps for determining the data recovery area in an automatic data recovery method for a database cluster according to an embodiment of the present invention. Figure 5 This is a schematic diagram illustrating the determination of a data recovery area in a first case of an automatic data recovery method for a database cluster according to an embodiment of the present invention. Figure 6 This is a schematic diagram illustrating the determination of the data recovery area in a second scenario within an automatic data recovery method for a database cluster according to an embodiment of the present invention. Figure 7 This is a schematic diagram illustrating the determination of the data recovery area in a third scenario within an automatic data recovery method for a database cluster according to an embodiment of the present invention. Figures 4-7 As shown, the automatic data recovery method for a database cluster in this embodiment includes the following steps for determining the recovery data area based on the starting point of the redo log stream returned by the target database, the ending point of the redo log stream returned by the source database, and the redo recovery point of the backup database:

[0064] Step S402: Compare the timing relationship between the redo recovery point of the backup database and the start point of the redo log stream returned by the target database and the end point of the redo log stream returned by the source database. Determine the recovery data area based on the comparison results.

[0065] Step S404, if the redo recovery point of the standby database is located between the start point of the redo log stream returned by the target database and the end point of the redo log stream returned by the source database, step S410 is performed.

[0066] Step S410, the area between the start point of the redo log stream returned by the target database and the redo recovery point of the standby database is determined as the recovery data area.

[0067] Step S406, if the redo recovery point of the standby database is located before the start point of the redo log stream returned by the target database, step S412 is performed.

[0068] Step S408, if the redo recovery point of the standby database is located after the end point of the redo log stream returned by the source database, step S412 is performed.

[0069] Step S412, the area between the redo recovery point of the standby database and the end point of the redo log stream returned by the source database is determined as the recovery data area.

[0070] Figure 8 FIG. 6 is a flowchart of a step of recovering data of a source database in an automatic data recovery method of a database cluster according to an embodiment of the present application. As shown in FIG. 6, the step of recovering data of the source database in the automatic data recovery method of the database cluster according to the embodiment of the present application includes: Figure 8

[0071] Step S502, the recovery data area is flushed into the source database.

[0072] Step S504, data of the source database except the recovery data area and the archived redo log are deleted.

[0073] Step S506, the source database is configured as a standby database and re-joins the database cluster.

[0074] Figure 9 FIG. 5 is a flowchart of a step of obtaining a switchover signal of a master database of a database cluster in an automatic data recovery method of the database cluster according to an embodiment of the present application. As shown in FIG. 5, the step of obtaining the switchover signal of the master database of the database cluster in the automatic data recovery method of the database cluster according to the embodiment of the present application includes: Figure 9

[0075] ​​Step S602: Obtain information about any abnormal event occurring in any other database within the cluster where the current database resides. Abnormal events include the discovery of a failure in any other database within the cluster and the inability of any other database in the cluster to synchronize data with the current database. The current database is a database within the database cluster. The current database can be either the primary database or a backup database.

[0076] Step S604: Obtain the current master / slave status of the database. Master / slave status refers to whether the current database is the master database or the slave database.

[0077] Step S606: Send a probe message to the trust gateway of the database cluster, and confirm the current connectivity status between the database and the trust gateway based on the response from the trust gateway.

[0078] A trusted gateway can be a gateway device on the network segment where the database cluster resides. This gateway device can be a router or a switch; no modifications are required, only its IP address needs to be provided. The trusted gateway's response can include both normal and fault responses.

[0079] Fault responses can include error responses, timeout responses, and no response. A database cluster can use existing devices on the local network segment as trusted gateways. After providing the trusted gateway's IP address or host, all databases within the cluster will send ICMP packets to the trusted gateway via ping and use the packet response to determine their connectivity status. If the ping returns a normal response packet, the trusted gateway is responding normally. If the ping returns an error packet, the trusted gateway is responding incorrectly. If the ping returns a timeout message, the trusted gateway is responding with a timeout. If the ping times out and no packets are received, the trusted gateway is not responding. A normal response from the trusted gateway indicates normal connectivity; an abnormal response indicates a connection failure.

[0080] Step S608: Perform fault handling operations corresponding to the primary / standby status based on the connectivity status.

[0081] In other embodiments, when no abnormal events are found in the current database, a network check is performed at preset intervals to determine whether the device's network is experiencing problems and has disconnected from other databases, resulting in an incorrect judgment.

[0082] Figure 10 This is a schematic flowchart illustrating an automatic data recovery method for a database cluster according to an embodiment of the present invention, in the case where the current database is the primary database. Figure 10 As shown, the automatic data recovery method for a database cluster in this embodiment includes the following steps: performing fault handling operations corresponding to the primary / standby status based on the connectivity status.

[0083] Step S702, confirming that the current database is the master database.

[0084] Step S704, confirming the connection state of the current database and the trust gateway. When the connection state is normal connection, step S706 is performed. When the connection state is connection abnormality, step S708 is performed.

[0085] Step S706, removing the other database from the database cluster to obtain a switching signal of the master database of the database cluster.

[0086] Step S708, closing the current database.

[0087] When the synchronization between the current database (master database) and the other database (standby database) is interrupted, it is initially judged that the other database (standby database) is faulty, and the trust gateway detection is performed simultaneously. When the connection state is connection abnormality, it is judged that the local network is faulty, and the current database (master database) is closed. The other database can be selected to promote to the master database to obtain the master database switching signal.

[0088] When the synchronization between the current database (master database) and the other database (standby database) is interrupted, it is initially judged that the other database (standby database) is faulty, and the trust gateway detection is performed simultaneously. When the connection state is connection normality, no state change is performed on the current database, and the faulty other database (standby database) is tried to be kicked out of the cluster.

[0089] Figure 11 is a schematic flowchart of an automatic data recovery method of a database cluster according to an embodiment of the present application in the case where the current database is a standby database. As shown in Figure 10 the automatic data recovery method of the database cluster in the embodiment includes the following steps of performing a fault handling operation corresponding to the master-standby state according to the connection state:

[0090] Step S802, confirming that the current database is the standby database.

[0091] Step S804, confirming the connection state of the current database and the trust gateway. When the connection state is normal connection, step S806 is performed. When the connection state is connection abnormality, step S808 is performed.

[0092] Step S806, setting the current database as the master database to obtain a switching signal of the master database of the database cluster.

[0093] Step S808, downgrading the current database to an abnormal mode and trying to kick the current database out of the database cluster. The current database is downgraded to avoid affecting the normal operation of the other databases of the database cluster.

[0094] When synchronization between the current database (standby database) and other databases (primary database) is interrupted, the initial assessment is that the other database (primary database) is faulty. Simultaneously, a trust gateway check is performed, and the connectivity status is normal. Automatic failover is executed, the current database is promoted to primary database, and a primary database switchover signal is received.

[0095] When synchronization between the current database (standby database) and other databases (primary database) is interrupted, the initial assessment is that the other database (primary database) is faulty. Simultaneously, a trust gateway check is performed; if the connectivity status shows an abnormal connection, the fault is determined to be a local network failure. Automatic failover cannot be performed, the current database is downgraded to an abnormal mode, and attempts to remove itself from the cluster. Furthermore, no further fault handling can be performed; only the operation of the database cluster is guaranteed.

[0096] As shown in Table 1, the comparison of the three schemes demonstrates the effectiveness of the automatic data recovery method (Scheme ③) for the database cluster in this embodiment. Scheme ①: Primary and backup database clusters with automatic failover functionality. Scheme ②: Primary and backup database clusters and third-party services (observer or arbitrator node) with automatic failover functionality. Scheme ③: Primary and backup database clusters, trusted gateway, and automatic recovery module with automatic failover functionality.

[0097] Table 1

[0098]

[0099] As shown in the table above, the automatic data recovery method for the database cluster in this embodiment can prevent split-brain compared to the primary / standby cluster in scheme ①. Compared to scheme ②, the automatic data recovery method for the database cluster in this embodiment adds a trusted gateway and an automatic recovery module, enabling data recovery even without third-party services.

[0100] This embodiment also provides a machine-readable storage medium and a computer device. Figure 12 This is a schematic diagram of a machine-readable storage medium according to an embodiment of the present invention.

[0101] The machine-readable storage medium 40 stores a machine-executable program 41 thereon, which, when executed by a processor, implements the automatic data recovery method for the database cluster of any of the above embodiments.

[0102] Computer device 50 may include memory 520, processor 510, and machine-executable program 41 stored on memory 520 and running on processor 510. When processor 510 executes machine-executable program 41, it implements the automatic data recovery method of database cluster of any of the above embodiments.

[0103] It is to be appreciated that the logical and / or steps represented in the flow diagrams, or otherwise described herein, can be considered as a list of executable instructions for implementing logic functions, and can be specifically embodied in any machine-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions, or in conjunction with which the instructions can be executed.

[0104] For the description of the present embodiment, the machine-readable storage medium 40 can be any device that can contain, store, communicate, propagate or transport the program for use by or in connection with the instruction execution system, apparatus or device, or in conjunction with which the instruction execution system, apparatus or device is used. More specific examples (non-exhaustive list) of computer-readable medium include the following: electrical connection having one or more wires (electronic devices), portable computer diskette (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), fiber optic device, and portable compact disc read-only memory (CDROM). In addition, the computer-readable medium 40 can even be paper or other suitable medium on which the program can be printed, as the program can be electronically obtained, for example, by optical scanning of the paper or other medium, followed by electronic conversion, interpretation or processing, if necessary, in other suitable manner, and then stored in the computer memory.

[0105] It should be understood that parts of the present application can be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, a plurality of steps or methods can be implemented by software or firmware stored in the memory and executed by a suitable instruction execution system.

[0106] The flowcharts provided by the present embodiment are not intended to indicate that the operations of the methods will be executed in any particular order, or that all of the operations included in the methods will be included in every case. In addition, the methods can include additional operations. Additional changes can be made to the above-described methods within the scope of the technical ideas provided by the present embodiment.

[0107] So far, those skilled in the art should recognize that although the present application has been shown and described in detail in the above embodiments, many other variations or modifications can be directly determined or deduced from the disclosure of the present application according to the principles of the present application without departing from the spirit and scope of the present application. Therefore, the scope of the present application should be understood and recognized as covering all these other variations or modifications.

Claims

1. An automatic data recovery method of a database cluster, the database cluster comprising a master database, a standby database and a trust gateway, the trust gateway being a gateway device of a network segment where the database cluster is located, the automatic data recovery method comprising: obtaining a switchover signal of a master database of the database cluster; determining a communication state of a switchover target database and a switchover source database with the trust gateway; obtaining a start point of a redo log stream returned by the switchover target database and an end point of a redo log stream returned by the switchover source database in a case that the communication state of the switchover target database and the switchover source database with the trust gateway is normal; setting a redo recovery point of the standby database; comparing a time sequence relationship of the redo recovery point of the standby database, the start point of the redo log stream returned by the switchover target database and the end point of the redo log stream returned by the switchover source database; determining a recovery data area according to a comparison result; the step of determining the recovery data area according to the comparison result comprises: determining the start point of the redo log stream returned by the switchover target database and the redo recovery point of the standby database as the recovery data area if the redo recovery point of the standby database is located between the start point of the redo log stream returned by the switchover target database and the end point of the redo log stream returned by the switchover source database; determining the redo recovery point of the standby database to the end point of the redo log stream returned by the switchover source database as the recovery data area if the redo recovery point of the standby database is located before the start point of the redo log stream returned by the switchover target database; and determining the redo recovery point of the standby database to the end point of the redo log stream returned by the switchover source database as the recovery data area if the redo recovery point of the standby database is located after the end point of the redo log stream returned by the switchover source database. The step of determining the start point of the redo log stream returned by the switchover target database and the redo recovery point of the standby database as the recovery data area further comprises: flushing the recovery data area into the switchover source database. The step of flushing the recovery data area into the switchover source database further comprises: deleting data of the switchover source database except the recovery data area and archived redo logs. The step of deleting the data of the switchover source database except the recovery data area and the archived redo logs further comprises: configuring the switchover source database as the standby database and rejoining the database cluster. The step of obtaining the switchover signal of the master database of the database cluster further comprises: obtaining an abnormal event of any other database in the database cluster where a current database is located; obtaining a master-standby state of the current database. ​ ​ ​ ​ ​ 2. The automatic data recovery method of claim 1, wherein, ​ ​ 3. The automatic data recovery method of claim 2, wherein, ​ ​ 4. The automatic data recovery method of claim 3, wherein, ​ ​ 5. The automatic data recovery method of claim 1, wherein, ​ ​ ​ sending a probe packet to a trust gateway of the database cluster, and confirming a communication state between the current database and the trust gateway according to a response of the trust gateway; if the current database is a standby database and the communication state is normal communication, obtaining a switching signal of a master database of the database cluster. 6.A machine readable storage medium having stored thereon a machine executable program which, when executed by a processor, implements the automatic data recovery method of the database cluster according to any one of claims 1 to 5.

Images