Database switching method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a database switching method and device, equipment and a storage medium, and belongs to the technical field of databases. The method comprises the following steps: acquiring fault related data of a first database; inputting the fault related data into a preset fault prediction model to obtain a fault prediction result of the first database; and switching an access database of the service system from the first database to a second database of the second electronic equipment through the gateway controller under the condition that the fault prediction result of the first database is that the fault occurs. According to the embodiment of the invention, the switching efficiency of the existing method, especially the insurance industry, can be improved.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a database switching method, apparatus, device, and storage medium. Background Art

[0002] In the information age, enterprise databases, as the backbone of core business systems, ensure stability and availability, crucial to the normal operation of an enterprise. Databases not only store critical business data but also support daily business processes and decision-making analysis. In the insurance industry, in particular, the proper functioning of databases is directly related to core operations such as policy management, claims processing, and customer service. A database failure can lead to business interruption, data loss, and even severe economic losses and social impact. Therefore, ensuring high database availability and rapid recovery capabilities has become a top priority in enterprise information development.

[0003] Currently, most enterprises use a manual failover solution to switch databases when a fault is detected. This results in low failover efficiency and is prone to failures and data inconsistencies due to operational errors. Therefore, research on a more intelligent and flexible failover method for databases to improve the efficiency of existing methods and further enhance overall system efficiency has become an important area of research in database technology. Summary of the Invention

[0004] The main purpose of the embodiments of the present application is to provide a database switching method, apparatus, device and storage medium.

[0005] To achieve the above objectives, a first aspect of an embodiment of the present application provides a database switching method, the method comprising:

[0006] Acquiring fault-related data from the first database;

[0007] Inputting the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database;

[0008] When the fault prediction result of the first database is that a fault occurs, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller.

[0009] In some embodiments, switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller includes:

[0010] Obtaining a fault characteristic state from the first database; wherein the fault characteristic state includes at least one of the following: fault type, severity, and fault level;

[0011] Based on the fault characteristic state, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller.

[0012] In some embodiments, switching, by a gateway controller, an access database of the business system from the first database to a second database of the second electronic device based on the fault characteristic information includes:

[0013] When the fault characteristic state of the first database is the first state, the fault prediction result is sent to the administrator, and when a confirmation switching instruction is received, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller;

[0014] When the fault characteristic state of the first database is the second state, switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller;

[0015] The severity of the fault of the first database indicated by the first state is greater than the severity of the fault of the first database indicated by the second state.

[0016] In some embodiments, switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller includes:

[0017] Send the fault prediction result to the control terminal so that the control terminal generates a database switching command based on the fault prediction result, and sends the database switching command to the gateway controller; wherein the database switching command is used to instruct the gateway controller to switch the access database of the business system from the first database to the second database of the second electronic device.

[0018] In some embodiments, switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller includes:

[0019] Switching, by the gateway controller, the domain name of the business system accessing the database from the Internet Protocol address of the first database to the Internet Protocol address of the second database;

[0020] closing a first data synchronization link between the first database and the second database, where the first data synchronization link is used to synchronize data in the first database to the second database;

[0021] A second data synchronization link is opened between the second database and the first database, where the second data synchronization link is used to synchronize data in the second database to the first database.

[0022] In some embodiments, after switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller, the method includes:

[0023] Sending a switching result of switching the access database of the business system from the first database to the second database to the control terminal, and recording relevant information of the switching of the access database of the business system from the first database to the second database; wherein the switching result is that the first database is successfully switched to the second database;

[0024] Detecting information of the second database and synchronously sending the information of the second database to an administrator; wherein the information of the second database includes the status of the second database and the business operation status of the second database.

[0025] In some embodiments, before acquiring the fault-related data from the first database, the process includes:

[0026] Obtain historical fault-related data sets;

[0027] The fault-related data set is preprocessed, and a neural network is trained based on the preprocessed fault-related data set to obtain a fault prediction model.

[0028] To achieve the above-mentioned purpose, a second aspect of an embodiment of the present application provides a database switching device, the device comprising:

[0029] A data acquisition and processing module, configured to obtain fault-related data from the first database;

[0030] a fault prediction model module, configured to input the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database;

[0031] The switching module is used to switch the access database of the business system from the first database to the second database of the second electronic device through the gateway controller when the fault prediction result of the first database is a fault.

[0032] To achieve the above-mentioned purpose, the third aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor implements the method described in the first aspect when executing the computer program.

[0033] To achieve the above-mentioned purpose, the fourth aspect of the embodiments of the present application proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the method described in the first aspect.

[0034] A computer program product is stored in a storage medium and is executed by at least one processor to implement the method according to the first aspect.

[0035] The database switching method, apparatus, device, and storage medium proposed in this application obtain fault-related data from a first database; input the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database; and, if the fault prediction result of the first database indicates a fault, switch the access database of the business system from the first database to the second database of a second electronic device via a gateway controller. This application outputs the fault prediction result through the fault prediction model and then performs corresponding operations based on the fault prediction result. In this way, the fault prediction model responds to the input and makes predictions, enabling rapid identification of potential faults and predicting them before they occur, thereby enabling smooth database switching before a fault occurs. This solves the problem of low database switching efficiency caused by manual database switching when a database fault is manually determined, improves database switching efficiency, and enhances the stability and consistency of data access. Furthermore, automatic switching improves switching accuracy, further minimizing the business impact of database failures. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 is a flowchart of a database switching method provided in an embodiment of the present application;

[0037] Figure 2 yes Figure 1 One of the flowcharts of step S103 in FIG.

[0038] Figure 3 yes Figure 2 Flowchart of step S202 in FIG.

[0039] Figure 4 yes Figure 1 Flowchart 2 of step S103 in FIG. 2;

[0040] Figure 5 yes Figure 1 Flowchart 3 of step S103 in FIG.

[0041] Figure 6 This is a diagram of the database switching system architecture provided by an embodiment of the present application;

[0042] Figure 7Schematic diagram of the structure of the database switching device provided in an embodiment of the present application;

[0043] Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0045] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0046] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0047] First, let’s analyze some of the terms used in this application:

[0048] Business systems are computer software systems used by businesses or organizations to support their core business processes. These systems are designed to improve operational efficiency, manage resources, enhance the customer experience, and support decision-making. Business systems typically integrate multiple functional modules to meet the needs of different departments within the company, such as sales, marketing, finance, and human resources.

[0049] In the insurance industry, business systems are key tools used by insurers to manage their core business processes. These systems not only handle daily operations but also support complex tasks such as property and casualty insurance product management, health and medical insurance, and pension insurance product management, risk management, and customer relationship management. Common business systems in the insurance industry include core business systems, claims systems, customer relationship management systems, and actuarial systems.

[0050] CPU usage is the percentage of a central processing unit (CPU) used per unit of time. It is used to assess the computing resource utilization of a server or system and help identify performance bottlenecks.

[0051] Memory usage refers to the amount of memory used in a system, usually expressed in bytes or percentage. It reflects the system's memory resource usage and helps optimize memory allocation and management.

[0052] I / O wait time is the amount of time the system waits for input / output operations, typically measured in milliseconds. It is used to assess disk or network I / O performance and help identify I / O bottlenecks.

[0053] Log information can include system logs, application logs, and security logs. System logs record various events and operations during system operation, including system startup and shutdown, error messages, warning messages, and so on. System logs are used for system monitoring, troubleshooting, and security auditing. Application logs record various events and operations during application operation, including user logins, business operations, and exception handling. Application logs help developers debug and optimize applications and record business operation traces. Security logs record security-related events in systems and applications, such as user login failures, permission changes, and data access. Security logs can be used for security monitoring and auditing to prevent and track security threats.

[0054] Maintenance records can include system maintenance records, database maintenance records, and network maintenance records. System maintenance records: record detailed information about system maintenance operations, including maintenance time, maintenance content, maintenance personnel, and maintenance results. Database maintenance records: record detailed information about database maintenance operations, such as data backup, data recovery, and table structure optimization. Network maintenance records: record maintenance operations on network equipment and network configuration, including network troubleshooting and network optimization.

[0055] Network response time can include internal network response time and external network response time. Internal network response time refers to the communication response time between different systems and servers within a company's internal network. External network response time refers to the communication response time between a company and external networks (such as the Internet or partner networks).

[0056] Based on this, embodiments of the present application provide a database switching method, apparatus, device, and storage medium, aiming to improve the switching efficiency of existing methods.

[0057] The database switching method, apparatus, device, and storage medium provided in the embodiments of the present application are specifically described through the following embodiments. First, the database switching method in the embodiments of the present application is described.

[0058] The database switching method provided in the embodiment of the present application relates to the field of financial technology. The database switching method provided in the embodiment of the present application can be applied to electronic devices, and further, can be applied to the software of electronic devices. The electronic device can be a terminal or a server. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc.; the server can be configured as an independent physical server, or as a server cluster or distributed system composed of multiple physical servers, or as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the database switching method, etc., but is not limited to the above forms.

[0059] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0060] Figure 1 This is an optional flowchart of the database switching method provided in an embodiment of the present application, which is applied to a first electronic device. Figure 1 The method may include but is not limited to steps S101 to S103.

[0061] Step S101, obtaining fault-related data from the first database;

[0062] Step S102: inputting the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database;

[0063] Step S103 : when the fault prediction result of the first database is that a fault occurs, switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller.

[0064] In steps S101 to S103, as shown in the embodiment of the present application, fault-related data is obtained from a first database; the fault-related data is input into a preset fault prediction model to obtain a fault prediction result for the first database; and if the fault prediction result of the first database indicates a fault, the gateway controller switches the access database of the business system from the first database to the second database of the second electronic device. The present application outputs a fault prediction result through the fault prediction model and then performs corresponding operations based on the fault prediction result. In this way, the fault prediction model responds to the input and makes predictions, enabling rapid identification of potential faults and predicting them before they occur, thereby enabling smooth database switching before a fault occurs. This solves the problem of low database switching efficiency caused by manual database switching when a database fault is manually determined, improves database switching efficiency, and enhances the stability and consistency of data access. Automatic switching also improves switching accuracy, further avoiding the business impact of database failures.

[0065] In step S101 of some embodiments, fault-related data is collected from the first database. The fault-related data can be understood as data that will trigger a database failure. In some implementations, the fault-related data may include at least one of the following: performance indicators of the business system (CPU usage, memory usage, I / O waiting time), log information, maintenance records, network response time, etc.

[0066] It should be noted that the first electronic device may be an electronic device containing the first database, and may be a hardware device such as a server or computer. The first database may be a database storing business system data, located in the first electronic device, primarily providing data support for the business system and storing various system data. Fault-related data can be used as input to a fault prediction model to analyze and predict database fault conditions.

[0067] In step S102 of some embodiments, the collected fault-related data is input into a pre-trained fault prediction model.

[0068] It should be noted that the preset fault prediction model can be a pre-trained model for predicting database failures based on machine learning or deep learning algorithms. The preset fault prediction model can be used to predict the likelihood of a database failure by analyzing fault-related data. The fault prediction result can be the output of the fault prediction model, indicating whether a database failure is likely, and can be used as a basis for deciding whether to perform a database failover.

[0069] In step S103 of some embodiments, if the fault prediction model determines that the first database is about to fail, the database access request of the business system is switched from the first database to the second database on the second electronic device through the gateway controller.

[0070] It should be noted that the gateway controller can be a device or software component responsible for managing and controlling the business system's access to the database. The gateway controller can be used to switch the database of the business system from one database to another when needed. The second electronic device can be another electronic device, usually used as a backup device, containing a second database. The second electronic device can be used to provide backup database services when the first database fails. The second database can be a database located on the second electronic device, which can maintain data synchronization with the first database. The second database can serve as a backup for the first database and take over the data access requests of the business system when the first database fails.

[0071] Before the database switch, if a data access request from the business system is received, the gateway controller will resolve the domain name of the business system's access database to the IP address of the first database, and the business system will obtain data from the first database; after the database switch, that is, the domain name of the business system's access database will be resolved from the IP address of the first database to the IP address of the second database through the gateway controller, then the business system will obtain data from the second database.

[0072] Switching from the first database to the second database means that the second database is a backup database of the first database. Therefore, the first database can be understood as a primary database, and the second database can be understood as a standby database.

[0073] However, in the present application, the first database and the second database can serve as each other's backup databases, that is, when one of the databases fails, data access services can be provided through the other database.

[0074] See also Figure 2 In some embodiments, step S103 may include but is not limited to steps S201 to S205:

[0075] Step S201: Acquire the fault characteristic status of the first database; wherein the fault characteristic status includes at least one of the following: fault type, severity, and fault level;

[0076] Step S202: Based on the fault characteristic state, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller.

[0077] In step S201 of some embodiments, fault feature status of a first database is collected.

[0078] It should be noted that the fault characteristic status can be characteristic information describing a database fault, including at least one of the following: fault type, severity, and fault level. The fault characteristic status can be used to determine the nature and impact of the database fault, and to guide fault handling and database switching decisions. The fault type can refer to different types of faults that may occur in the first database, such as hardware faults, software faults, network faults, etc. The severity can describe the extent of the impact of the fault on the database operation and business system, and can be divided into levels such as minor, moderate, and severe. The fault level can be a level divided according to the type and severity of the fault, which is used to quantify and standardize the severity of the fault.

[0079] In some implementations, the fault characteristic state may be obtained from the output of a fault prediction model;

[0080] In other implementations, the fault characteristic status may be obtained through external tools and is not limited to a specific acquisition form.

[0081] In step S202 of some embodiments, based on the acquired fault characteristic status, a gateway controller is used to switch the database access request of the business system from the first database to the second database on the second electronic device.

[0082] It should be noted that a business system can be an application system that relies on a database to support various business operations. A business system can access and store data in a database to support daily business activities. In the insurance industry, a business system can provide technical support and a management platform for the design, sales, claims processing, and risk management of insurance products, such as medical insurance.

[0083] In this embodiment, by acquiring fault characteristic status and performing database switching based on this status, the business system can switch to a secondary backup database before or when a primary database failure occurs, thus avoiding business interruption. This not only reduces the risk of data loss but also minimizes the impact on business. When a primary database fails, the secondary database can continue to support business operations while the primary database is maintained and repaired, improving system maintainability. Detailed fault characteristic status allows for more accurate fault diagnosis and resolution, improving the targetedness and efficiency of fault resolution.

[0084] See also Figure 3 In some embodiments, step S202 may include but is not limited to steps S301 to S302:

[0085] Step S301: When the fault characteristic state of the first database is the first state, the fault prediction result is sent to the administrator, and when a confirmation switching instruction is received, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller;

[0086] Step S302: When the fault characteristic state of the first database is the second state, switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller;

[0087] The severity of the fault of the first database indicated by the first state is greater than the severity of the fault of the first database indicated by the second state.

[0088] In step S301 of some embodiments, the fault characteristic status of the first database is collected, including information such as the fault type, severity, and fault level. Based on predefined criteria, a determination is made as to whether the fault characteristic status is the first state or the second state. The first state indicates a minor fault, while the second state indicates a more severe fault. If the fault characteristic status is the first state, a fault prediction result is sent to an administrator, and the administrator's confirmation switch instruction is awaited. If the administrator confirms the need for a switch, the gateway controller switches the access database of the business system from the first database to the second database of the second electronic device.

[0089] It should be noted that the first state may be one of the fault characteristic states, indicating that the fault is relatively minor and may be a state that will not immediately affect the normal operation of the business system.

[0090] In step S302 of some embodiments, if the fault characteristic state is the second state, the access database of the business system is directly switched from the first database to the second database of the second electronic device through the gateway controller.

[0091] It should be noted that the second state may be one of the fault characteristic states, indicating that the fault is more serious and may be a state that affects the normal operation of the business system.

[0092] When the fault characteristic state includes multiple characteristic information (fault type, severity and / or fault level), the first state can be defined as: obtaining the values corresponding to each characteristic information; combining the values of each characteristic information respectively to obtain multiple states, each state including a value of different characteristic information; the first state and the second state are different states among the multiple states, and the first state is better than the second state.

[0093] In the embodiment of the present application, by obtaining the fault characteristic status and switching the database based on these statuses, the business system can semi-automatically or automatically switch to the backup second database before or when the first database fails, avoiding business interruption, thereby improving the reliability and stability of the business system. Secondly, when the first database fails, the second database can be used to continue to support business operations, while the first database is maintained and repaired, which can improve the maintainability of the business system. Thirdly, different response measures are taken according to the severity of the fault. You can either wait for the administrator's confirmation when the fault is minor, or directly switch the database when the fault is more serious. This flexible mechanism can adapt to different fault scenarios and ensure the stability of the business system and the continuity of the business.

[0094] See also Figure 4 In some embodiments, step S103 may also include, but is not limited to, step S401:

[0095] Step S401: Send the fault prediction result to the control terminal so that the control terminal generates a database switching command based on the fault prediction result, and sends the database switching command to the gateway controller; wherein, the database switching command is used to instruct the gateway controller to switch the access database of the business system from the first database to the second database of the second electronic device.

[0096] In step S401 of some embodiments, a fault prediction result of the first database is transmitted to a control terminal. After receiving the fault prediction result, the control terminal generates a database switching command based on the result. The control terminal transmits the generated database switching command to a gateway controller. Based on the received database switching command, the gateway controller switches the access database of the business system from the first database to the second database of the second electronic device.

[0097] It should be noted that the control terminal can be a device or software platform used to manage and monitor system operations, and can be used to receive fault prediction results and generate and send database switch commands. The database switch command can be an instruction generated by the control terminal and sent to the gateway controller, used to instruct the gateway controller to perform the database switch operation.

[0098] In an embodiment of the present application, through the collaborative work of the control terminal and the gateway controller, the business system can switch to the backup second database in a timely manner before or when the first database fails, thereby avoiding business interruption. At the same time, the timeliness and accuracy of the switching operation are also ensured. Secondly, switching databases before or when a failure occurs can reduce the risk of data loss and reduce the impact on the business. Thirdly, when the first database fails, the second database can be used to continue to support business operations while maintaining and repairing the first database, thereby improving the maintainability of the business system.

[0099] See also Figure 5 In some embodiments, step S103 may also include, but is not limited to, steps S501 to S503:

[0100] Step S501: Switching the domain name of the business system accessing the database from the Internet Protocol address of the first database to the Internet Protocol address of the second database through the gateway controller;

[0101] Step S502: closing a first data synchronization link between the first database and the second database, where the first data synchronization link is used to synchronize data in the first database to the second database;

[0102] Step S503: Open a second data synchronization link between the second database and the first database, where the second data synchronization link is used to synchronize data in the second database to the first database.

[0103] In step S501 of some embodiments, the gateway controller switches the domain name resolution used by the business system to access the database from the IP address of the first database to the IP address of the second database, so that the business system can access the second database through the new IP address, ensuring business continuity.

[0104] It should be noted that a domain name can be a hierarchical text name used to identify and locate computers on the internet, allowing business systems to access databases through the domain name, which resolves to a specific IP address. An Internet Protocol address (IP address) can be a numerical label used to uniquely identify a device on a network, and its purpose can be to establish a connection between a business system and a database through the IP address.

[0105] In step S502 of some embodiments, the data synchronization process from the first database to the second database is stopped to avoid conflicts or inconsistencies caused by data synchronization during the switching process, or to avoid failures in the second database.

[0106] It should be noted that the first data synchronization link may be a link for synchronizing data in the first database to the second database. The first data synchronization link may ensure data consistency between the second database and the first database.

[0107] In step S503 of some embodiments, a data synchronization process from the second database to the first database is started.

[0108] It should be noted that the second data synchronization link may be a link for synchronizing data in the second database to the first database. The second data synchronization link may ensure that the first database can obtain the latest data from the second database after switching.

[0109] In the embodiment of the present application, by switching the domain name and IP address, the business system can seamlessly switch to the second database, avoiding business interruption due to failure of the first database, and improving the reliability and stability of the business system. During the switching process, the first data synchronization link is closed and the second data synchronization link is opened to ensure the consistency and integrity of the data and the continuity and stability of the business. When the first database fails, the second database can be used to continue to support business operations while maintaining and repairing the first database, thereby improving the maintainability of the business system.

[0110] In some embodiments, after step S103, the following steps may be included but are not limited to steps S601 to S602:

[0111] Step S601: Sending a switching result of switching the access database of the business system from the first database to the second database to the control terminal, and recording relevant information of the switching of the access database of the business system from the first database to the second database; wherein the switching result is that the first database is successfully switched to the second database;

[0112] Step S602: Detect information of the second database, and synchronously send the information of the second database to an administrator; wherein the information of the second database includes the status of the second database and the business operation status of the second database.

[0113] In step S601 of some embodiments, after the database switch is completed, the switch result (ie, the first database is successfully switched to the second database) is sent to the control terminal, and information related to the switch from the first database to the second database is recorded in the business system.

[0114] It should be noted that the switchover result can indicate whether the database switchover operation was successful. This can be used to confirm the completion of the switchover operation and ensure the normal operation of the business system. Related information can include detailed information related to the database switchover, including the switchover time, switchover reason, and key data from the switchover process. This information can provide a basis for subsequent auditing, analysis, and troubleshooting.

[0115] In step S602 of some embodiments, the status and service operation of the second database are detected and relevant data is collected to ensure that the second database can operate normally after the switch. At the same time, the detected status and service operation of the second database are sent to the administrator, allowing the administrator to understand the operating status of the second database in real time and perform necessary management and maintenance.

[0116] It should be noted that the information on the second database may include information such as the status of the second database and business operation status. This information can help administrators understand the operational status of the second database and promptly identify and address issues. The status of the second database can describe the current operational status of the second database, such as normal or faulty. The business operation status can describe whether the business system can operate normally after the switch, including indicators such as response time and error rate.

[0117] In the embodiments of the present application, by sending switching results and recording related information, the business system can ensure the success of the switching operation and promptly identify and address potential issues, thereby improving the reliability and stability of the business system. Secondly, the detailed records and real-time information can help managers quickly locate and resolve problems, improving maintainability. Thirdly, by confirming switching results and detecting status information, the business system can ensure data consistency and integrity.

[0118] For example, referring to Figure 6 , Figure 6 A database switching system architecture diagram provided for an embodiment of the present application.

[0119] Based on the use of insurance business system database, a database switching solution is designed. As shown in the figure, it includes business system module, database module, data acquisition and processing module, fault prediction module and control terminal module. The specific implementation process is as follows:

[0120] 1. When the business system accesses the database domain name, the gateway normally resolves it to the primary database IP address (10.xxxx). The primary database (primary database) and the standby database (backup database) synchronize data in real time through the primary synchronization link to maintain data consistency between the two databases.

[0121] 2. The data acquisition and processing module collects database performance indicators (CPU usage, memory usage, I / O wait time, etc.), log information, network status, maintenance records, and other data in real time. Feature data is extracted from the collected data using preprocessing methods.

[0122] 3. The characteristic data obtained above is input into the fault prediction model, which analyzes and evaluates the data characteristics and outputs the prediction results.

[0123] 4. After the prediction results are sent to the management terminal (management personnel and control terminal), the management terminal executes the corresponding strategy according to the prediction results.

[0124] (1) When the management terminal receives normal prediction results from the database, it does not perform any control;

[0125] (2) When the management terminal receives the predicted result of the database failure, it issues an alarm to notify the system administrator to confirm whether the switch can be made. Based on the feedback from the administrator, the control terminal determines the execution strategy again:

[0126] ① If the administrator confirms that the switch cannot be made, no intervention command will be issued;

[0127] ② If it is confirmed that the switch is possible, the control terminal sends a switch instruction to the gateway controller.

[0128] 5. When the gateway controller receives the switching command from the control terminal, it automatically resolves the database domain name to the standby database IP (20.xxxx), and at the same time triggers the synchronization link command to stop the main synchronization link and enable the standby synchronization link.

[0129] 6. After switching to the standby database, the switchover result is returned to the control terminal, and the standby database's operating status information is synchronously sent to the administrator, notifying them to monitor the database status and business operations to ensure a successful switchover and normal business operation. Execution log information during the switchover process is recorded and stored in real time for subsequent analysis and auditing.

[0130] In some embodiments, before step S101, the following steps may be performed, including but not limited to steps S701 to S702:

[0131] Step S701, obtaining historical fault-related data sets;

[0132] Step S702 : preprocessing the fault-related data set, and training a neural network based on the preprocessed fault-related data set to obtain a fault prediction model.

[0133] In step S701 of some embodiments, previously accumulated data related to database failures is collected, including but not limited to failure type, occurrence time, duration, related logs, system resource usage, etc. This provides rich training samples for subsequent model training, enabling the model to learn the characteristics and patterns of different failure modes.

[0134] It should be noted that the historical fault-related data set may be a data set related to database faults accumulated in the past, and may include relevant information when various faults occur and sample data during normal operation.

[0135] In step S702 of some embodiments, the corresponding operations may include: 1. Data cleaning: removing noise, erroneous data, and duplicate data from the data; 2. using different preset processing methods for different data and performing numerical processing on the cleaned data; 3. Data normalization: converting data of different ranges and dimensions to the same scale to facilitate model processing and training; 4. Feature selection and extraction: selecting features highly relevant to fault prediction from historical fault-related data and extracting key information that can effectively characterize the fault mode. 5. Data segmentation: dividing the preprocessed dataset into a training set, a validation set, and a test set, typically with a ratio of 700%, 20%, 10%, or other reasonable allocation methods. The neural network structure is then defined, and parameters such as the neural network weights and biases are initialized. An appropriate loss function is selected based on the objective of the fault prediction task. The training set data is input into the neural network, and the prediction results are calculated through forward propagation. The loss function value is then calculated to measure the difference between the prediction results and the true label (the label corresponding to each sample data). The gradient is then calculated through the backpropagation algorithm, and the network parameters are updated using the optimizer. This process is iterated continuously until the model performance on the training and validation sets meets the expected requirements or convergence conditions. The trained model is evaluated using the test set, and the performance of the model is judged based on the evaluation results, such as accuracy, recall rate, F1 score, and other indicators. If the performance is not ideal, the network structure and hyperparameters can be adjusted and optimized, and the model can be retrained to improve its prediction performance.

[0136] It's important to note that when preparing training samples, each sample data is labeled accordingly. The label of a training sample identifies or categorizes the output corresponding to the input data, guiding the model to learn the mapping relationship between input data and output results. In database fault prediction scenarios, labels can indicate information such as whether the sample is in a fault state and the specific fault type.

[0137] Exemplarily, the construction of the fault prediction model can be explained as follows:

[0138] 1. Collect historical data: Collect fault-related data from the insurance company's multiple databases. This data should include performance metrics (CPU usage, memory usage, I / O wait time), log information, maintenance records, and network response time.

[0139] 2. Data preprocessing

[0140] (1) Data cleaning: remove missing or abnormal data records in the collected data.

[0141] (2) Numerical processing: Among the features listed above, log information and maintenance records are non-numerical information. The processing methods for these two features are as follows:

[0142] Log information: Checks whether there are suspected abnormal keywords in the log records. If the keyword does not exist, it is marked as 1; if the keyword exists, it is marked as 0.

[0143] Maintenance records: Count the number of maintenance records that have existed in each database in history and mark them with the number of maintenance records.

[0144] (3) Data normalization: Use the max-min normalization method to normalize the feature data to the same scale for subsequent processing.

[0145] 3. BP neural network model construction and training

[0146] (1) Network model structure construction: The input of the BP neural network is the data set features, and the output is the prediction result of whether there is a fault. In this method, we selected 6 features and the output is the prediction result, so the BP neural network structure is designed as a network layer with 6 inputs and 1 output.

[0147] (2) Model training and verification

[0148] Dataset division: The preprocessed data is divided into training set, validation set and test set in a ratio of 7:2:1. The training set is used for model training, the validation set is used for model selection, and the test set is used to evaluate model performance.

[0149] The BP neural network was trained using the standard PyTorch framework using the training set. Through continuous iterative verification, the final database fault prediction model was trained.

[0150] In the embodiments of the present application, by using historical fault-related data sets for sufficient preprocessing and neural network training, the resulting fault prediction model can more accurately identify and predict database fault conditions. The model can learn the characteristics and patterns of different fault modes from a large amount of historical data, so that when faced with new data, it can make accurate judgments based on the learned knowledge, thereby improving the accuracy and reliability of fault prediction. With the help of an accurate and reliable fault prediction model, the business system can detect possible database faults in advance, providing administrators with sufficient time to take preventive measures such as adjusting system parameters, backing up data, switching to a backup database, etc., thereby avoiding the serious impact of faults on the business system and reducing the risk of business system downtime and data loss. Through the early warning function of the fault prediction model, operation and maintenance personnel can carry out maintenance work more targetedly, avoiding blindly conducting comprehensive inspections and maintenance of the system, saving a lot of manpower, material resources and time resources. At the same time, the frequency and severity of faults are reduced, and the additional costs incurred by fault repair, such as emergency repair costs and data recovery costs, are also reduced. As new fault data and normal operation data are continuously collected and added to historical data sets, and the model is retrained and optimized, the performance of the fault prediction model will continue to improve. This enables the system to better adapt to the ever-changing operating environment and technical requirements, achieve self-optimization and improvement, and provide stronger guarantees for the stable operation of the business system.

[0151] See also Figure 7 The embodiment of the present application further provides a database switching device that can implement the above database switching method, and the device includes:

[0152] The data acquisition and processing module 701 is used to obtain fault-related data from the first database;

[0153] A fault prediction model module 702 is configured to input the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database;

[0154] The switching module 703 is configured to switch the access database of the business system from the first database to the second database of the second electronic device through the gateway controller when the fault prediction result of the first database is that a fault occurs.

[0155] The specific implementation of the database switching device is substantially the same as the specific embodiment of the above-mentioned database switching method, and will not be described in detail here.

[0156] The present application also provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the above-mentioned database switching method when executing the computer program. The electronic device can be any smart terminal including a tablet computer, an in-vehicle computer, or the like.

[0157] See also Figure 8 , Figure 8 The hardware structure of an electronic device according to another embodiment is shown. The electronic device includes:

[0158] The processor 801 can be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0159] The memory 802 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 802 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 802 and is called by the processor 801 to execute the database switching method of the embodiments of this application.

[0160] Input / output interface 803, used to implement information input and output;

[0161] Communication interface 804, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0162] Bus 805 , which transmits information between various components of the device (e.g., processor 801 , memory 802 , input / output interface 803 , and communication interface 804 );

[0163] The processor 801 , the memory 802 , the input / output interface 803 and the communication interface 804 are connected to each other in communication within the device via a bus 805 .

[0164] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned database switching method is implemented.

[0165] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0166] The database switching method, apparatus, device, and storage medium provided in embodiments of the present application obtain fault-related data from a first database; input the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database; and, if the fault prediction result of the first database indicates a fault, switch the access database of the business system from the first database to the second database of a second electronic device via a gateway controller. The present application outputs a fault prediction result through the fault prediction model and then performs corresponding operations based on the fault prediction result. Thus, the fault prediction model makes predictions in response to input, enabling rapid identification of potential faults and predicting them before they occur, thereby enabling smooth database switching before a fault occurs. This solves the problem of low database switching efficiency caused by manually switching databases when a database fault is manually determined, improves database switching efficiency, and enhances the stability and consistency of data access. Furthermore, automatic switching can improve switching accuracy, further avoiding the business impact of database failures.

[0167] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0168] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0169] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0170] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0171] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0172] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0173] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the above-mentioned units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0174] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0175] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0176] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: various media that can store programs, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0177] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. A database switching method, characterized in that: Applied to a first electronic device, the first electronic device includes a first database, and the method includes: Obtaining fault-related data from the first database; Inputting the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database; When the fault prediction result of the first database is that a fault occurs, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller.

2. The method according to claim 1, characterized in that The step of switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller includes: Obtaining a fault characteristic state from the first database; wherein the fault characteristic state includes at least one of the following: fault type, severity, and fault level; Based on the fault characteristic state, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller.

3. The method according to claim 2, characterized in that The method of switching, based on the fault characteristic information, the access database of the business system from the first database to the second database of the second electronic device through the gateway controller includes: When the fault characteristic state of the first database is the first state, the fault prediction result is sent to the administrator, and when a confirmation switching instruction is received, the access database of the business system is switched from the first database to the second database of the second electronic device through the gateway controller; When the fault characteristic state of the first database is the second state, switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller; The severity of the fault of the first database indicated by the first state is greater than the severity of the fault of the first database indicated by the second state.

4. The method according to claim 1, wherein The step of switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller includes: Send the fault prediction result to the control terminal so that the control terminal generates a database switching command based on the fault prediction result, and sends the database switching command to the gateway controller; wherein the database switching command is used to instruct the gateway controller to switch the access database of the business system from the first database to the second database of the second electronic device.

5. The method according to claim 1, wherein The step of switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller includes: Switching, by the gateway controller, the domain name of the business system accessing the database from the Internet Protocol address of the first database to the Internet Protocol address of the second database; closing a first data synchronization link between the first database and the second database, where the first data synchronization link is used to synchronize data in the first database to the second database; A second data synchronization link is opened between the second database and the first database, where the second data synchronization link is used to synchronize data in the second database to the first database.

6. The method according to claim 1, characterized in that After switching the access database of the business system from the first database to the second database of the second electronic device through the gateway controller, the method includes: Sending a switching result of switching the access database of the business system from the first database to the second database to the control terminal, and recording relevant information of the switching of the access database of the business system from the first database to the second database; wherein the switching result is that the first database is successfully switched to the second database; Detecting information of the second database and synchronously sending the information of the second database to an administrator; wherein the information of the second database includes the status of the second database and the business operation status of the second database.

7. The method according to claim 1, characterized in that Before acquiring the fault-related data from the first database, the method includes: Obtain historical fault-related data sets; The fault-related data set is preprocessed, and a neural network is trained based on the preprocessed fault-related data set to obtain a fault prediction model.

8. A database switching device, characterized in that: The database switching device includes: A data acquisition and processing module, configured to obtain fault-related data from the first database; a fault prediction model module, configured to input the fault-related data into a preset fault prediction model to obtain a fault prediction result for the first database; The switching module is used to switch the access database of the business system from the first database to the second database of the second electronic device through the gateway controller when the fault prediction result of the first database is a fault.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the database switching method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the database switching method according to any one of claims 1 to 7 is implemented.

Images