A database cluster management method and device, and computer-readable storage medium

Abstract

The embodiment of the present invention discloses a database cluster management method and device, and a computer-readable storage medium, which can achieve high availability of the database cluster. The method is applied to the database cluster, and is characterized in that a first monitoring module and a first recovery module are configured on a first host. The method includes: when the first database is the main database and the second database is the backup database, and the first monitoring module detects an abnormality in the first database, the first monitoring module transfers the data service of the first database to the second database to use the second database as the main database; when the first monitoring module detects that the first database meets the preset recovery conditions, the first recovery module performs differential repair on the data in the first database based on the current data difference between the first database and the second database, so that the data in the first database and the second database are restored to synchronization.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a database cluster management method and device, and a computer-readable storage medium. Background Art

[0002] As databases become increasingly widely used, high availability of database clusters needs to be considered before they are officially deployed in production systems. Traditional high-availability solutions for database clusters are often based on streaming replication. This approach requires operations personnel to log in to the system and perform repairs when data anomalies occur in the database cluster. This carries the risk of reduced high availability due to operations personnel being unable to restore the database in a timely manner. Furthermore, if an anomaly occurs in the primary database in a database cluster, a base backup must be manually pulled from the new primary database to serve as the new backup database. This backup process is extremely time-consuming and resource-intensive, impacting system performance and further reducing the high availability of the database cluster. Summary of the Invention

[0003] Embodiments of the present invention are intended to provide a database cluster management method and apparatus, and a computer-readable storage medium, which can improve the high availability of a database cluster.

[0004] The technical solution of the present invention is achieved as follows:

[0005] An embodiment of the present invention provides a database cluster management method, which is applied to a database cluster. The database cluster includes at least a first database configured on a first host and a second database configured on a second host, the first host and the second host being interconnected via a network; the first host being configured with a first monitoring module and a first recovery module. The method includes:

[0006] When the first database is the primary database and the second database is the backup database, and the first monitoring module detects an abnormality in the first database, the first monitoring module transfers the data service of the first database to the second database, so that the second database serves as the primary database;

[0007] When the first monitoring module detects that the first database meets the preset recovery conditions, the first recovery module performs differential repair on the data in the first database based on the current data difference between the first database and the second database, so as to restore the data in the first database to synchronization with the data in the second database.

[0008] An embodiment of the present invention provides a database cluster management device, which is applied to a database cluster. The database cluster includes at least a first database configured on a first host and a second database configured on a second host, wherein the first host and the second host are interconnected via a network. The device includes: a first monitoring module and a first recovery module configured on the first host, wherein:

[0009] The first monitoring module is configured to, when the first database is a primary database and the second database is a backup database, transfer data services of the first database to the second database upon detecting an abnormality in the first database, so as to make the second database the primary database;

[0010] The first recovery module is used to perform differential repair on the data in the first database based on the current data difference between the first database and the second database when the first monitoring module monitors that the first database meets the preset recovery conditions, so as to restore the data in the first database to synchronization with the data in the second database.

[0011] An embodiment of the present invention provides a database cluster management device, comprising: a processor, a memory, and a communication bus. The memory communicates with the processor via the communication bus. The memory stores one or more computer programs executable by the processor. When the one or more computer programs are executed, the processor executes any of the database cluster management methods described above.

[0012] An embodiment of the present invention provides a computer-readable storage medium storing one or more computer programs. The one or more computer programs can be executed by one or more processors. When the computer programs are executed by the processors, the database cluster management method as described in any one of the above items is implemented.

[0013] An embodiment of the present invention provides a database cluster management method and device, and a computer-readable storage medium. The method is applied to a database cluster, where the database cluster includes at least a first database configured on a first host and a second database configured on a second host, the first host and the second host being interconnected via a network; a first monitoring module and a first recovery module are configured on the first host, and the method includes: when the first database is a primary database and the second database is a backup database, and the first monitoring module detects an abnormality in the first database, the first monitoring module transfers the data service of the first database to the second database to use the second database as the primary database; when the first monitoring module detects that the first database meets preset recovery conditions, the first recovery module performs differential repair on the data in the first database based on the current data difference between the first database and the second database, so that the data in the first database and the second database are restored to synchronization. By adopting the method provided by the embodiment of the present invention, when a failure occurs in the first database serving as the master database, the database cluster management device can perform differential repair on the data in the first database based on the data difference between the first database and the second database, thereby reducing the amount of data that needs to be pulled from the new master database each time the original master database is repaired, improving the repair efficiency, shortening the time during which the database in the database cluster is unavailable, improving the high availability of the database cluster, and simultaneously realizing automatic repair of the failure of the first database, i.e., the original master database, further improving the high availability of the database cluster. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A schematic diagram of the structure of a data cluster management system provided by an embodiment of the present invention;

[0015] Figure 2 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0016] Figure 3 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0017] Figure 4 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0018] Figure 5 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0019] Figure 6 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0020] Figure 7A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0021] Figure 8 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0022] Figure 9 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0023] Figure 10 A schematic diagram of an optional flow chart of a data cluster management method provided in an embodiment of the present invention;

[0024] Figure 11 A schematic diagram of an optional structure of a data cluster management device provided by an embodiment of the present invention;

[0025] Figure 12 This is a schematic diagram of an optional structure of a data cluster management device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0026] The technical solutions in the embodiments of the present invention will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present invention.

[0027] The embodiment of the present invention provides a database cluster management method, which is applied to a data cluster management system, such as Figure 1 As shown, the database cluster management system 10 includes a high-availability module 11, a gateway 12, a first host 13, a second host 14, a first database 130 and a first self-test program 131 running on the first host 13, and a second database 140 and a second self-test program 141 running on the second host 14. The first host 13 and the second host 14 are interconnected via the gateway 12. The first database 130 operates as the primary database, responding to read and write requests from clients 20 to the database cluster management system 10 through the high-availability module 11 and providing data services to the clients 20. The second database 140 operates as a standby database, backing up the data stored in the primary database, i.e., the first database 130, through synchronous streaming replication, and acting as a read-only server to provide data access services to clients through the high-availability module 11. The high-availability module 11 is deployed on both the first host 13 and the second host 14 to provide address migration functionality. Specifically, the high availability module 11 provides a virtual IP address (VIP) bound to the primary database to the application on the client 20 to access the first database 130. When an exception occurs in the first database 130, the VIP automatically drifts to the second host 14, and the high availability module of the second host 14 provides the VIP for application access, so that the application is unaware of the switching between the primary and standby databases.

[0028] In this embodiment of the present invention, the first self-test program 131 on the first host 13 includes a first monitoring module 1310 and a first recovery module 1311. The second self-test program 141 on the second host 14 includes a second monitoring module 1410 and a second recovery module 1411. The first monitoring module 1310 is used to regularly check the health of the first and second databases 130, 140 and whether the first host 13's network can properly connect to the gateway 12. The second monitoring module 1410 is used to regularly check the health of the first and second databases 130, 140 and whether the second host 14's network can properly connect to the gateway 12, thereby determining whether the networks of the first and second hosts 13, 14 are functioning properly and preventing a split-brain situation. When an exception occurs in the first database 130, the first monitoring module 1310 disables the high-availability module of the first host 13, automatically migrating the VIP to the second host 14. The second database 140 becomes the new primary database, and the high-availability module on the second host 14 takes over the data services corresponding to the client 20. At the same time, first monitoring module 1310 continuously monitors whether first database 130 is ready for recovery. When the conditions are met, first recovery module 1311 is invoked to restore first database 130, allowing first database 130 to be added to the database cluster as a backup database for second database 140, thereby automatically achieving high availability. If an exception occurs in second database 140, second recovery module 1411 is invoked to restore second database 140, allowing it to serve as a backup database again.

[0029] It should be noted that, in the embodiment of the present invention, the database cluster management system 10 may include at least two hosts, namely Figure 1 In addition to the first host 13 and the second host 14, other hosts may also be included as backup hosts for the first host 13, for running backup databases of the first database 130. If the first database 130 has multiple backup databases, when an exception occurs in the first database 130, the corresponding target backup database is selected as the new primary database based on the priority of each backup database, thereby completing the database cluster management method of the embodiment of the present invention.

[0030] Figure 2 This is an optional flow chart of the database cluster management method provided by the embodiment of the present invention, which will be combined with Figure 2 The steps shown are explained.

[0031] S101. When a first database is a primary database and a second database is a backup database, and a first monitoring module detects an abnormality in the first database, the first monitoring module transfers data services of the first database to the second database, so that the second database serves as the primary database.

[0032] In this embodiment of the present invention, when a database cluster management device provides data services through a first database, the first database is considered the currently running primary database. Therefore, the database cluster management device can use a second database as a backup database and synchronize data stored in the first database with the second database through real-time streaming replication.

[0033] In an embodiment of the present invention, the database cluster management device can use a synchronous backup method to perform data backup. Specifically, when using synchronous backup, since real-time streaming replication is based on transactions, the primary database will wait for the standby database to return the transaction status, such as whether the transaction was successfully backed up, before completing the current transaction. This method ensures that every piece of data in the primary database is successfully backed up to the standby database, preventing data loss in the event of a primary database failure. However, if a standby database fails, the primary database will be suspended while waiting for feedback and unable to continue writing data, impacting the normal operation of the primary database. Alternatively, the database cluster management device can also use an asynchronous method to perform data backup. Specifically, when using the standby database to back up data from the primary database, the primary database does not wait for the standby database to return the transaction status after submitting the transaction to be backed up to the standby database. This method ensures that if a standby database fails, the primary database will not be blocked and its operation will not be affected, but there may be a risk of data loss. In actual applications, the appropriate data backup method can be selected based on actual circumstances, and the embodiments of the present invention do not limit it.

[0034] In some embodiments, the database cluster management device can use the second database to back up the write-ahead logging (Wal) log in the first database, or it can back up other types of logs such as redo logs or other types of archived data. The specific selection is made according to actual conditions and is not limited in the embodiments of the present invention.

[0035] In an embodiment of the present invention, when the first monitoring module detects that an abnormality has occurred in the first database, indicating that the first database can no longer provide services to the client normally, the database cluster management device transfers the data service of the first database to the second database through the first monitoring module, so that the second database can continue to provide services to the client as the new primary database, maintain high availability, and at the same time keep monitoring the first database.

[0036] In an embodiment of the present invention, the database cluster management device can collect status information and network information of the first database through the first monitoring module to monitor the first database. The database cluster management device analyzes the status information and network information collected by the first monitoring module to determine whether an abnormality occurs in the first database.

[0037] In some embodiments, the first database is bound to the VIP through the keepalived service to provide data services to the client through the VIP. When it is determined that an abnormality has occurred in the first database, the database cluster management device can stop the keepalived service on the first host through the first monitoring module, so that the VIP automatically drifts to the second host, and the high availability module of the second host automatically takes over the client's data service. The application on the client can switch to the second database through the VIP without perception to access and read and write data, thereby realizing the transfer of the data service of the first database to the second database.

[0038] In an embodiment of the present invention, after the database cluster management device transfers the data service of the first database to the second database, it will continue to monitor the first database through the first monitoring module, so that the first database can be enabled and rejoined to the database cluster in time when the conditions for returning to normal are met.

[0039] S102. When the first monitoring module detects that the first database meets the preset recovery conditions, the first recovery module performs differential repair on the data in the first database based on the current data difference between the first database and the second database, so as to restore the data in the first database to synchronization with the data in the second database.

[0040] In an embodiment of the present invention, when the database cluster management device monitors through the first monitoring module that the first database that previously experienced an abnormality has again met the preset recovery conditions, the database cluster management device can repair the first database through the first recovery module, so that it is re-joined to the database cluster as a new primary database, that is, a backup database of the second database, to improve the high availability of the database cluster.

[0041] In this embodiment of the present invention, the second database continues to serve as the primary database, providing data services from the time the first database experiences an anomaly until the preset recovery conditions are met. Therefore, when the first database detects that the preset recovery conditions have been met, the data currently stored in the first database and the data currently stored in the second database may have already differed. Therefore, the database cluster management device must, based on the data differences between the first and second databases, repair the data in the first database to ensure consistency with the data in the second database, thereby maintaining synchronization between the first and second databases.

[0042] In an embodiment of the present invention, the database cluster management device can find the node where data differences occur between the first database and the second database by comparing the timelines of the work logs of the first database and the second database, roll back the data in the first database based on the node, and then perform differential synchronization based on the data in the first database after the rollback and the data in the second database, thereby completing the differential repair of the data in the first database.

[0043] In an embodiment of the present invention, when the database cluster management device finds that the data in the first database is completely consistent with the data in the second database by comparing the timelines of the work logs of the first database and the second database, the first database can be directly used as a backup database for the second database without modifying the data in the first database.

[0044] In some embodiments, the database cluster management device may perform differential repair on the data in the first database through the pg_rewind tool. The pg_rewind tool can copy only the changed blocks in the data file without reading the unchanged blocks in the database. Other tools with differential repair functions may also be used. The specific selection is made according to actual conditions and is not limited in the embodiments of the present invention.

[0045] In an embodiment of the present invention, after the database cluster management device completes the repair of the first database, it can restart the first database as a standby database for the second database, so that the first database can continue to synchronize the changed data in the second database on the basis of the initial data state being synchronized, thereby completing the database cluster management.

[0046] In some embodiments, the first recovery module may configure the first database as a standby database by modifying the recovery.conf file in the first database, and start the first database to make the first database a standby database for the second database.

[0047] It can be understood that in the embodiment of the present invention, when the first database serving as the master database fails, the database cluster management device can perform differential repair on the data in the first database based on the data difference between the first database and the second database, thereby reducing the amount of data that needs to be pulled from the new master database each time the original master database is repaired, improving the repair efficiency, shortening the time that the database in the database cluster is unavailable, improving the high availability of the database cluster, and at the same time realizing automatic repair of the failure of the first database, i.e., the original master database, further improving the high availability of the database cluster.

[0048] In the embodiment of the present invention, based on Figure 2 , S102 can be Figure 3 As shown, including S1021-S1024, as follows:

[0049] S1021. Obtain first archived data in the first database and second archived data in the second database; the first archived data is the data archived at the current time point in the first database; the second archived data is the data archived at the current time point in the second database.

[0050] In an embodiment of the present invention, when the database cluster management device monitors through the first monitoring module that the first database meets the preset recovery conditions, it will obtain the data archived in the first database at the current time point as the first archived data, and obtain the data archived in the second database at the current time point as the second archived data.

[0051] In the embodiment of the present invention, the database cluster management device determines the data difference between the first database and the second database based on the comparison between the first archived data and the second archived data.

[0052] In the embodiment of the present invention, the first archived data and the second archived data may be wal logs in the first database and the second database respectively, and the wal logs store records of each data modification in the first database or the second database.

[0053] S1022. Compare, by means of the first recovery module, whether there is a divergence point between the first archived data and the second archived data; the divergence point is a node where the first archived data and the second archived data differ on the timeline.

[0054] In the embodiment of the present invention, the database cluster management device compares the time lines of the first archived data and the second archived data through the first recovery module to determine whether there is a divergence point between the first archived data and the second archived data.

[0055] In an embodiment of the present invention, since the second database, as the master database, may have performed some data read and write transactions during the period from when an exception occurs in the first database and the data service is transferred to the second database until it is detected that the first database has re-met the preset recovery conditions, the archived data of the second database and the first database after a certain point in time are no longer the same, and therefore, the database cluster management device needs to compare the timelines of the first archived data and the second archived data to find the divergence point between the first archived data and the second archived data.

[0056] In an embodiment of the present invention, a divergence point is a node where a difference occurs on the timeline between the first archived data and the second archived data, indicating that from the divergence point onwards, the timelines of the first database and the second database have deviated, the first database and the second database are no longer synchronized, and the data after the divergence point in the first archived data also differs from the data after the divergence point in the second archived data.

[0057] S1023. When a divergence point exists, determine the closest consistency point between the first archived data and the second archived data; the closest consistency point is the node in the first archived data that is closest to the time point of consistency with the second archived data before the divergence point.

[0058] In an embodiment of the present invention, when a divergence point exists, the database cluster management device needs to further determine the most recent consistency point between the first archived data and the second archived data, and use the most recent consistency point as a reference node for restoring the first archived data.

[0059] In this embodiment of the present invention, the most recent consistency point is the node in the first archived data that is most consistent with the second archived data before the divergence point. This represents the last node on the timeline at which the first and second archived data are consistent. In other words, from the perspective of the timeline, the first and second archived data are consistent from the start of the timeline to the most recent consistency point.

[0060] It should be noted that there are many kinds of abnormal situations in which the first database may occur. When the first database itself is not faulty but the network connected to the first database is abnormal, the client's data request cannot be submitted to the first database from the time of the network abnormality. Then the last node of the timeline of the first archived data is the most recent consistency point; when the network connected to the first database is normal and an abnormality occurs inside the first database, before the database cluster management device drifts the VIP to the second database, some client data requests may still be submitted to the first database and archived by the first database, resulting in the archived data of the first database and the second database being no longer synchronized after the divergence point.

[0061] S1024. Recover and synchronize the first database based on the most recent consistency point, thereby completing differential repair of the first database.

[0062] In the embodiment of the present invention, the database cluster management device updates the first archived data based on the latest consistency point, so that the updated data in the first database can be consistent with the second archived data.

[0063] In the embodiment of the present invention, S1024 can be implemented through S201-S202 as follows:

[0064] S201: Restore the timeline of the first archived data to the most recent consistency point to obtain intermediate archived data.

[0065] In the embodiment of the present invention, the database cluster management device first rolls back the first archived data to the most recent consistency point on the timeline, which is equivalent to discarding data content in the first archived data that is inconsistent with the second archived data, thereby obtaining intermediate archived data.

[0066] In some embodiments, the database cluster management device may roll back the first archived data to the most recent consistency point using the pg_rewind tool.

[0067] S202: Synchronize the data after the most recent consistency point in the second archived data to the timeline after the intermediate archived data, thereby achieving differential repair of the first database.

[0068] In an embodiment of the present invention, since the intermediate archived data lacks data after the most recent consistency point in the second archived data compared to the second archived data, the database cluster management device continues to synchronize the data after the most recent consistency point in the second archived data after the timeline of the intermediate archived data. In this way, the data in the first database can be kept consistent with the data in the second database, and the differential repair of the first database can be completed, so that the first database can rejoin the database cluster in a synchronized state, thereby completing the management of the database cluster.

[0069] In the embodiment of the present invention, based on Figure 3 , after S1022, S1025 may also be included, as follows:

[0070] S1025: When there is no divergence point, the first archived data is not restored.

[0071] In the embodiment of the present invention, when there is no divergence point, it indicates that the first archived data and the second archived data are originally consistent, and the database cluster management device does not need to roll back or restore the first archived data.

[0072] It is understood that in this embodiment of the present invention, the database cluster management device can restore the first archived data to the most recent consistency point before synchronizing it with the second archived data. In other words, when repairing the first database, the database cluster management device only needs to synchronize the data in the second archived data after the most recent consistency point. This reduces the amount of data required to be pulled from the new primary database each time the original primary database is repaired, improving repair efficiency, shortening the time databases in the database cluster are unavailable, and enhancing the high availability of the database cluster.

[0073] In the embodiment of the present invention, based on Figure 2 After S102, you can also Figure 4 As shown, including S103-S105, as follows:

[0074] S103: Configure the first database as a standby database through the first recovery module.

[0075] In an embodiment of the present invention, after the first database completes data repair, the database cluster management device can modify the configuration file of the first database through the first recovery module, configure the first database as a standby database type, and then restart the first database so that the first database can rejoin the database cluster as a standby database and provide data backup for the new primary database.

[0076] S104: Determine, through the second monitoring module, the first database as a backup database for the second database.

[0077] S105: Use the first database to back up the data in the second database.

[0078] In an embodiment of the present invention, the database cluster management device can determine the first database as a backup database of the second database through the second monitoring module corresponding to the second database, i.e., the new primary database, thereby designating the first database to back up the data in the new primary database, i.e., the second database, as a backup database.

[0079] In some embodiments, the database cluster management device may set the backup mode of the first database to synchronous backup through the second monitoring module, thereby promoting the first database to a synchronous backup of the second database.

[0080] It can be understood that in the embodiment of the present invention, the database cluster management device can restore the original master database through the recovery module on the original master database, and re-enable the original master database as a backup database of the new master database through the monitoring module on the new master database, thereby realizing automatic repair of the failure of the first database, i.e., the original master database, and further improving the high availability of the database cluster.

[0081] In the embodiment of the present invention, based on Figure 2 Before S101, you can Figure 5 As shown, including S001-S003, as follows:

[0082] S001. Monitor status information of a first database through a first monitoring module.

[0083] In an embodiment of the present invention, the database cluster management device collects the internal operation status information of the first database and the network status information connected to the first database through the first monitoring module as the status information of the first database, and monitors the operation status of the first database by automatically analyzing the status information.

[0084] S002. Determine whether the first database is a primary database or a backup database based on the status information.

[0085] In an embodiment of the present invention, the database cluster management device can determine from the status information whether the first database is currently running as a master database or a slave database, thereby executing a corresponding process based on the role of the first database in the database cluster.

[0086] In some embodiments, the database cluster management device can analyze the pg_controldata information of the first database through the Database cluster state field to determine whether the first database is a primary database or a backup database. For example, when the first database is the primary database, the value of the Database cluster stated field can be "in production"; when the first database is the primary database, the value of the Database cluster stated field can be "in archiverecovery".

[0087] S003. When the first database is determined to be the primary database, the second database is determined to be the backup database of the first database; the primary database is used to provide external data services; the backup database is used to back up data of the primary database.

[0088] In an embodiment of the present invention, when the database cluster management device determines that the first database is the primary database through status information, it can determine that the second database is the backup database of the first database, so that the exceptions occurring on the first database can be managed according to the above-mentioned primary database exception process, and the exceptions occurring on the second database can be managed according to the backup database exception process.

[0089] In some embodiments of the present invention, when the first database is determined to be the primary database, the first monitoring module may continue to determine whether the first database, i.e., the primary database, is functioning normally based on the collected status information. When the first database is functioning normally and the first monitoring module detects an abnormality in the second database, the database cluster management device updates the backup mode of the second database to asynchronous backup.

[0090] In an embodiment of the present invention, when the first database is in a normal state, the database cluster management device also monitors the status of the backup database, i.e., the second database, through the first monitoring module. If an exception is detected in the second database, this indicates that the second database is no longer able to perform real-time backups of the first database. Because in synchronous backup mode, when the primary database synchronizes data with the backup database, it waits for the synchronous backup database to return the transaction status before completing the current transaction. Therefore, when the backup database fails, the primary database's transaction processing will also be blocked, preventing the primary database from writing data. Therefore, to prevent the impact of a failure in the second database on the first database, when an exception occurs in the second database, the database cluster management device updates the backup mode of the second database to asynchronous backup.

[0091] In an embodiment of the present invention, when a first database serving as a primary database in a database cluster corresponds to multiple standby databases, the database cluster management device updates the backup mode of the second database to asynchronous backup and then selects a synchronous backup mode or a high-priority standby database from the remaining standby databases to back up the first database, thereby reducing the risk of data loss caused by the failure to back up the first database, i.e., the primary database, in a timely manner.

[0092] In this embodiment of the present invention, when the database cluster management device determines that the first database is a standby database based on the status information, the exception occurring on the first database can be managed according to the standby database exception process. The corresponding standby database exception handling process will be described in detail below.

[0093] In the embodiment of the present invention, based on Figure 5 After S002, you can also Figure 6 As shown, including S004-S006, as follows:

[0094] S004: When the first database is a standby database, determine the second database as the primary database, and determine whether the first database is normal based on status information.

[0095] In an embodiment of the present invention, the database cluster management device can monitor the work log of the first database and determine whether an abnormality occurs in the first database based on whether log information such as loss of stream replication process, server connection failure, and master database connection failure appears in the work log.

[0096] S005: When the first database is in an abnormal state, determine whether the first database and the network connected to the first database are normal.

[0097] In an embodiment of the present invention, when the first database is in an abnormal state, the database cluster management device will further check the first database itself and the network connected to the first database to determine whether the first database and the network connected to the first database are normal and find the location of the abnormality.

[0098] S006. When the first database is abnormal and the network is normal, the first database is restored by the first recovery module.

[0099] In an embodiment of the present invention, when an abnormality occurs within the first database itself, but the network connected to the first database is normal, the database cluster management device restarts and recovers the first database through the first recovery module, so that the recovered first database continues to be used as a standby database to back up the second database.

[0100] In the embodiment of the present invention, based on Figure 1In the network architecture shown in FIG, the second monitoring module 1410 on the second host can periodically check the health of the first database 130 and the second database 140. When the second monitoring module detects an abnormality in the first database, acting as a backup database, the second monitoring module downgrades the first database's backup mode to asynchronous backup. Therefore, the method for restoring the first database using the first recovery module in the database cluster management device may include: restarting the first database using the first recovery module, and updating the first database's backup type to synchronous backup using the second monitoring module, thereby completing the recovery of the first database.

[0101] In the embodiment of the present invention, based on Figure 6 After S005, you can also Figure 7 As shown, including S007-S008, as follows:

[0102] S007. When the first database is abnormal and the network is abnormal, the network is regularly monitored by the first monitoring module.

[0103] S008. When it is detected that the network is normal, the first database is restored through the first recovery module.

[0104] In an embodiment of the present invention, when an internal abnormality occurs in the first database and a network connected to the first database is also abnormal, the database cluster management device will periodically monitor the network connected to the first database through the first monitoring module. For example, the database cluster management device will continuously ping the gateway through the first monitoring module; when the database cluster management device returns a normal result from the network monitoring, the database cluster management device will recover the first database through the first recovery module.

[0105] In the embodiment of the present invention, the method in which the database cluster management device recovers the first database through the first recovery module is consistent with the process description in S006 and will not be repeated here.

[0106] In the embodiment of the present invention, based on Figure 6 After S005, you can also Figure 8 As shown, including S009-SS010, as follows:

[0107] S009. When the first database is internally normal and the network is abnormal, the first monitoring module is used to periodically monitor the network.

[0108] S010. When it is detected that the network is normal, continue to use the first database to back up data of the second database.

[0109] In an embodiment of the present invention, when the first database is internally normal but the network connected to the first database is abnormal, it means that there is no fault in the first database itself, but a problem with the network connection. The database cluster management device regularly monitors the network through the first monitoring module until it detects that the network is normal. Then, the backup type of the first database is directly updated to synchronous backup through the second monitoring module, that is, the monitoring module corresponding to the current main database, so that the first database can continue to be used to back up data of the second database.

[0110] It is understandable that in the embodiment of the present invention, when a failure occurs in a standby database in a database cluster, the database cluster management device can also automatically repair and re-enable the standby database through the monitoring module and recovery module on the host where the standby database is located, thereby improving the degree of automation of fault repair and further improving the high availability of the database cluster.

[0111] The following describes exemplary applications of the embodiments of the present invention in actual application scenarios.

[0112] An embodiment of the present invention provides a monitoring method for a monitoring module, which can be used for a host monitoring module on a host or a standby monitoring module on a standby machine in a database cluster management system. In the following embodiments, the host is equivalent to the first host, the standby machine is equivalent to the second host, the host monitoring module is equivalent to the first monitoring module, and the monitoring module on the standby machine is equivalent to the second monitoring module. The functions and configurations of the host monitoring module and the monitoring module on the standby machine are the same; the monitoring method can be as follows Figure 9 As shown, including S301-S319, as follows:

[0113] S301. The monitoring module collects database status information and network information.

[0114] In S301, the host monitoring module can simultaneously collect database status information and network information on the host and the backup machine to monitor the primary and backup databases; similarly, the backup monitoring module can also simultaneously collect database status information and network information on the host and the backup machine to monitor the primary and backup databases.

[0115] S302: Determine whether the current database is the main database.

[0116] In S302, since the monitoring modules on the primary and backup servers can have the same functions and configurations, the monitoring module first determines whether the current database (i.e., the database on its own host) is the primary or backup database. If the current database is the primary database, S303 is executed; if the current database is the backup database, S309 is executed.

[0117] S303: Determine whether the main database is normal.

[0118] In S303, if the current database is the master database, it indicates that the monitoring module is a host monitoring module, and the host monitoring module can be used to determine whether the master database is normal. If the master database is normal, execute 306; otherwise, execute S304.

[0119] S304: Determine whether the standby database status is normal.

[0120] In S304, when an abnormality occurs in the main database, the host monitoring module further determines whether the status of the standby database is normal. When the status of the standby database is normal, S305 is executed. When the status of the standby database is abnormal, it means that both the main database and the standby database have abnormalities and the standby database cannot be promoted to the new main database. The host monitoring module ends this monitoring process and can switch to other modules to execute alarms, error reporting, etc., or other modules can report another high-priority standby database as a new synchronous standby, etc. The specific selection is made according to the actual situation and is not limited in the embodiments of the present invention.

[0121] S305: Stop the high availability service of the host, and use the host recovery module to repair the original master database to become the backup database of the new master database.

[0122] In this embodiment of the present invention, when an exception occurs in the primary database and the backup database is operating normally, the host monitoring module disables the host's high-availability services, such as the Keepalived service, to automatically migrate VIPs originally bound to the primary to the backup server. The host recovery module, or the first recovery module, repairs the original primary database, making it the new backup database, and then ends the monitoring process.

[0123] In S305 , the method of repairing the original master database to become the standby database of the new master database through the host recovery module is consistent with the description of S102 above and will not be repeated here.

[0124] S306: Determine whether the standby database status is normal.

[0125] In S306, when the status of the primary database is normal, the host monitoring module further determines whether the status of the backup database is normal to monitor whether the data backup of the primary database is normal. If the status of the backup database is normal, execute S308; otherwise, execute S307.

[0126] S307: The host monitoring module cancels the synchronous backup and repairs the standby database through the standby recovery module.

[0127] In S307, when the status of the primary database is normal and the status of the backup database is abnormal, in order to prevent the failure of the backup database from blocking data writing to the primary database, the host monitoring module cancels the synchronous backup, downgrades the backup mode of the backup database to asynchronous backup, and repairs the backup database through the backup recovery module on the backup machine, that is, the second recovery module.

[0128] S308: Determine that the cluster status is normal.

[0129] In S308 , when the status of the primary database and the backup database are normal, it indicates that the database cluster is normal, and the host monitoring module ends this monitoring process.

[0130] S309: Determine whether the standby database is normal.

[0131] In S309, if the current database is a standby database, it indicates that the monitoring module is a standby monitoring module, and the standby database can be monitored by the standby monitoring module. If the standby database is normal, execute S317; otherwise, execute S310.

[0132] S310. Check whether the standby database and network are abnormal.

[0133] In S310 , when an abnormality occurs in the standby database, the standby monitoring module further checks whether the standby database itself and the network connected to the standby database are abnormal.

[0134] S311: Is the standby database abnormal?

[0135] In S311 , if the standby database status is abnormal, execute S314 ; otherwise, execute S312 .

[0136] S312: Check if the network is abnormal.

[0137] In S312, when the standby database is in normal state, the standby monitoring module further determines whether the network is abnormal. If the network is abnormal, S313 is executed.

[0138] S313. Continue to ping the gateway.

[0139] In S313, when a network anomaly occurs, the standby monitoring module periodically checks whether it can ping the gateway. After the network is normal, the standby recovery module restores the database, and then ends this monitoring process.

[0140] The method in S313 is consistent with the above description of S009-S010 and will not be repeated here.

[0141] S314: Check if the network is abnormal.

[0142] In S314, when an abnormality occurs in the standby database, the standby monitoring module further determines whether an abnormality also occurs in the network. If an abnormality also occurs in the network, S316 is executed; otherwise, S315 is executed.

[0143] S315: The standby machine recovery module restores the standby database.

[0144] In S315 , when an exception occurs in the standby database but the network status is normal, the standby database is restored through the standby recovery module to continue backing up data for the host through the standby database.

[0145] The method in S315 is consistent with the above description of S006 and will not be repeated here.

[0146] S316. Continue to ping the gateway. When the network is normal, restore the standby database through the standby recovery module.

[0147] In S316, when an exception occurs in the standby database and the network is also in an abnormal state, the standby monitoring module periodically checks whether it can ping the gateway. After the network is normal, the database is restored through the standby recovery module, and the standby database is promoted to a synchronous standby through the main database monitoring module, and then the monitoring process ends.

[0148] The method in S316 is consistent with the above description of S007-S008 and will not be repeated here.

[0149] S317. Determine whether the main database is normal.

[0150] In S317, when the standby database monitoring module determines that the standby database is normal, the standby database monitoring module further determines whether the primary database is normal. If the primary database is normal, S319 is executed; otherwise, S318 is executed.

[0151] S318. The high availability module performs active / standby switching and restores the database through the standby recovery module.

[0152] In S318, when the standby database monitoring module detects an abnormality in the primary database, it takes over the data service of the primary database through Keepalived, switches the original standby database to the new primary database, and restores the original primary database to the new standby database through the host recovery module, i.e., the first recovery module.

[0153] S319: Determine that the cluster status is normal.

[0154] In S319, when the status of the primary database and the backup database are normal, it means that the database cluster is normal, and the backup database monitoring module ends this monitoring process.

[0155] It can be understood that in the embodiment of the present invention, when a failure occurs in the primary database or the backup database in the database cluster, the monitoring modules configured on the host and backup machines can automatically detect the database failure and perform primary-backup switching without the need for manual intervention, thereby shortening the failure recovery time and improving the high availability of the database cluster.

[0156] An embodiment of the present invention provides a method for repairing an abnormal database by a recovery module, which can be used for a host recovery module on a host or a standby recovery module on a standby in a database cluster management system, wherein the host is equivalent to a first host, the standby is equivalent to a second host, the host recovery module is equivalent to a first recovery module, and the recovery module on the standby is equivalent to a second recovery module, and the functions and configurations of the host recovery module and the recovery module on the standby are the same; the repair method can be as follows Figure 10 As shown, including S401-S407, as follows:

[0157] S401: Determine whether the current library is the main library.

[0158] In S401, since the recovery modules on the primary and backup servers can have the same functions and configuration, the recovery module first determines whether the current database (i.e., the database on the host server where it resides) is the primary or backup database. If the current database is the primary database, S402 is executed; if the current database is the backup database, S406 is executed.

[0159] S402: Determine whether the original master database can be downgraded.

[0160] In S402, if the current database is the master database, the master database recovery module compares the data differences between the original and new master databases to determine whether the original master database can be downgraded. If the data stored in the original master database and the data stored in the new master database do not diverge, the original master database is determined to be downgraded and the process proceeds to S405. If the data stored in the original master database and the data stored in the new master database do diverge, the original master database is determined not to be directly downgraded and the process proceeds to S403.

[0161] In S402, the original master database is the database on the host.

[0162] In S402 , the process in which the master database recovery module determines whether the original master database can be downgraded by comparing the data differences between the original master database and the new master database is consistent with the description of S1022 above and will not be repeated here.

[0163] S403. Use the pg_rewind tool to make the original master database a backup database for the new master database.

[0164] In S403 , when there are divergences between the data stored in the original master database and the data stored in the new master database, the host recovery module repairs the original master database using the pg_rewind tool, making the original master database a backup database for the new master database.

[0165] In S403, the new primary database is the database on the standby machine.

[0166] In S403, the host recovery module repairs the original master database through the pg_rewind tool, making the original master database a backup database for the new master database. The process is consistent with the description of S1023 above and will not be repeated here.

[0167] S404. The monitoring module of the new host upgrades the new standby database to a synchronous standby database.

[0168] In S404, after the original master database is repaired to become the new backup database of the new master database, the monitoring module of the new host computer promotes the new backup database to a synchronous backup database to perform real-time data backup of the new master database through the new backup database, and then ends the repair process.

[0169] S405. Modify the configuration file directly, and then start the original master database as the backup database for the new master database.

[0170] In S405 , when the original master database can be directly downgraded, the host recovery module directly modifies the configuration file of the original master database to a standby database type, and starts the original master database as a standby database for the new master database through the standby machine.

[0171] S406. Restart the standby database.

[0172] In S406 , when the current database is a standby database, the standby database recovery module recovers the standby database by restarting the standby database.

[0173] S407: The host monitoring module upgrades the standby database to a synchronous standby database.

[0174] In S407, after the standby database is restarted, the host monitoring module promotes the standby database to a synchronous standby database, so as to use the repaired standby database to perform real-time data backup on the primary database again, and then ends this repair process.

[0175] It is understandable that when a failure occurs in the primary or backup database in a database cluster, the database can be automatically repaired through the recovery modules configured on the primary and backup machines without the need for manual intervention, which shortens the recovery time and improves the high availability of the database cluster.

[0176] An embodiment of the present invention provides a database cluster management device, which is applied to a database cluster, wherein the database cluster includes at least a first database configured on a first host and a second database configured on a second host, wherein the first host and the second host are connected to each other via a network. Figure 11 As shown, the database cluster management device 3 includes a first monitoring module 31 and a first recovery module 32 configured on the first host, wherein:

[0177] The first monitoring module 31 is configured to, when the first database is the primary database and the second database is the backup database, transfer the data services of the first database to the second database when an abnormality is detected in the first database, so as to make the second database the primary database;

[0178] The first recovery module 32 is used to perform differential repair on the data in the first database based on the current data difference between the first database and the second database when it is detected through the first monitoring module that the first database meets the preset recovery conditions, so as to restore the data in the first database to synchronization with the data in the second database.

[0179] In the above-mentioned device, the first recovery module 32 is also used to obtain the first archived data in the first database and the second archived data in the second database when it is monitored that the first database meets the preset recovery conditions; the first archived data is the data archived at the current time point in the first database; the second archived data is the data archived at the current time point in the second database; compare whether there is a divergence point between the first archived data and the second archived data; the divergence point is the node where the first archived data and the second archived data differ on the timeline; when there is a divergence point, determine the most recent consistency point between the first archived data and the second archived data; the most recent consistency point is the node in the first archived data that is most consistent with the second archived data before the divergence point; based on the most recent consistency point, the first database is restored and synchronized, thereby realizing differential repair of the first database and completing the management of the database cluster.

[0180] In the above-mentioned device, the first recovery module 32 is also used to restore the timeline of the first archived data to the most recent consistency point to obtain intermediate archived data; and synchronize the data after the most recent consistency point in the second archived data to the timeline after the intermediate archived data, thereby completing the differential repair of the first database.

[0181] In the above device, the first recovery module 32 is further configured to not recover the first archived data when the divergence point does not exist.

[0182] In the above-mentioned device, a second monitoring module is configured on the second host, and the database cluster management device 3 also includes a backup module. The first recovery module 32 is used to configure the first database as a backup database; the second monitoring module is used to determine the first database as a backup database for the second database; and the backup module is used to use the first database to back up the data in the second database.

[0183] In the above-mentioned device, the first monitoring module 31 is also used to transfer the data service of the first database to the second database when the first database is the main database and the second database is the backup database, and when an abnormality is detected in the first database, so as to monitor the status information of the first database before the second database is used as the main database; judge whether the first database is the main database or the backup database through the status information; when it is determined that the first database is the main database, determine the second database as the backup database of the first database; the main database is used to provide data services to the outside; and the backup database is used to back up data of the main database.

[0184] In the above-mentioned device, the first monitoring module 31 is also used to determine whether the first database is a primary database or a backup database through the status information. When the first database is a backup database, the second database is determined to be the primary database, and whether the first database is normal is determined through the status information; when the first database is in an abnormal state, whether the first database and the network connected to the first database are normal; when the first database is abnormal and the network is normal, the first database is restored by the first recovery module 32.

[0185] In the above-mentioned device, the first monitoring module 31 is also used to determine whether the first database and the network connected to the first database are normal when the first database is in an abnormal state. When the first database is abnormal and the network is abnormal, the network is monitored regularly; when it is monitored that the network is normal, the first database is restored through the first recovery module 32.

[0186] In the above-mentioned device, the first monitoring module 31 is also used to determine whether the first database and the network connected to the first database are normal when the first database is in an abnormal state. When the first database is normal and the network is abnormal, the network is monitored regularly; when it is monitored that the network is normal, the first database is continued to be used to back up data of the second database.

[0187] It should be noted that the description of the above device embodiment is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present invention, please refer to the description of the method embodiment of the present invention for understanding.

[0188] The embodiment of the present invention provides a database cluster management device, such as Figure 12 As shown, the database cluster management device 8 includes: a processor 54, a memory 55 and a communication bus 56. The memory 55 communicates with the processor 54 via the communication bus 56. The memory 55 stores one or more computer programs executable by the processor 54. When one or more computer programs are executed, any one of the database cluster management methods in the aforementioned embodiments is executed by the processor 54.

[0189] An embodiment of the present invention provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the image processing method described above in the embodiment of the present invention.

[0190] It should be noted that, in the embodiment of the present invention, if the above-mentioned image processing method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present invention, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a terminal (which can be a smart phone with a camera, a tablet computer, etc.) to execute all or part of the methods described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiment of the present invention is not limited to any specific combination of hardware and software.

[0191] An embodiment of the present invention provides a computer-readable storage medium storing a computer program. The computer program is stored in the storage medium. When the computer program is executed by a processor, the processor will execute the database cluster management method provided by the embodiment of the present invention.

[0192] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or various devices including one or any combination of the above memories.

[0193] In some embodiments, a computer program may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0194] As an example, a computer program may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, for example, in one or more scripts within a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (for example, files storing one or more modules, subroutines, or code portions).

[0195] By way of example, a computer program may be deployed to be executed on one computing device or on multiple computing devices at one site or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0196] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of the present invention, please refer to the description of the method embodiments of the present invention for understanding.

[0197] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage and optical storage, etc.) containing computer-usable program code.

[0198] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0199] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0200] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The steps for the function specified in one or more boxes.

[0201] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention.

Claims

1. A database cluster management method, applied to a database cluster, wherein the database cluster comprises at least a first database configured on a first host and a second database configured on a second host, wherein the first host and the second host are connected to each other via a network; characterized in that: The first host is configured with a first monitoring module and a first recovery module, the second host is configured with a second monitoring module, and both the first host and the second host are configured with a high availability module; when the first database is a primary database and the second database is a backup database, the first database uses the high availability module on the first host to provide data services to the client; the method includes: When the first database is the primary database and the second database is the backup database, and the first monitoring module detects an abnormality in the first database, the first monitoring module deactivates the high availability module on the first host, and the high availability module on the second host takes over the client's data service, so that the second database becomes the primary database; When the first monitoring module detects that the first database meets preset recovery conditions, the first recovery module compares the timelines of the work logs of the first database and the second database to determine a node where data differences occur between the first database and the second database. Data in the first database is rolled back based on the node, and differential synchronization is performed on the data in the rolled-back first database with the data in the second database to restore data synchronization between the first database and the second database. By using the first recovery module, the first database is configured as a standby database; Determining, by the second monitoring module, the first database as a backup database for the second database; The data in the second database is backed up using the first database.

2. The method according to claim 1, characterized in that The comparing the timelines of the work logs of the first database and the second database, determining a node where data differences occur between the first database and the second database, rolling back the data in the first database according to the node, and performing differential synchronization based on the data in the rolled-back first database and the data in the second database, includes: Acquire first archived data in the first database and second archived data in the second database; the first archived data is data archived in the first database at the current time point; the second archived data is data archived in the second database at the current time point; Comparing, by the first recovery module, whether there is a divergence point between the first archived data and the second archived data; the divergence point is a node where a difference occurs between the first archived data and the second archived data on a timeline; When a divergence point exists, determining the closest consistency point between the first archived data and the second archived data; the closest consistency point is the node in the first archived data that is closest to the time at which the second archived data is consistent before the divergence point; Based on the most recent consistency point, the first database is restored and synchronized.

3. The method according to claim 2, characterized in that The recovering and synchronizing the first database based on the most recent consistency point includes: Restoring the timeline of the first archived data to the most recent consistency point to obtain intermediate archived data; Synchronize the data after the most recent consistency point in the second archived data to the timeline after the intermediate archived data.

4. The method according to claim 3, characterized in that After comparing, by the first recovery module, whether there is a divergence point between the first archived data and the second archived data, the method further includes: When the divergence point does not exist, the first archived data is not restored.

5. The method according to claim 1, wherein When the first database is a primary database and the second database is a backup database, and the first monitoring module detects an abnormality in the first database, the method further includes: transferring data services of the first database to the second database through the first monitoring module before making the second database the primary database. monitoring the status information of the first database by the first monitoring module; Determine whether the first database is a primary database or a backup database based on the status information; When the first database is determined to be the primary database, the second database is determined to be the backup database of the first database; the primary database is used to provide external data services; the backup database is used to back up data of the primary database.

6. The method according to claim 5, characterized in that After determining whether the first database is a primary database or a backup database based on the status information, the method further includes: When the first database is a standby database, determining the second database as the primary database and judging whether the first database is normal based on the status information; When the first database is in an abnormal state, determining whether the first database and a network connected to the first database are normal; When the first database is abnormal internally and the network is normal, the first database is restored by the first recovery module.

7. The method according to claim 6, characterized in that When the first database is in an abnormal state, after determining whether the first database and a network connected to the first database are normal, the method further includes: When the first database is abnormal and the network is abnormal, the first monitoring module is used to regularly monitor the network; When it is monitored that the network is normal, the first database is restored by the first recovery module.

8. The method according to claim 6, characterized in that When the first database is in an abnormal state, after determining whether the first database and a network connected to the first database are normal, the method further includes: When the first database is internally normal and the network is abnormal, the first monitoring module periodically monitors the network; When it is detected that the network is normal, the first database is continued to be used to back up data of the second database.

9. A database cluster management system, applied to a database cluster, wherein the database cluster comprises at least a first database configured on a first host and a second database configured on a second host, the first host and the second host being interconnected via a network, the first database being a primary database and the second database being a backup database; characterized in that: The first host is configured with a first monitoring module and a first recovery module, the second host is configured with a second monitoring module and a second recovery module, and both the first host and the second host are configured with a high availability module; when the first database is the primary database and the second database is the backup database, the first database uses the high availability module on the first host to provide data services to the client; wherein, The first monitoring module is configured to, when an exception occurs in the first database, disable the high availability module on the first host, so that the high availability module on the second host can take over the client's data service and use the second database as the primary database; The first recovery module is configured to, when the first monitoring module detects that the first database meets a preset recovery condition, compare the timelines of the work logs of the first database and the second database to determine a node at which data differences occur between the first database and the second database, roll back the data in the first database based on the node, and perform differential synchronization with the data in the second database based on the rolled-back data, so as to restore data synchronization between the first database and the second database; The first recovery module is further configured to compare the timelines of the work logs of the first database and the second database to determine a node where data differences occur between the first database and the second database, roll back the data in the first database based on the node, and configure the first database as a standby database after performing differential synchronization based on the rolled-back data in the first database and the data in the second database. the second monitoring module is configured to enable the first recovery module to perform differential repair on the data in the first database based on the data difference between the first database and the second database, so as to restore the data synchronization between the first database and the second database, and then determine the first database as a standby database for the second database; The second recovery module is configured to recover the second database when an exception occurs in the second database and use the second database as a standby database again; The first database is used to back up the data in the second database.

10. A database cluster management device, applied to a database cluster, wherein the database cluster comprises at least a first database configured on a first host and a second database configured on a second host, wherein the first host and the second host are connected to each other via a network; The device includes: a first monitoring module and a first recovery module configured on the first host, a second monitoring module configured on the second host, and a high availability module configured on both the first host and the second host; when the first database is the primary database and the second database is the backup database, the first database uses the high availability module on the first host to provide data services to the client; wherein, The first monitoring module is configured to, when the first database is a primary database and the second database is a backup database, deactivate the high availability module on the first host upon detecting an abnormality in the first database, so that the high availability module on the second host can take over the client's data service and use the second database as the primary database; The first recovery module is used to, when it is monitored by the first monitoring module that the first database meets the preset recovery conditions, compare the timelines of the work logs of the first database and the second database, determine the node where the data difference occurs between the first database and the second database, roll back the data in the first database according to the node, and perform differential synchronization based on the data in the rolled-back first database and the data in the second database to restore the synchronization of the data in the first database and the second database; configure the first database as a standby database type, so that the second monitoring module determines the first database as a standby database of the second database, so that the first database backs up the data in the second database.

11. A database cluster management device, characterized in that: include: A processor, a memory, and a communication bus, wherein the memory communicates with the processor via the communication bus, the memory stores one or more computer programs executable by the processor, and when the one or more computer programs are executed, the processor executes the method according to any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that One or more computer programs are stored, and the one or more computer programs can be executed by one or more processors. When the computer programs are executed by the processors, the method according to any one of claims 1 to 8 is implemented.

Images