Application layer fault tolerance method and system in MySQL master-slave mode

Abstract

The present invention discloses an application layer fault tolerance method and system in MySQL master-slave mode, belonging to the technical field of database disaster tolerance. The present invention aims to solve the technical problem that the MySQL master-slave synchronization mechanism may cause data inconsistency. The technical scheme adopted is as follows: the method is specifically as follows: deploying an application layer database; deploying an unsynchronized data access control system database table; the application layer logs in to the unsynchronized data access control system; the application layer writes a business table. The system includes a deployment module 1, a deployment module 2, a login module and a write module, which are used to write a business table at the application layer.

Description

Technical Field

[0001] The present invention relates to the technical field of database disaster tolerance, in particular to an application layer fault tolerance method and system in a MySQL master-slave mode. Background Art

[0002] With the rapid development of Internet information technology, the amount of data continues to increase, business logic is becoming more complex, and there are more and more scenarios for high-concurrency access to the system and massive data processing. How to achieve the goals of high availability, scalability, and extensibility of the system at a lower cost is becoming increasingly important. In order to solve this series of problems, the system architecture is also constantly evolving. Traditional centralized systems have gradually failed to meet the requirements, and distributed systems are being used in more scenarios.

[0003] The requirements for system availability and data reliability determine that the underlying database needs to provide backup to prevent the entire system from being unavailable or data loss due to database failure. However, in a distributed system, the complexity of the environment and the uncertainty of the network will cause great difficulties in state synchronization between nodes. Problems such as machine crashes and message loss that exist in centralized systems will also become more complicated in a distributed environment. This puts higher requirements on the data consistency of multiple copies of the database.

[0004] In reality, many business scenarios, such as financial systems, have high requirements for data reliability and system availability. According to the CAP theory, the system must make trade-offs between reliability, availability, and partition tolerance. As a result, many protocols suitable for distributed systems have emerged, such as Paxos and Raft, which can ideally solve the system's availability and reliability. In order to solve the data consistency of distributed nodes, some theories and solutions have emerged, such as the CAP theory, distributed consistency protocols Paxos, Raft, and Zab. These methods have effectively solved the data consistency problem of distributed systems.

[0005] The strongest consistency implementation, such as synchronous double writing, completely eliminates the problem of data inconsistency in data copies, but any copy failure will cause the system to be unable to provide services normally, so it does not meet most business scenarios. MySQL provides synchronization solutions between master and slave nodes, such as asynchronous replication and semi-synchronization, to ensure the availability of the system. However, in asynchronous replication mode, binlog is sent to the slave database asynchronously, and the transaction submission of the master database does not care whether the binlog has been sent to the slave database. In semi-synchronous replication, the master database waits for the binlog to be sent to the slave database relay_log before submitting the transaction. Asynchronous replication is suitable for scenarios with low latency and low requirements for data consistency, while semi-synchronous replication is suitable for scenarios with higher consistency requirements. However, neither of the two synchronization solutions can guarantee data consistency in the event of a failure.

[0006] Therefore, how to solve the data inconsistency that may be caused by the MySQL master-slave synchronization mechanism is a technical problem existing in the current prior art. Summary of the invention

[0007] The technical task of the present invention is to provide an application layer fault tolerance method and system in MySQL master-slave mode to solve the problem of data inconsistency that may be caused by MySQL master-slave synchronization mechanism.

[0008] The technical task of the present invention is achieved in the following way: an application layer fault tolerance method in MySQL master-slave mode, the method is as follows:

[0009] Deploy application layer database;

[0010] Deployment of unsynchronized data access control system database tables;

[0011] Application layer login unsynchronized data access control system;

[0012] The application layer writes the business table.

[0013] As a preferred method, the application layer database is deployed as follows:

[0014] Enable MySQL master-slave asynchronous replication mode;

[0015] A pre-written version number field is added to the business table. The pre-written version number is used to write the return value of the unsynchronized database access control system.

[0016] More preferably, the fields of the unsynchronized data access control system database table include business ID, database ID, business table name, primary key column name, primary key value and pre-written version number;

[0017] Among them, the business ID is used to assign an ID to the business layer to distinguish different businesses;

[0018] The database ID refers to the business database ID. When logging in at the application layer, the business database deployment information is registered to the unsynchronized database access control system;

[0019] The pre-written version number of the unsynchronized data access control system database table is used to check whether the unsynchronized record in the business standby database has been synchronized.

[0020] As a preferred embodiment, the application layer logs in to the unsynchronized data access control system as follows:

[0021] The application layer sends a login request to the unsynchronized database access control system;

[0022] The content of the application layer request includes the user name, login timestamp, primary database ID and / or primary database connection information, standby database ID and / or connection information list, and summary information;

[0023] The content of the response of the unsynchronized database access control system includes the return code, business ID and token; the business ID uniquely identifies the user; the token of the unsynchronized database access control system response represents the signature of (user name | login timestamp | primary database ID | standby database ID list | business ID);

[0024] Login authentication: The unsynchronized database access control system uses the password corresponding to the user in the local database to encrypt the request message, obtain the summary information, and compare it with the summary information in the request to determine whether they are the same:

[0025] If they are the same, the authentication is successful.

[0026] As a preferred embodiment, the application layer writes the service table as follows:

[0027] Pre-request the unsynchronized data access control system to check whether writing is allowed;

[0028] After the requester receives the write-allowed response message, the application layer requests to write to the business database and updates the returned pre-written version number to the business table;

[0029] Since the MySQL cluster where the business table is located has master-slave asynchronous replication enabled, the write operation including the pre-written version number of the record will be synchronized to each slave database in a very short time under normal circumstances;

[0030] The unsynchronized data access control system checks whether the write operation has been synchronized to each standby database based on the pre-written version number cycle;

[0031] According to the connection information of each database node in the login information, query the pre-written version number of the record in the corresponding standby database, and compare it with the local pre-written version number to determine whether the pre-written version numbers are the same:

[0032] If they are the same, the corresponding records are erased from the unsynchronized data access control system database table (UNSYNC_TABLE table);

[0033] When a single point failure of MySQL occurs and a master-slave switch occurs, the application layer needs to log in again and carry the latest master-slave database information; and the pre-write request needs to carry the latest Header information. At the same time, based on the logic of whether writing is allowed, the access control table of the new master database will be automatically enabled to perform write access control;

[0034] When MySQL recovers from a failure, the control system database table (UNSYNC_TABLE) is accessed based on the unsynchronized data in each standby database to restore data from the failed node.

[0035] Preferably, whether writing is allowed is determined as follows:

[0036] Use the business ID, master database ID information, and request parameters in the Header to query whether the unsynchronized data access control system database table (UNSYNC_TABLE) is empty:

[0037] If the query result is not empty, it means that the last write operation of this record in the unsynchronized data access control system database table (UNSYNC_TABLE table) has not been synchronized to this node, so writing is not allowed this time, and a message indicating that writing is not allowed is returned to the application layer;

[0038] If the query result is empty, a pre-written version number is generated, and several records are inserted into the unsynchronized data access control system database table (UNSYNC_TABLE table) according to the business table name, primary key column name, primary key value, business ID in the header, business standby database ID list (as the database ID field in the UNSYNC_TABLE table, split into several database IDs) and pre-written version number in the request message body; then a write-allowed response message is returned to the requester;

[0039] The content requested by the requester includes Header {user name | login timestamp | primary database ID | backup database ID list | business ID + login token}, business table name, primary key list, primary key value and business callback data; the login token is issued by the unsynchronized data access control system at login; the unsynchronized data access control system verifies whether the token is legal based on the information in the Header: if it is not legal, the request is ignored; the business callback data requested by the requester is filled in by the requester to uniquely identify the request, so as to trigger the corresponding logic after the return;

[0040] The content of the requester's response includes whether writing is allowed, the pre-written version number and the business callback data; the pre-written version number of the requester's response is generated by the unsynchronized data access control system and is used to identify the write version of the business data; the business callback data of the requester's response is used for the transparent transmission field and is filled in by the requester.

[0041] As a preferred embodiment, the node deployment of the unsynchronized database access control system is as follows:

[0042] The unsynchronized data access control system adopts active-standby multi-node deployment, where the active-standby multi-nodes are connected to the same database. Under normal circumstances, only the active node provides services.

[0043] When the primary node fails, the primary node is blocked, and the standby node is upgraded to the primary node. After pulling the full unsynchronized list from the database to the cache, it starts to provide services.

[0044] When a database node fails, the write operation is downgraded to write-ahead log plus write cache. After the database node recovers, the full cache is flushed to the database node.

[0045] An application layer fault-tolerant system in MySQL master-slave mode, the system comprising:

[0046] Deployment module 1, used to deploy the application layer database;

[0047] Deployment module 2, used to deploy the unsynchronized data access control system database table;

[0048] Login module, used for application layer to log in to the unsynchronized data access control system;

[0049] The writing module is used to write business tables at the application layer.

[0050] An electronic device comprising: a memory and at least one processor;

[0051] Wherein, the memory stores a computer program;

[0052] The at least one processor executes the computer program stored in the memory, so that the at least one processor executes the application layer fault tolerance method in the MySQL master-slave mode as described above.

[0053] A computer-readable storage medium stores a computer program, which can be executed by a processor to implement the application layer fault tolerance method in the MySQL master-slave mode as described above.

[0054] The application layer fault tolerance method and system in the MySQL master-slave mode of the present invention have the following advantages:

[0055] (I) The present invention provides a simple unsynchronized data access control mechanism in the MySQL master-slave synchronization mode, which mainly solves the data inconsistency problem that may be caused by the MySQL master-slave synchronization mechanism;

[0056] (ii) The present invention only implements the unsynchronized data access control logic, and does not need to implement the distributed consistency protocol, which is simple to implement. In addition, since it does not adopt the traditional quorum mechanism, it does not require more than half of the nodes to be alive, thereby improving the availability of the system;

[0057] (III) The present invention introduces an unsynchronized data access control system to ensure data reliability before and after the master-slave switch; shield access to individual inconsistent records when the master-slave switch occurs due to a single-point failure in MySQL, and resynchronize the inconsistent records after the failure is recovered; the upper-layer application does not need to stop external services when a single-point failure in the database occurs, thus ensuring the basic availability of the system and the reliability of the data;

[0058] (iv) The present invention uses MySQL's own synchronization mechanism to increase access control of unsynchronized data. The logic is relatively simple, making it easy to implement stable services, thereby improving service availability and reliability.

[0059] (V) Since most of the time, data is synchronized normally, the unsynchronized record list of the unsynchronized data access control system is empty, and the additional storage overhead is very small;

[0060] (VI) The present invention does not require more than half of the nodes to be alive like the quorum mechanism. In extreme cases, only one MySQL node is left and can provide external services, thereby improving the availability of the system.

[0061] (VII) The present invention introduces an unsynchronized data access control mechanism, sacrificing the access availability of a small part of the data in the event of a failure in exchange for the overall availability of the system and the consistency of the data. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The present invention is further described below in conjunction with the accompanying drawings.

[0063] Attached Figure 1 This is a flowchart of the application layer fault tolerance method in MySQL master-slave mode. DETAILED DESCRIPTION

[0064] The application layer fault tolerance method and system in the MySQL master-slave mode of the present invention are described in detail below with reference to the accompanying drawings and specific embodiments of the specification.

[0065] Example 1

[0066] As attached Figure 1 As shown, the application layer fault tolerance method in the MySQL master-slave mode of the present invention is as follows:

[0067] S1. Deploy application layer database;

[0068] S2, deploying unsynchronized data access control system database tables;

[0069] S3, application layer login unsynchronized data access control system;

[0070] S4. The application layer writes the business table.

[0071] The deployment of the application layer database in step S1 of this embodiment is specifically as follows:

[0072] S101, enable MySQL master-slave asynchronous replication mode;

[0073] S102. Add a pre-written version number field in the business table. The pre-written version number is used to write the return value of the unsynchronized database access control system, as shown in the following table:

[0074]

[0075] The fields of the unsynchronized data access control system database table in this embodiment include business ID, database ID, business table name, primary key column name, primary key value and pre-written version number; as shown in the following table:

[0076]

[0077] Among them, the business ID is used to assign an ID to the business layer to distinguish different businesses;

[0078] The database ID refers to the business database ID. When logging in at the application layer, the business database deployment information is registered to the unsynchronized database access control system;

[0079] The pre-written version number of the unsynchronized data access control system database table is used to check whether the unsynchronized record in the business standby database has been synchronized.

[0080] The application layer logs in to the unsynchronized data access control system in step S3 of this embodiment as follows:

[0081] S301, the application layer sends a login request to the unsynchronized database access control system;

[0082] The content of the application layer request includes the user name, login timestamp, primary database ID and / or primary database connection information, standby database ID and / or connection information list, and summary information, as shown in the following table:

[0083]

[0084] The content of the response of the unsynchronized database access control system includes the return code, business ID and token; the business ID uniquely identifies the user; the token of the unsynchronized database access control system response represents the signature of (user name | login timestamp | primary database ID | standby database ID list | business ID); as shown in the following table:

[0085]

[0086] S302, login authentication: The unsynchronized database access control system uses the password corresponding to the user in the local database to encrypt the request message using the password corresponding to the user, obtains summary information, and compares it with the summary information in the request to determine whether they are the same:

[0087] If they are the same, the authentication is successful.

[0088] The application layer writes the service table in step S4 of this embodiment as follows:

[0089] S401, pre-requesting an unsynchronized data access control system to check whether writing is allowed;

[0090] S402: After the requester receives the write-allowed response message, the application layer requests to write to the business database and updates the returned pre-written version number to the business table;

[0091] S403. Since the MySQL cluster where the business table is located has master-slave asynchronous replication enabled, the write operation including the pre-written version number of the record will be synchronized to each slave database in a very short time under normal circumstances.

[0092] S404, the unsynchronized data access control system checks whether the write operation has been synchronized to each standby database according to the pre-written version number cycle;

[0093] S405. According to the connection information of each database node in the login information, query the pre-written version number of the record in the corresponding standby database, compare it with the local pre-written version number, and determine whether the pre-written version numbers are the same:

[0094] If they are the same, the corresponding records will be erased from the UNSYNC_TABLE table;

[0095] S406. When a single point failure of MySQL occurs and a master-slave switch occurs, the application layer needs to log in again and carry the latest master-slave database information; and the pre-write request needs to carry the latest Header information. At the same time, according to the logic of whether writing is allowed, the access control table of the new master database will be automatically enabled to perform write access control;

[0096] S407. After the MySQL failure is recovered, data is restored from the failed node according to the UNSYNC_TABLE table of each standby database.

[0097] In this embodiment, whether writing is allowed in step S401 is determined as follows:

[0098] S40101. Check whether the UNSYNC_TABLE table is empty by using the business ID, master database ID information and request parameters in the Header:

[0099] If the query result is not empty, it means that the last write operation of this record in the UNSYNC_TABLE table has not been synchronized to this node. This write operation is not allowed and a message indicating that write operation is not allowed is returned to the application layer.

[0100] If the query result is empty, a pre-written version number is generated, and several records are inserted into the UNSYNC_TABLE table according to the business table name, primary key column name, primary key value, business ID in the header, business standby database ID list (as the database ID field in the UNSYNC_TABLE table, split into several database IDs) and the pre-written version number in the request message body; then a write-allowed response message is returned to the requester;

[0101] The content requested by the requester includes Header {user name | login timestamp | primary database ID | backup database ID list | business ID + login token}, business table name, primary key list, primary key value and business callback data; the login token is issued by the unsynchronized data access control system at login; the unsynchronized data access control system verifies whether the token is legal based on the information in the Header: if it is not legal, the request is ignored; the business callback data requested by the requester is filled in by the requester to uniquely identify the request, so as to trigger the corresponding logic after the return; as shown in the following table:

[0102]

[0103] The content of the requester's response includes whether writing is allowed, the pre-written version number, and the business callback data; the pre-written version number of the requester's response is generated by the unsynchronized data access control system and is used to identify the write version of the business data; the business callback data of the requester's response is used for the transparent transmission field and is filled in by the requester; as shown in the following table:

[0104]

[0105] The node deployment of the unsynchronized database access control system in this embodiment is as follows:

[0106] (1) The unsynchronized data access control system adopts a master-slave multi-node deployment, where the master and backup nodes are connected to the same database. Under normal circumstances, only the master node provides services.

[0107] (2) When the primary node fails, the primary node is blocked, and the standby node is upgraded to the primary node. After pulling the full unsynchronized list from the database to the cache, it starts to provide services;

[0108] (3) When a database node fails, the write operation is downgraded to write-ahead log plus write cache. After the database node recovers, the full cache is flushed to the database node.

[0109] Example 2

[0110] This embodiment provides an application layer fault-tolerant system in MySQL master-slave mode, the system comprising:

[0111] Deployment module 1, used to deploy the application layer database;

[0112] Deployment module 2, used to deploy the unsynchronized data access control system database table;

[0113] Login module, used for application layer to log in to the unsynchronized data access control system;

[0114] The writing module is used to write business tables at the application layer.

[0115] Example 3

[0116] This embodiment also provides an electronic device, including: a memory and a processor;

[0117] Wherein, the memory stores computer-executable instructions;

[0118] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the application layer fault tolerance method in the MySQL master-slave mode in any embodiment of the present invention.

[0119] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor may be a microprocessor or any conventional processor, etc.

[0120] The memory can be used to store computer programs and / or modules. The processor realizes various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created according to the use of the terminal, etc. In addition, the memory can also include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (SMC), a secure digital (SD) card, a flash memory card, at least one disk storage period, a flash memory device, or other volatile solid-state storage devices.

[0121] Example 4

[0122] The embodiment of the present invention further provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions are loaded by a processor, so that the processor executes the application layer fault tolerance method in the MySQL master-slave mode in any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, on which a software program code that implements the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or device reads and executes the program code stored in the storage medium.

[0123] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.

[0124] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code may be downloaded from a server computer via a communication network.

[0125] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling an operating system operating on the computer to complete part or all of the actual operations based on instructions from the program code.

[0126] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or written to a memory provided in an expansion unit connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or the expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.

[0127] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. An application layer fault tolerance method in MySQL master-slave mode, characterized in that: The method is as follows: Deploy application layer database; Deployment of unsynchronized data access control system database tables; Application layer login unsynchronized data access control system; The application layer writes the business table; The deployment of the application layer database is as follows: Enable MySQL master-slave asynchronous replication mode; Add a pre-written version number field in the business table. The pre-written version number is used to write the return value of the unsynchronized data access control system. The fields of the unsynchronized data access control system database table include business ID, database ID, business table name, primary key column name, primary key value, and pre-written version number; Among them, the business ID is used to assign an ID to the business layer to distinguish different businesses; The database ID refers to the business database ID. When logging in at the application layer, the business database deployment information is registered to the unsynchronized data access control system; The pre-written version number of the unsynchronized data access control system database table is used to check whether the unsynchronized records in the business standby database have been synchronized; The application layer login unsynchronized data access control system is as follows: The application layer sends a login request to the unsynchronized data access control system; The content of the application layer request includes the user name, login timestamp, primary database ID and / or primary database connection information, standby database ID and / or connection information list, and summary information; The content of the response of the unsynchronized data access control system includes a return code, a business ID, and a token; the business ID uniquely identifies the user; the token of the unsynchronized data access control system represents the signature; Login authentication: The unsynchronized data access control system uses the password corresponding to the user in the local database to encrypt the request message, obtain the summary information, and compare it with the summary information in the request to determine whether they are the same: If they are the same, the authentication is passed; The application layer writes the business table as follows: Pre-request the unsynchronized data access control system to check whether writing is allowed; After the requester receives the write-allowed response message, the application layer requests to write to the business database and updates the returned pre-written version number to the business table; The write operation, including the recorded pre-written version number, will be synchronized to each standby database; The unsynchronized data access control system checks whether the write operation has been synchronized to each standby database based on the pre-written version number cycle; According to the connection information of each database node in the login information, query the pre-written version number of the record in the corresponding standby database, and compare it with the local pre-written version number to determine whether the pre-written version numbers are the same: If they are the same, the corresponding records are erased from the unsynchronized data access control system database table; When a single point failure of MySQL occurs and a master-slave switch occurs, the application layer needs to log in again and carry the latest master-slave database information; and the pre-write request needs to carry the latest Header information. At the same time, based on the logic of whether to allow writing, the access control table of the new master database will be automatically enabled to perform write access control; When MySQL recovers from a failure, the control system database table is accessed based on the unsynchronized data in each standby database, and data is restored from the failed node. Whether writing is allowed is determined as follows: Use the business ID, master database ID information, and request parameters in the Header to query whether the database table of the unsynchronized data access control system is empty: If the query result is not empty, it means that the last write operation of this record in the unsynchronized data access control system database table has not been synchronized to this node, so writing is not allowed this time, and a message indicating that writing is not allowed is returned to the application layer; If the query result is empty, a pre-written version number is generated, and a record is inserted into the unsynchronized data access control system database table according to the business table name, primary key column name, primary key value, business ID in the header, business standby database ID list and pre-written version number in the request message body; then a write-allowed response message is returned to the requester; The content requested by the requester includes Header {user name | login timestamp | primary database ID | backup database ID list | business ID + login token}, business table name, primary key list, primary key value and business callback data; the login token is issued by the unsynchronized data access control system at login; the unsynchronized data access control system verifies whether the token is legal based on the information in the Header: if it is not legal, the request is ignored; the business callback data requested by the requester is filled in by the requester to uniquely identify the request, so as to trigger the corresponding logic after the return; The content of the requester's response includes whether writing is allowed, the pre-written version number, and the business callback data; the pre-written version number of the requester's response is generated by the unsynchronized data access control system and is used to identify the write version of the business data; the business callback data of the requester's response is used for the transparent transmission field and is filled in by the requester; The node deployment of the unsynchronized data access control system is as follows: The unsynchronized data access control system adopts active-standby multi-node deployment, where the active-standby multi-nodes are connected to the same database. Under normal circumstances, only the active node provides services. When the primary node fails, the primary node is blocked, and the standby node is upgraded to the primary node. After pulling the full unsynchronized list from the database to the cache, it starts to provide services. When a database node fails, the write operation is downgraded to write-ahead log plus write cache. After the database node recovers, the full cache is flushed to the database node.

2. An application layer fault-tolerant system in MySQL master-slave mode, characterized in that: The system is used to implement the application layer fault tolerance method in the MySQL master-slave mode as claimed in claim 1; the system includes: Deployment module 1, used to deploy the application layer database; Deployment module 2, used to deploy the unsynchronized data access control system database table; Login module, used for application layer to log in to the unsynchronized data access control system; The writing module is used to write business tables at the application layer.

3. An electronic device, characterized in that: include: memory and at least one processor; Wherein, the memory stores a computer program; The at least one processor executes the computer program stored in the memory, so that the at least one processor executes the application layer fault tolerance method in the MySQL master-slave mode as claimed in claim 1.

4. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which can be executed by a processor to implement the application layer fault tolerance method in the MySQL master-slave mode as claimed in claim 1.

Images