Database cluster fault processing method, intelligent monitoring platform, device and medium

Abstract

The application relates to the technical field of data processing, and provides a fault processing method of a database cluster, an intelligent monitoring platform, equipment and a medium. The database cluster comprises a master database and at least one slave database, and the master database and the slave database are containerized. The method comprises the following steps: monitoring running state information of the database cluster; if it is determined that the master database has a fault according to the monitored running state information, acquiring master database fault information of the master database; and performing first fault processing according to the master database fault information and historical switching records. The historical switching records are stored in the intelligent monitoring platform, and the first fault processing comprises backup database switching, database expansion and data recovery. On the one hand, an emergency expansion recovery scheme of the master database is realized, the workload of database operation and maintenance personnel is reduced, and the operation and maintenance efficiency after the master database fault is improved. On the other hand, resource matching is performed according to the historical switching records, so that resource overallocation can be prevented and concurrent recovery can be realized.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a fault handling method for a database cluster, an intelligent monitoring platform, a computer device, and a readable storage medium. Background Technology

[0002] As enterprises enter a period of rapid development, data has become a key production factor driving the development of the data economy. Developing the digital economy is the only way to achieve high-quality economic development and build a modern economic system.

[0003] However, due to the various complex business scenarios of enterprises, database operation and maintenance personnel face significant challenges. It is common for one person to manage thousands of databases in modern database operation and maintenance. When large-scale or even data center-level database failures occur, database operation and maintenance personnel may be at a loss, resulting in low operation and maintenance efficiency after database failures. Summary of the Invention

[0004] In view of this, this application provides a fault handling method for a database cluster, an intelligent monitoring platform, computer equipment, and a readable storage medium, which reduces the workload of database operation and maintenance personnel and improves the operation and maintenance efficiency after the main database fails.

[0005] In a first aspect, embodiments of this application provide a fault handling method for a database cluster, applied to an intelligent monitoring platform. The database cluster includes a master database and at least one slave database, both of which are containerized. The method includes:

[0006] Monitor the operational status information of the database cluster;

[0007] If the main database is determined to have failed based on the monitored operating status information, then the main database failure information is obtained.

[0008] Based on the primary database failure information and historical switchover records, the first failure handling was carried out;

[0009] Historical switchover records are stored on the intelligent monitoring platform. The first fault handling includes: backup database switchover, database expansion, and data recovery.

[0010] The fault handling method for the database cluster described in the embodiments of this application may also have the following additional technical features:

[0011] In the above technical solution, optionally, a first fault handling is performed based on the master database fault information and historical switchover records, including:

[0012] Based on the primary database failure information, determine whether the failure is caused by the primary database's original container or the primary database's original host machine.

[0013] If the original container of the primary database fails, the primary database will be switched to the standby database according to the historical switchover record. A new container of the primary database will be restarted on the original host machine of the primary database. The state path of the new container of the primary database will be mounted to the original state path of the original host machine of the primary database so as to restore the data of the primary database in the new container of the primary database and set the primary database as the slave database of the new container of the primary database.

[0014] Optionally, in any of the above technical solutions, the method further includes:

[0015] If the original host machine of the primary database fails, the primary database is switched to the standby database according to the historical switchover record. Then, the primary database is switched to the corresponding container on the first reserved host machine. The data of the primary database is restored in the corresponding container on the first reserved host machine according to the image backup data of the primary database. The primary database is also set as the slave database of the corresponding container on the first reserved host machine.

[0016] Optionally, in any of the above technical solutions, the method further includes:

[0017] If a failure is determined to occur in the database based on the monitored operating status information, the failure information of the slave database is obtained, and a second failure handling is performed based on the slave database failure information and historical switch records.

[0018] The second fault handling includes database expansion and data recovery.

[0019] Optionally, in any of the above technical solutions, a second fault handling process is performed based on the slave database fault information and historical switchover records, including:

[0020] Based on the database failure information, determine whether the failure occurred in the original container of the database slave or the original host machine of the database slave.

[0021] If the original slave container of the database fails, a new slave container will be restarted on the original host machine of the slave based on the historical switch records. The state path of the new slave container will be mounted to the original state path of the original host machine of the slave to restore the data of the slave database in the new slave container, and the slave database will be set as the slave database of the new slave container.

[0022] Optionally, in any of the above technical solutions, the method further includes:

[0023] If the original host machine of the slave database fails, the slave database will be switched to the corresponding container on the second reserved host machine according to the historical switch records. The slave database data will be restored in the corresponding container on the second reserved host machine according to the image backup data of the slave database. The slave database will also be set as the slave database of the corresponding container on the second reserved host machine.

[0024] Optionally, in any of the above technical solutions, the method further includes:

[0025] After handling the first or second fault, update the historical switch record based on the handling result.

[0026] Secondly, embodiments of this application provide an intelligent monitoring platform for handling faults in a database cluster. The database cluster includes a master database and at least one slave database, both of which are containerized. The platform includes:

[0027] The monitoring module is used to monitor the running status information of the database cluster;

[0028] The acquisition module is used to acquire the main database failure information if the main database is determined to have failed based on the monitored operating status information.

[0029] The processing module is used to perform the first fault handling based on the main database fault information and historical switch records;

[0030] Historical switchover records are stored on the intelligent monitoring platform. The first fault handling includes: backup database switchover, database expansion, and data recovery.

[0031] The intelligent monitoring platform according to the embodiments of this application may also have the following additional technical features:

[0032] In the above technical solution, optionally, the processing module is specifically used to: determine, based on the primary database failure information, whether the primary database's original container or the primary database's original host machine has failed; if the primary database's original container has failed, then based on historical switch records, switch the primary database to the standby database, restart a new primary database container on the primary database's original host machine, mount the state path of the new primary database container to the original state path of the primary database's original host machine, so as to restore the primary database's data in the new primary database container, and set the primary database as the slave database of the new primary database container.

[0033] In any of the above technical solutions, optionally, the processing module is specifically used for: if the original host machine of the primary database fails, switching the primary database to the backup database according to the historical switching record, then switching the primary database to the corresponding container on the first reserved host machine, restoring the data of the primary database in the corresponding container on the first reserved host machine according to the image backup data of the primary database, and setting the primary database as the slave database of the corresponding container on the first reserved host machine.

[0034] In any of the above technical solutions, optionally, the acquisition module is further configured to acquire the slave database failure information if it is determined from the monitored operating status information that a failure has occurred in the slave database; the processing module is further configured to perform a second failure processing based on the slave database failure information and historical switching records; wherein, the second failure processing includes database expansion and data recovery.

[0035] In any of the above technical solutions, optionally, the processing module is specifically used to: determine, based on the slave database failure information, whether the failure is caused by the original slave container of the slave database or the original slave host machine of the slave database; if the original slave container of the slave database fails, then based on the historical switch records, restart a new slave container on the original slave host machine, mount the state path of the new slave container to the original state path of the original slave host machine, so as to restore the data of the slave database in the new slave container, and set the slave database as the slave database of the new slave container.

[0036] In any of the above technical solutions, optionally, the processing module is specifically used for: if the original host machine of the slave database fails, switching the slave database to the corresponding container on the second reserved host machine according to the historical switching record, restoring the data of the slave database in the corresponding container on the second reserved host machine according to the image backup data of the slave database, and setting the slave database as the slave database of the corresponding container on the second reserved host machine.

[0037] Optionally, in any of the above technical solutions, the processing module is further configured to update the historical switching record based on the processing result after performing the first fault processing or the second fault processing.

[0038] Thirdly, embodiments of this application provide a computer device including a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions implementing the steps of the method as described in the first aspect when executed by the processor.

[0039] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0040] Fifthly, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0041] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method as described in the first aspect.

[0042] In this embodiment, the operating status information of the master and slave databases in the database cluster is continuously monitored, and the operating status information is analyzed to determine whether a failure has occurred. If the operating status information determines that the master database has failed, the system performs standby database switching, database expansion, and data recovery based on the master database failure information and the historical switchover records stored on the intelligent monitoring platform.

[0043] Through the technical solution of this application embodiment, on the one hand, the entire complex expansion and automated recovery mechanism is completed without human intervention, and all operations are completed automatically, making the emergency expansion and recovery solution of the main database faster and more stable, which can improve the availability of the main database operation and maintenance, reduce the workload of database operation and maintenance personnel, and improve the operation and maintenance efficiency after the main database failure.

[0044] On the other hand, the intelligent AI monitoring platform will match resources based on historical switching records, which can prevent resource over-provisioning and enable concurrent recovery.

[0045] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0046] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0047] Figure 1 A schematic diagram illustrating the fault handling process of a database cluster according to an embodiment of this application is shown;

[0048] Figure 2 One of the flowcharts of a fault handling method for a database cluster according to an embodiment of this application is shown;

[0049] Figure 3 This is a second schematic flowchart illustrating a fault handling method for a database cluster according to an embodiment of this application;

[0050] Figure 4 The third flowchart illustrates the fault handling method for a database cluster according to an embodiment of this application;

[0051] Figure 5 A structural block diagram of the intelligent monitoring platform according to an embodiment of this application is shown;

[0052] Figure 6 A structural block diagram of a computer device according to an embodiment of this application is shown. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0054] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0055] Currently, many tools and scripts exist for automated database backup and one-click restore, playing a crucial role in database backup and restore. However, in the event of a large-scale or data center-level failure, operations and maintenance personnel still need to spend a significant amount of time finding a new server suitable for restoration, deploying the necessary backup and restore tools on that new machine, and finally performing the backup and restore using those tools. For data center-level disasters, it is impossible to restore the system to its pre-failure level in the shortest possible time. Therefore, the rapid recovery capabilities of enterprise database operations and maintenance personnel, as well as related lower-level operations and maintenance staff, remain a significant challenge.

[0056] This situation is particularly challenging in the financial industry. Due to the stringent regulations in the financial sector, databases subject to regulation must be maintained in self-built Internet Data Centers (IDCs). While server scaling is easily achieved in the cloud, it becomes a significant challenge in traditional IDCs. In the event of a large-scale or even data center-level database failure, database maintenance personnel may need several days or even more than ten days to restore the database to its pre-failure state. Furthermore, various other potential problems may arise during the recovery process.

[0057] For large-scale or even data center-level failures, as well as failures of single or small databases, this application's embodiments employ an intelligent AI monitoring platform to automate emergency expansion and recovery operations, reducing the workload of database maintenance personnel and improving maintenance efficiency after database failures.

[0058] The following description, in conjunction with the accompanying drawings, details the fault handling method, intelligent monitoring platform, computer equipment, and readable storage medium for the database cluster provided in this application, through specific embodiments and application scenarios.

[0059] This application provides a fault handling method for a database cluster, applied to an intelligent monitoring platform. The intelligent monitoring platform stores historical failover records. The database cluster includes a master database and at least one slave database, both of which are containerized. Figure 1 As shown, the intelligent monitoring platform communicates with the master database and at least one slave database to perform automated emergency expansion and recovery operations on the master and slave databases.

[0060] like Figure 2 As shown, the method includes:

[0061] Step 201: Monitor the running status information of the database cluster;

[0062] Step 202: If it is determined that the main database has failed based on the monitored operating status information, then obtain the main database failure information.

[0063] Step 203: Based on the primary database failure information and historical switchover records, perform the first fault handling, which includes: standby database switchover, database expansion, and data recovery.

[0064] In this embodiment, all databases have been containerized with Docker, the database applications are deployed in Docker containers, data persistence is performed on the host machine where the Docker container is located, I / O bottlenecks are controllable, and high-availability nodes are distributed on different host machines.

[0065] In this embodiment, the operating status information of the master and slave databases in the database cluster is continuously monitored, and the operating status information is analyzed to determine whether a failure has occurred. If the operating status information determines that the master database has failed, the system performs standby database switching, database expansion, and data recovery based on the master database failure information and the historical switchover records stored on the intelligent monitoring platform.

[0066] Through the technical solution of this application embodiment, on the one hand, the entire complex expansion and automated recovery mechanism is completed without human intervention, and all operations are completed automatically, making the emergency expansion and recovery solution of the main database faster and more stable, which can improve the availability of main database operation and maintenance, reduce the workload of main database operation and maintenance personnel, and improve the operation and maintenance efficiency after the main database failure.

[0067] On the other hand, the intelligent AI monitoring platform will match resources based on historical switching records, which can prevent resource over-provisioning and enable concurrent recovery.

[0068] In one embodiment of this application, taking MySQL as an example, if a single database fails, and it is determined that the primary database has failed, then based on the primary database failure information, it is further determined whether the primary database's original container or the primary database's original host machine has failed.

[0069] In the first scenario, if the original container of the primary database fails, the high-availability node will automatically switch the primary database to the standby database based on historical switchover records. Furthermore, a new primary database container will be restarted on the original host machine of the primary database, and the state path of the new primary database container will be mounted to the original state path of the original host machine of the primary database. This allows the new primary database container to seamlessly restore the data of the primary database, and the original primary database will be automatically connected to the new primary database container to become its slave database. The restored data of the primary database includes configuration, users, databases, tables, records, and other data.

[0070] The above method enables resource matching based on historical switchover records in the event of a failure in the original container of the primary database, achieving a better capacity expansion and recovery effect.

[0071] In the second scenario, if the original host machine of the primary database fails, the high-availability node will automatically switch the primary database to the standby database based on the historical switchover record. Then, the primary database will be switched to the corresponding container on the first reserved host machine. The data of the primary database will be restored in the corresponding container on the first reserved host machine based on the image backup data of the primary database. The original primary database will be automatically connected to the corresponding container on the first reserved host machine to become its slave database. The first reserved host machine is one of multiple reserved host machines.

[0072] The above method enables resource matching based on historical switchover records in the event of a failure in the original host machine of the primary database, achieving a better capacity expansion and recovery effect.

[0073] In one embodiment of this application, such as Figure 3 As shown, the method includes:

[0074] Step 301: Monitor the running status information of the database cluster;

[0075] Step 302: Based on the running status information, determine whether the failure is in the master database or the slave database. If the failure is in the master database, proceed to step 303; if the failure is in the slave database, proceed to step 304.

[0076] Step 303: Obtain primary database failure information and perform first failure handling based on primary database failure information and historical switch records. The first failure handling includes: standby database switchover, database expansion and data recovery.

[0077] Step 304: Obtain slave database failure information from the database, and perform second fault handling based on the slave database failure information and historical switch records; wherein, the second fault handling includes database expansion and data recovery.

[0078] In this embodiment, the operating status information of the master and slave databases in the database cluster is continuously monitored, and the operating status information is analyzed to determine whether a failure has occurred. If a failure is determined to have occurred in a slave database based on the operating status information, database expansion and data recovery are performed based on the slave database failure information and historical switchover records stored in the intelligent monitoring platform.

[0079] Through the technical solution of this application embodiment, on the one hand, the entire complex expansion and automated recovery mechanism is completed without human intervention, and all operations are completed automatically, making the emergency expansion and recovery solution of the database faster and more stable, improving the availability of database operation and maintenance, reducing the workload of database operation and maintenance personnel, and improving the operation and maintenance efficiency after database failure.

[0080] On the other hand, the intelligent AI monitoring platform will match resources based on historical switching records, which can prevent resource over-provisioning and enable concurrent recovery.

[0081] In one embodiment of this application, if it is determined that a failure occurred in the slave database, then based on the slave database failure information, it is further determined whether the failure occurred in the original slave container of the slave database or the original slave host machine of the slave database.

[0082] In the first scenario, if the original slave container of the slave database fails, there is no need to perform a backup switch. Instead, based on the historical switch records, a new slave container is restarted on the original host machine of the slave database. The state path of the new slave container is mounted to the original state path of the original host machine of the slave database, so that the data of the original slave database can be seamlessly restored in the new slave container. The original slave database is also automatically connected to the new slave container and becomes its slave database. The restored slave database data includes configuration, users, databases, tables, records, and other data.

[0083] The above method enables resource matching based on historical switch records in the event of a failure in the original slave container of the database, achieving a better capacity expansion and recovery effect.

[0084] In the second scenario, if the original host machine of the slave database fails, there is no need to switch the backup database. Instead, based on the historical switch records, the slave database is switched to the corresponding container on the second reserved host machine. Furthermore, if the original host machine can be recovered, the slave database data is restored in the corresponding container on the second reserved host machine based on the image backup data of the slave database, and the slave database is set as the slave database of the corresponding container on the second reserved host machine.

[0085] The above method enables resource matching based on historical switchover records in the event of a failure in the original host machine of the slave database, achieving a better capacity expansion and recovery effect.

[0086] In one embodiment of this application, such as Figure 4 As shown, the method includes:

[0087] Step 401: Monitor the running status information of the database cluster;

[0088] Step 402: Based on the running status information, determine whether the failure is in the master database or the slave database. If the failure is in the master database, proceed to step 403; if the failure is in the slave database, proceed to step 404.

[0089] Step 403: Obtain primary database failure information and perform first failure handling based on primary database failure information and historical switch records. The first failure handling includes: standby database switchover, database expansion and data recovery.

[0090] Step 404: Obtain slave database failure information from the database, and perform second fault handling based on the slave database failure information and historical switch records; wherein, the second fault handling includes database expansion and data recovery;

[0091] Step 405: Update the historical switch record based on the processing result.

[0092] In this embodiment, regardless of whether the expansion and recovery of the primary database or the secondary database is performed, the switching information is stored, that is, the historical switching record is updated, which provides a basis for resource allocation for subsequent expansion and recovery and ensures the effectiveness of expansion and recovery.

[0093] In this embodiment, regardless of whether it's the master or slave database, recovery and allocation information is recorded in the intelligent AI monitoring platform. When a large-scale or data center-level database failure occurs, the intelligent AI monitoring platform performs resource matching based on the recorded allocation information. This prevents resource over-provisioning, enables concurrent recovery, and represents a significant leap in both the time and efficiency of database operations and maintenance. Furthermore, the entire process is analyzed, evaluated, and commands are issued by the intelligent AI monitoring platform without any manual intervention. After business operations are restored to normal, reports are generated based on the information recorded in the database for database operations personnel to analyze problems and for management to make decisions.

[0094] As a specific implementation of the aforementioned database cluster fault handling method, this application embodiment provides an intelligent monitoring platform. The intelligent monitoring platform is used to handle database cluster faults. The platform stores historical failover records. The database cluster includes a master database and at least one slave database, both of which are containerized. Figure 5 As shown, the intelligent monitoring platform 500 includes: a monitoring module 501, an acquisition module 502, and a processing module 503.

[0095] The monitoring module 501 is used to monitor the operating status information of the database cluster; the acquisition module 502 is used to acquire the primary database failure information if the primary database is determined to have failed based on the monitored operating status information; the processing module 503 is used to perform the first failure processing based on the primary database failure information and historical switch records; the first failure processing includes: standby database switch, database expansion and data recovery.

[0096] In this embodiment, all databases have been containerized with Docker, the database applications are deployed in Docker containers, data persistence is performed on the host machine where the Docker container is located, I / O bottlenecks are controllable, and high-availability nodes are distributed on different host machines.

[0097] In this embodiment, the operating status information of the master and slave databases in the database cluster is continuously monitored, and the operating status information is analyzed to determine whether a failure has occurred. If the operating status information determines that the master database has failed, the system performs standby database switching, database expansion, and data recovery based on the master database failure information and the historical switchover records stored on the intelligent monitoring platform.

[0098] Through the technical solution of this application embodiment, on the one hand, the entire complex expansion and automated recovery mechanism is completed without human intervention, and all operations are completed automatically, making the emergency expansion and recovery solution of the main database faster and more stable, which can improve the availability of the main database operation and maintenance, reduce the workload of database operation and maintenance personnel, and improve the operation and maintenance efficiency after the main database failure.

[0099] On the other hand, the intelligent AI monitoring platform will match resources based on historical switching records, which can prevent resource over-provisioning and enable concurrent recovery.

[0100] In the above technical solution, optionally, the processing module 503 is specifically used to: determine, based on the primary database failure information, whether the primary database's original container or the primary database's original host machine has failed; if the primary database's original container has failed, then based on the historical switch records, switch the primary database to the standby database, restart a new primary database container on the primary database's original host machine, mount the state path of the new primary database container to the original state path of the primary database's original host machine, so as to restore the primary database's data in the new primary database container, and set the primary database as the slave database of the new primary database container.

[0101] In any of the above technical solutions, optionally, the processing module 503 is specifically used for: if the original host machine of the master database fails, switching the master database to the standby database according to the historical switching record, then switching the master database to the corresponding container on the first reserved host machine, restoring the data of the master database in the corresponding container on the first reserved host machine according to the image backup data of the master database, and setting the master database as the slave database of the corresponding container on the first reserved host machine.

[0102] In any of the above technical solutions, optionally, the acquisition module 502 is further configured to acquire the slave database fault information if it is determined from the monitored operating status information that a fault has occurred in the slave database; the processing module 503 is further configured to perform a second fault handling based on the slave database fault information and historical switching records; wherein, the second fault handling includes database expansion and data recovery.

[0103] In any of the above technical solutions, optionally, the processing module 503 is specifically used to: determine, based on the slave database failure information, whether the failure is caused by the original slave container of the slave database or the original slave host machine of the slave database; if the original slave container of the slave database fails, then based on the historical switch records, restart a new slave container on the original slave host machine, mount the state path of the new slave container to the original state path of the original slave host machine, so as to restore the data of the slave database in the new slave container, and set the slave database as the slave database of the new slave container.

[0104] In any of the above technical solutions, optionally, the processing module 503 is specifically used for: if the original host machine of the slave database fails, switching the slave database to the corresponding container on the second reserved host machine according to the historical switching record, restoring the data of the slave database in the corresponding container on the second reserved host machine according to the image backup data of the slave database, and setting the slave database as the slave database of the corresponding container on the second reserved host machine.

[0105] Optionally, in any of the above technical solutions, the processing module 503 is further configured to update the historical switching record based on the processing result after performing the first fault processing or the second fault processing.

[0106] The intelligent monitoring platform 500 in this application embodiment can be a computer device or a component within the computer device, such as an integrated circuit or a chip. The computer device can be a terminal or other devices besides a terminal. For example, the computer device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle computer device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the application.

[0107] The intelligent monitoring platform 500 in this embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this embodiment does not specifically limit its use.

[0108] The intelligent monitoring platform 500 provided in this application embodiment can achieve... Figure 1 The various processes implemented in the database cluster fault handling method embodiment will not be described again here to avoid repetition.

[0109] This application also provides a computer device, such as... Figure 6As shown, the computer device 600 includes a processor 601 and a memory 602. The memory 602 stores a program or instruction that can run on the processor 601. When the program or instruction is executed by the processor 601, it implements the various steps of the above-described database cluster fault handling method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0110] It should be noted that the computer devices in the embodiments of this application include the mobile computer devices and non-mobile computer devices described above.

[0111] The memory 602 can be used to store software programs and various data. The memory 602 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 602 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 602 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0112] Processor 601 may include one or more processing units; optionally, processor 601 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 601.

[0113] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described database cluster fault handling method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0114] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described database cluster fault handling method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0115] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0116] This application also provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described database cluster fault handling method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0117] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0118] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A fault handling method for a database cluster, characterized in that, The method, applied to an intelligent monitoring platform, comprises a database cluster including a master database and at least one slave database. Both the master and slave databases are containerized, the database application is deployed in the corresponding container, and data persistence is performed on the host machine where the container resides. Monitor the operational status information of the database cluster; If it is determined that the main database has failed based on the monitored operating status information, then the main database failure information is obtained. Based on the primary database fault information and historical switchover records, the first fault handling is performed; The historical switching records are stored in the intelligent monitoring platform, and the first fault handling includes: backup database switching, database expansion, and data recovery. The failure of the primary database includes a failure of the original primary database container or a failure of the original primary database host machine. If the original primary database container fails, the primary database is switched to a standby database according to the historical switch records. A new primary database container is then restarted on the original primary database host machine. The state path of the new primary database container is mounted to the original state path of the original primary database host machine to restore the data of the primary database in the new primary database container. The primary database is then set as a slave database of the new primary database container.

2. The method according to claim 1, characterized in that, The first fault handling based on the primary database fault information and historical switchover records includes: Based on the primary database failure information, determine whether the failure is caused by the primary database's original container or the primary database's original host machine. If the original primary container of the primary database fails, the primary database is switched to the standby database according to the historical switch records. A new primary container is then restarted on the original host machine of the primary database. The state path of the new primary container is mounted to the original state path of the original host machine of the primary database to restore the data of the primary database in the new primary container and to set the primary database as the slave database of the new primary container.

3. The method according to claim 2, characterized in that, Also includes: If the original host machine of the primary database fails, the primary database is switched to the backup database according to the historical switch records, and then switched to the corresponding container on the first reserved host machine. The data of the primary database is restored in the corresponding container on the first reserved host machine according to the image backup data of the primary database, and the primary database is set as the slave database of the corresponding container on the first reserved host machine.

4. The method according to any one of claims 1 to 3, characterized in that, Also includes: If it is determined that the slave database has failed based on the monitored operating status information, then the slave database failure information is obtained, and a second fault handling is performed based on the slave database failure information and the historical switching records. The second fault handling includes database expansion and data recovery.

5. The method according to claim 4, characterized in that, The second fault handling based on the slave database fault information and the historical switchover records includes: Based on the database failure information, determine whether the failure is caused by the original container of the database slave or the original host machine of the database slave. If the original slave container of the slave database fails, a new slave container is restarted on the original slave host machine according to the historical switch record. The state path of the new slave container is mounted to the original state path of the original slave host machine to restore the data of the slave database in the new slave container and set the slave database as the slave database of the new slave container.

6. The method according to claim 5, characterized in that, Also includes: If the original host machine of the slave database fails, the slave database is switched to the corresponding container on the second reserved host according to the historical switch record. The data of the slave database is restored in the corresponding container on the second reserved host according to the image backup data of the slave database. The slave database is then set as the slave database of the corresponding container on the second reserved host.

7. The method according to claim 4, characterized in that, Also includes: After performing the first fault handling or the second fault handling, the historical switching record is updated according to the processing result.

8. An intelligent monitoring platform, characterized in that, The intelligent monitoring platform is used to handle faults in the database cluster, which includes a master database and at least one slave database. Both the master and slave databases are containerized, with database applications deployed in corresponding containers and data persistence hosted on the host machine of the container. The platform includes: The monitoring module is used to monitor the operating status information of the database cluster; The acquisition module is used to acquire the main database failure information if it is determined from the monitored operating status information that the main database has failed. The processing module is used to perform the first fault handling based on the main database fault information and historical switching records; The historical switching records are stored in the intelligent monitoring platform, and the first fault handling includes: backup database switching, database expansion, and data recovery. The failure of the primary database includes a failure of the original primary database container or a failure of the original primary database host machine. If the original primary database container fails, the primary database is switched to a standby database according to the historical switch records. A new primary database container is then restarted on the original primary database host machine. The state path of the new primary database container is mounted to the original state path of the original primary database host machine to restore the data of the primary database in the new primary database container. The primary database is then set as a slave database of the new primary database container.

9. A computer device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that run on the processor, the program or instructions being executed by the processor to implement the steps of the fault handling method for the database cluster as described in any one of claims 1 to 7.

10. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the steps of the fault handling method for the database cluster as described in any one of claims 1 to 7.

Images