Data management method and device of MHA high-availability architecture, medium and computing device

Abstract

This invention provides a data management method, apparatus, medium, and computing device for MHA high availability architecture. The method includes identifying the master database and each slave database in the MHA high availability architecture; creating storage disks corresponding to the master and slave databases, wherein the storage disks are disk volumes that can be unmounted and mounted at any time; and storing the binlog logs of the master and slave databases to the corresponding storage disks. This invention achieves master-slave data synchronization by placing the binlogs of the master database and the standby databases during peer failover on external storage disks, which are mounted on the host via volumes, instead of storing them on their respective local disks. This truly achieves zero data loss and confirms the integrity of production data.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a data management method, apparatus, medium, and computing device for MHA high availability architecture. Background Technology

[0002] With the widespread use of the open-source database MySQL, high availability has become increasingly important. To ensure that the data's RPO (Recovery Point Objective) is as low as possible (RPO = 0, the rate of data loss in the event of a disaster), various high availability architectures have emerged in the industry, with MHA being a commonly used one. In native MHA high availability, under normal circumstances, if the MySQL primary database becomes unavailable, during MHA failover, the new primary database automatically performs binlog compensation to ensure data consistency with the primary database.

[0003] However, if the operating system on which the MySQL master database resides crashes, the MHA management node will be unable to log in to the master database's operating system via SSH. If there is a delay between the new master database and the old master database, some data will be lost, leading to inconsistency between the master and slave databases. Summary of the Invention

[0004] In view of the above problems, the present invention proposes a data management method, apparatus, medium and computing device for MHA high availability architecture that overcomes or at least partially solves the above problems.

[0005] According to one aspect of the present invention, a data management method for an MHA high-availability architecture is provided, the method comprising:

[0006] Identify the master and slave databases in the MHA high-availability architecture;

[0007] Create storage disks corresponding to the master database and slave database, wherein the storage disks are disk volumes that can be unmounted and mounted at any time;

[0008] The binlog logs of the master database and slave database are stored to their respective storage disks.

[0009] Optionally, creating the storage disks corresponding to the master and slave databases includes:

[0010] Mount a first storage disk with the same path on each instance of the master database and the slave database;

[0011] A second storage disk is mounted on each instance of the main database.

[0012] Optionally, storing the binlog logs of the master database and the slave database to the corresponding storage disk includes:

[0013] The binlog logs from each instance of the database are stored in the corresponding first storage disk;

[0014] The binlog logs of each instance of the main database are stored in the corresponding first and second storage disks.

[0015] Optionally, binlog server technology can be used to store the binlog logs generated by the main database in the first storage disk to the corresponding first and second storage disks;

[0016] The second storage disk and the binlog logs in the second storage disk have the same number and content.

[0017] Optionally, after storing the binlog logs of the master database and the slave database to their respective storage disks, the method further includes:

[0018] When the MHA monitoring process detects that the primary database has crashed and cannot be logged into via SSH, it determines the backup primary database that was pre-selected from the database and mounts the second storage disk to the backup primary database.

[0019] The first data file of the backup master database is obtained based on the first storage disk, and the second data file of the master database is obtained based on the second storage disk;

[0020] The first data file and the second data file are compared to generate a difference data file, which is then applied to the backup master database.

[0021] Optionally, mounting the second storage disk to the standby primary database includes: mounting the second storage disk to the standby primary database using the operating system's mount command.

[0022] Optionally, after applying the difference data file to the standby master database, the method further includes:

[0023] Select a new standby master database from the database and start the master-slave replication process.

[0024] According to another aspect of the present invention, a data management device for an MHA high-availability architecture is provided, characterized in that the device comprises:

[0025] The database identification module is used to identify the master database and each slave database in the MHA high availability architecture;

[0026] The storage disk creation module is used to create storage disks corresponding to the master database and the slave database. The storage disks are disk volumes that can be unmounted and mounted at any time.

[0027] The data storage module is used to store the binlog logs of the master database and the slave database to the corresponding storage disks.

[0028] Optionally, the storage disk creation module is also used to mount a first storage disk with the same path on each instance of the master database and the slave database;

[0029] A second storage disk is mounted on each instance of the main database.

[0030] Optionally, the data storage module is further configured to: store the binlog logs of each instance of the database into the corresponding first storage disk;

[0031] The binlog logs of each instance of the main database are stored in the corresponding first and second storage disks.

[0032] Optionally, the data storage module 430 is used to store the binlog logs generated by the main database in the first storage disk to the corresponding first storage disk and second storage disk using binlog server technology;

[0033] The second storage disk and the binlog logs in the second storage disk have the same number and content.

[0034] Optionally, the data management device of the MHA high availability architecture of the present invention may further include a failover module, used to: when the primary database is found to be down and unable to log in via SSH through the MHA monitoring process, determine the backup primary database pre-selected from the database, and mount the second storage disk to the backup primary database;

[0035] The first data file of the backup master database is obtained based on the first storage disk, and the second data file of the master database is obtained based on the second storage disk;

[0036] The first data file and the second data file are compared to generate a difference data file, which is then applied to the backup master database.

[0037] Optionally, the failover module is also used to: mount the second storage disk to the standby primary database using the operating system's mount command.

[0038] Optionally, the failover module is also used to: select a new standby master database from the slave database and start the master-slave replication process.

[0039] According to another aspect of the present invention, a computer-readable storage medium is also provided for storing program code for executing the data management method of the MHA high availability architecture described in any of the preceding claims.

[0040] According to another aspect of the present invention, a computing device is also provided, the computing device comprising a processor and a memory:

[0041] The memory is used to store program code and transmit the program code to the processor;

[0042] The processor is used to execute the data management method of the MHA high availability architecture described above according to the instructions in the program code.

[0043] This invention provides a data management method, apparatus, medium, and computing device for MHA high availability architecture. The data management method of this invention performs secondary development and architecture upgrade on the native MHA high availability architecture. It places the binlogs of the primary database and the standby database during peer failover on an external storage disk, mounted to the host via a volume, instead of storing them on their respective local disks, thus achieving master-slave data synchronization. Even in the event of a server crash, no data will be lost, truly achieving zero data loss, confirming the integrity of production data, and protecting users' data assets.

[0044] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below.

[0045] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0046] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0047] Figure 1 A schematic diagram of the data management method for MHA high availability architecture according to an embodiment of the present invention is shown;

[0048] Figure 2 A schematic diagram of an MHA high availability architecture upgrade according to an embodiment of the present invention is shown;

[0049] Figure 3 A schematic diagram of the database failover process according to an embodiment of the present invention is shown;

[0050] Figure 4 A schematic diagram of a data management device structure according to an embodiment of the MHA high availability architecture is shown.

[0051] Figure 5 A schematic diagram of the data management device structure of the MHA high availability architecture according to another embodiment of the present invention is shown. Detailed Implementation

[0052] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0053] This invention provides a data management method for MHA high-availability architecture, such as... Figure 1 As shown, the data management method for the MHA high availability architecture provided in this embodiment of the invention may include at least the following steps S101 to S103.

[0054] S101 identifies the master database and slave databases in the MHA high availability architecture.

[0055] MHA (Master High Availability) is a mature and open-source MySQL high-availability program. It enables automatic single-pass failover in a MySQL master-slave environment when the master node fails. Written in Perl, it is easy to install and use. MHA consists of two parts: MHA Manager (management node) and MHA Nodes (data nodes). The MHA Manager can be deployed on a separate machine to manage multiple master-slave clusters, or it can be deployed on a single slave node. The MHA Manager primarily runs tools such as `masterha_manager` for automatic monitoring of the MySQL master and master failover, and other tools for manual master failover, online master migration, connection checks, etc. MHA Nodes...

[0056] MHA Nodes (data nodes) run on each MySQL server. MHA Manager periodically probes the master node in the cluster. When the master fails, it can automatically promote the slave with the latest data to the new master, and then redirect all other slaves to the new master. The entire failover process is completely transparent to the application.

[0057] The MHA high-availability architecture uses a master-slave configuration, with one master node acting as the primary database and two slave nodes acting as secondary databases to enable proactive data synchronization. For example... Figure 2 As shown, in this embodiment, database A is the primary database, databases B and C are secondary databases, and database B is the backup primary database.

[0058] S102, create storage disks corresponding to the master database and slave database, wherein the storage disks are disk volumes that can be unmounted and mounted at any time.

[0059] In this embodiment, the storage disk is a disk volume that can be unmounted and mounted at any time. Specifically, this is achieved by optimizing and modifying the MHA tool source code to automatically unmount and mount the disk volume, followed by logging. Mounting is the process of accessing a directory on the root file system from outside the root file system; the process of releasing this association is called unmounting. In this embodiment, the traditional MHA high-availability architecture can be implemented by modifying and adjusting the source code when creating the mounted disk.

[0060] S103, store the binlog logs of the master and slave databases to their respective storage disks. The binlog log, or binary log, records all operations performed on the MySQL database in event format. After creating the mounted storage disks for the master and slave databases, the binlog logs generated by the master and slave databases can be stored in the mounted storage disks created in step S102 above, thus saving data while achieving master-slave synchronization.

[0061] The data management method for the MHA high availability architecture provided in this embodiment is a secondary development and upgrade of the native MHA high availability architecture. It places the binlogs of the primary database and the standby database during peer failover on an external storage disk, mounted to the host via a volume, instead of storing them on their respective local disks, thus achieving master-slave data synchronization. Even in the event of a server crash, no data will be lost, truly achieving zero data loss, confirming the integrity of production data, and protecting users' data assets.

[0062] As mentioned in step S102 above, storage disks corresponding to the master database and slave database need to be created. In some embodiments, two storage disks can be created: in this embodiment, they are denoted as the first storage disk D1 and the second storage disk D2. That is, when creating storage disks that can be mounted and unmounted at any time, firstly, a first storage disk with the same path is mounted on each instance of the master database and slave database. Secondly, a second storage disk is mounted on each instance of the master database.

[0063] Furthermore, step S103 above, which involves storing the binlog logs of the master database and the slave database to the corresponding storage disks, may include: storing the binlog logs of each instance of the slave database to the corresponding first storage disk; and storing the binlog logs of each instance of the master database to the corresponding first storage disk (D1 disk) and second storage disk (D2 disk).

[0064] In other words, whether it is the master database or the slave database, a storage disk with the same path is mounted on each instance of MySQL. In this embodiment, it is referred to as the first storage disk D1. In addition, an extra storage disk needs to be mounted on the master database. In this embodiment, it is named the second storage disk D2. (1) The detailed disk information is as follows:

[0065] ① Disk information for primary database A: / mybinlog is the mount point for disk D1, which stores the binlog logs of the primary database; / mybinlog_mha is the mount point for disk D2, which acts as the binlog server, and its content is the same as the binlog logs of the primary database.

[0066] #df-Th

[0067] / dev / mapper / vgadg-lv_vgadg ext4 123G 33G 84G 29% / mybinlog

[0068] / dev / mapper / vgpri-lv_vgpri ext4 123G 25G 92G 22% / mybinlog_mha

[0069] ② Disk information for backup database B: / mybinlog is the mount point for disk D1.

[0070] #df-Th

[0071] / dev / mapper / vgpri-lv_vgpri ext4 123G 31G 87G 26% / mybinlog

[0072] In some embodiments, binlog server technology is used to store the binlog logs generated by the main database in the first storage disk to the corresponding first storage disk and second storage disk; the number and content of binlog logs in the second storage disk and the second storage disk are the same.

[0073] In this embodiment, the binlog of each MySQL instance is stored on disk D1. Furthermore, using binlog server technology, an additional copy of the binlog generated by the primary database A is placed on disk D2, ensuring that the number and content of binlog logs on disks D1 and D2 of the primary database A are exactly the same. This way, when the primary database A crashes and disk D2 is mounted to the new primary database B, the new primary database B can access the binlog of the original primary database A and perform further operations.

[0074] Binlog server technology is a method of binlog replication. Master-slave replication often experiences delays due to various factors. When the master fails and SSH is unavailable, the slave database may lose some data and fail to synchronize. In this case, a separate server is set up as a binlog server to pull binlog logs from the master database in real time, so that other slave databases can recover data from the binlog server if the master fails.

[0075] MySQL Binlog Server uses the `mysqlbinlog` command as a daemon process to simulate a slave's IO thread connecting to the master database. This allows for convenient and real-time synchronization of the master's binlog, mitigating the risk of data loss during the interval between the most recent backup and the next backup in scheduled backup strategies. In this embodiment, binlog server technology is used to connect to the first storage disk D1, enabling real-time retrieval of the master database's binlog logs from D1 and storage on disk D2.

[0076] In practical applications, the master data may fail over due to system downtime. Therefore, in some embodiments, the above step S103 may include a failover process, the specific implementation steps of which are as follows:

[0077] The first step, when the MHA monitoring process detects that the primary database has crashed and SSH login is unavailable, identifies the pre-selected backup primary database from the databases and mounts the second storage disk onto the backup primary database. Mounting the second storage disk onto the backup primary database includes using the operating system's mount command to mount the second storage disk onto the backup primary database.

[0078] In other words, when the primary database A experiences a system-level crash, and the MHA monitor process detects that the primary database A is dead and cannot be logged into via SSH, it will directly mount the D2 disk to the new primary database B.

[0079] The second step is to obtain the first data file of the backup master database based on the first storage disk, and to obtain the second data file of the master database based on the second storage disk.

[0080] The third step is to compare the first data file and the second data file, generate a difference data file, and apply the difference data file to the backup master database.

[0081] In this embodiment, the binlog in disk D2 is compared with the binlog in disk D1 of database B. The differences between database A and database B are used to generate a corresponding difference file, which is then applied to the new primary database B. This ensures that after the original primary database A fails, any extra data is synchronized to database B, guaranteeing data consistency between database A and database B. Figure 3 As shown, the detailed steps of the database failover process in this embodiment are as follows.

[0082] The MHA monitor process is a persistent background process that runs on the MHA manager management node; the process is as follows:

[0083] #Monitoring process

[0084] $ps axu|grep mbsp00

[0085] root 13345 0.0 0.0 197260 19672? SJul14 65:33 perl / usr / bin / masterha_manager--global_conf= / paic / mysql / mha / masterha_default.conf--conf= / paic / mysql / mha / mbsp00_ 3308 / app1.conf--ignore_fail_on_start--ignore_last_failover--wait_on_monitor_error=60--wait_on_failover_error=60

[0086] ② The identification logic of the monitoring process depends on the setting of ping_type in the mha configuration file app1.conf. In production, ping_type = connect is used. That is, every time the database is logged in and select 1 as Value is executed to detect whether the database is alive, the connection must be recreated each time. If the connection cannot be created successfully after 4 attempts (or other set number of attempts), the monitoring process considers the database to be down and unable to provide services, and then triggers failover.

[0087] ③ When the primary database A fails, the D2 disk will be directly mounted to the new primary database B. The mounting command and method, as shown in the code snippet, mainly involve calling the function stop_umount_mha(). After the primary database fails, the / mybinlog_mha disk will be mounted to the new primary database using the operating system's mount command.

[0088] ④ After mounting disk D2 of the original primary database A to the new primary database B, use the `show slave status` command to check if the values ​​of `Master_Log_File&&Read_Master_Log_Pos` and `Relay_Master_Log_File&&Exec_Master_Log_Pos` are consistent. If they are consistent, there is no delay, and the standby database does not need to compensate for binlog; a direct switchover is possible. If they are inconsistent, there is a delay in standby database B. By comparing the differences between the parameters `Master_Log_File&&Read_Master_Log_Pos` and `Relay_Master_Log_File&&Exec_Master_Log_Pos`, identify the binlog differences that database B has not yet applied. Finally, use the `mysqlbinlog` command to import these differences into the new primary database B, compensating for the log differences between the new standby database and the primary database.

[0089] Step 4: Select a new standby master database from the slave database and start the master-slave replication process.

[0090] In this embodiment, the original slave database B is set as the standby master database. When the original master database A crashes, database B can be used as the new master database. At the same time, database C can be used as the standby master-master database of the new master database. Database C is attached to database B. After the master-standby replication process is started, the binlog logs of B will be used to complete the master-slave synchronization task of other standby databases.

[0091] The step of attaching database C to database B is achieved using the native MySQL command `change master to`. You specify the IP address and port of the new master B, and then copy the user's username and password. For example, `change master to master_host='21.64.153.188', master_port=3308, master_user='dbsync', master_password='SfCd5nwGJ5f9xzrvE6wR', master_auto_position=1`.

[0092] Start slave;

[0093] After database B becomes the new primary database, in addition to mounting the original first storage disk D1, a second storage disk D2 can also be mounted on database B. Similarly, binlog server technology can be used to synchronize the binlog logs of database B stored in disk D1 to disk D2, thereby realizing the data synchronization of binlog logs in the new primary database and thus achieving a new round of data backup.

[0094] In practical applications, master-slave replication is often subject to some delays due to various factors. The method provided in this embodiment, through a simple adjustment to the MHA architecture, allows the standby database to compensate for logs through the binlog of the master database in the shared storage disk even when the master database fails and cannot be SSH'd, ensuring that the data is consistent with the original master database. This solves the pain points of master-slave delay switching and data loss caused by the inability to log in via SSH when the master database crashes, making it more targeted.

[0095] Based on the same inventive concept, embodiments of the present invention also provide a data management device for an MHA high-availability architecture, such as... Figure 4 As shown, the data management device for the MHA high availability architecture provided in this embodiment of the invention may include: a database identification module 410, a storage disk creation module 420, and a data storage module 430, wherein the functions of each module are as follows:

[0096] Database identification module 410 is used to identify the master database and each slave database in the MHA high availability architecture;

[0097] The storage disk creation module 420 is used to create storage disks corresponding to the master database and the slave database. The storage disks are disk volumes that can be unmounted and mounted at any time.

[0098] The data storage module 430 is used to store the binlog logs of the master database and the slave database to the corresponding storage disks.

[0099] In some embodiments, the storage disk creation module 420 can also be used to mount a first storage disk with the same path on each instance of the master database and the slave database.

[0100] A second storage disk is mounted on each instance of the main database.

[0101] In some embodiments, the data storage module 430 may also be used to: store the binlog logs from each instance of the database into the corresponding first storage disk;

[0102] The binlog logs of each instance of the main database are stored in the corresponding first and second storage disks.

[0103] In some embodiments, the data storage module 430 can also be used to store the binlog logs generated by the main database in the first storage disk to the corresponding first and second storage disks using binlog server technology.

[0104] The second storage disk and the binlog logs in the second storage disk have the same number and content.

[0105] In some embodiments, such as Figure 5 As shown, the data management device of the MHA high availability architecture in this embodiment of the invention may further include a failover module 440.

[0106] The failover module 440 is used to: when the MHA monitoring process detects that the primary database has crashed and cannot be logged in via SSH, determine the backup primary database pre-selected from the database, and mount the second storage disk to the backup primary database;

[0107] The first data file of the backup master database is obtained based on the first storage disk, and the second data file of the master database is obtained based on the second storage disk;

[0108] The first data file and the second data file are compared to generate a difference data file, which is then applied to the backup master database.

[0109] In some embodiments, the failover module 440 can also be used to mount the second storage disk to the standby master database via the operating system mount command.

[0110] In some embodiments, the failover module 440 can also be used to: select a new standby master database from the slave database and start the master-slave replication process.

[0111] An embodiment of the present invention also provides a computer-readable storage medium for storing program code for executing the data management method of the MHA high availability architecture described in the above embodiment.

[0112] An embodiment of the present invention also provides a computing device, the computing device including a processor and a memory: the memory is used to store program code and transmit the program code to the processor; the processor is used to execute the data management method of the MHA high availability architecture described in the above embodiment according to the instructions in the program code.

[0113] Those skilled in the art will clearly understand that the specific working process of the systems, devices, modules and units described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.

[0114] Furthermore, the functional units in the various embodiments of the present invention can be physically independent of each other, or two or more functional units can be integrated together, or all functional units can be integrated into one processing unit. The integrated functional units described above can be implemented in hardware, or in software or firmware.

[0115] Those skilled in the art will understand that if the integrated functional unit is implemented in software 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 invention, or all or part of it, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computing device (e.g., a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of the present invention when running the instructions. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0116] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as a computing device, personal computer, server, or network device) related to program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the computing device, the computing device executes all or part of the steps of the methods described in the various embodiments of the present invention.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of the present invention, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to depart from the protection scope of the present invention.

Claims

1. A data management method for an MHA high-availability architecture, characterized in that, The method includes: Identify the master and slave databases in the MHA high-availability architecture; Create storage disks corresponding to the master database and slave database, wherein the storage disks are disk volumes that can be unmounted and mounted at any time; wherein, a first storage disk with the same path is mounted on each instance of the master database and slave database; and a second storage disk is mounted on each instance of the master database. The binlog logs of each instance of the primary database are stored in the corresponding first storage disk; the binlog logs of each instance of the primary database are stored in the corresponding first storage disk and second storage disk. When the MHA monitoring process detects that the primary database has crashed and cannot be logged into via SSH, it determines the pre-selected backup primary database from the database and mounts the second storage disk onto the backup primary database; it obtains the first data file of the backup primary database based on the first storage disk and the second data file of the primary database based on the second storage disk; it compares the first data file and the second data file to generate a difference data file and applies the difference data file to the backup primary database.

2. The method according to claim 1, characterized in that, Use binlog server technology to store the binlog logs generated by the main database in the first storage disk to the corresponding first and second storage disks; The second storage disk and the binlog logs in the second storage disk have the same number and content.

3. The method according to claim 1, characterized in that, Mounting the second storage disk to the standby primary database includes: mounting the second storage disk to the standby primary database using the operating system's mount command.

4. The method according to claim 1, characterized in that, After applying the difference data file to the standby master database, the method further includes: Select a new standby master database from the database and start the master-slave replication process.

5. A data management device for an MHA high-availability architecture, characterized in that, The device includes: The database identification module is used to identify the master database and each slave database in the MHA high availability architecture; The storage disk creation module is used to create storage disks corresponding to the master database and the slave database. The storage disks are disk volumes that can be unmounted and mounted at any time. Specifically, a first storage disk with the same path is mounted on each instance of the master database and the slave database. A second storage disk is mounted on each instance of the master database. The data storage module is used to store the binlog logs of each instance of the slave database to the corresponding first storage disk; and to store the binlog logs of each instance of the master database to the corresponding first storage disk and second storage disk. When the MHA monitoring process detects that the primary database has crashed and cannot be logged into via SSH, it determines the pre-selected backup primary database from the database and mounts the second storage disk onto the backup primary database; it obtains the first data file of the backup primary database based on the first storage disk and the second data file of the primary database based on the second storage disk; it compares the first data file and the second data file to generate a difference data file and applies the difference data file to the backup primary database.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for executing the data management method of the MHA high availability architecture according to any one of claims 1-4.

7. A computing device, characterized in that, The computing device includes a processor and memory: The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the data management method of the MHA high availability architecture according to any one of the instructions in the program code.

Images