Table of contents
background
Before introducing the MHA data supplement function, let’s introduce some basic knowledge about MHA.
MHA (Master High Availability) is a tool set used to achieve high availability (High Availability) of MySQL database.
It can implement failover and master database switching in the master-slave replication architecture to ensure the stable operation of database services.
MHA consists of two main components:
- MHA Manager: Responsible for monitoring the MySQL master-slave replication status, detecting failures and performing failover. It is usually deployed on a separate management server.
- MHA Node: Deployed on each MySQL server to assist MHA Manager in completing failover operations, such as log parsing, differential data transmission, etc.
The main functions of MHA are as follows:
-
Automatic failover : When the master database fails, MHA can automatically promote one of the slave databases to the new master database and redirect the other slave databases to the new master database to achieve fast failover.
-
Online master database switching : Without interrupting service, MHA can switch the current master database to another slave database for database maintenance, upgrades and other operations.
-
Replication delay detection : MHA can monitor the delay of master-slave replication to ensure the accuracy of data synchronization.
-
Automatically repair replication : When problems occur when replicating from the database, MHA can automatically fix replication errors and restore normal data synchronization.
-
Flexible configuration and expansion : MHA supports a variety of configuration options and can be customized according to actual needs. At the same time, MHA has good scalability and can easily cope with the management needs of large database clusters.
Through these functions, MHA can improve the high availability of MySQL database and ensure the stable operation of the business system.
MHA data supplement function
When the master server fails and a failover is required, MHA ensures that the slave server has the latest data. The specific operations are as follows:
- MHA Manager will analyze the binary log (Binary Log) of the failed master server to find the data that may be missing from the slave server.
- MHA Manager will apply these missing data to the slave server to ensure that the slave server has the latest data.
- After the data is completed, MHA Manager promotes one of the slave servers to the new master server and reconfigures the other slave servers to get updates from the new master server.
The following are the specific steps for supplementing data:
-
Detect master server failure : MHA Manager monitors the master-slave replication status and starts the failover process when it detects that the master server has failed.
-
Analyze the binary log : MHA Manager analyzes the binary log (Binary Log) of the failed master server to find data that may be missing from the slave server. If the failed master server is unreachable, MHA Manager attempts to obtain binary logs from other slave servers that have not yet been applied. This process is implemented using the mysqlbinlog tool.
-
Apply missing data : MHA Manager applies the missing data found to the slave server to ensure that the slave server has the latest data. This process may involve multiple slave servers, and MHA Manager will ensure data consistency among all slave servers. MHA uses the mysql command to apply the SQL statements in the binary log to the new master server.
-
Promote the new master server : After the data is completed, MHA Manager will select one of the slave servers to promote as the new master server. Usually choose the slave server with the smallest replication delay.
-
Reconfigure slave servers : MHA Manager will reconfigure other slave servers so that they get updates from the new master server. In this way, the master-slave replication relationship is restored.
Through this data filling process, MHA can ensure data consistency during failover and improve database availability.
Additional notes on supplementary data
The data complement process is essentially the same between different versions of MHA, but there may be some differences in details and functionality. Since there are many versions, here is an overview of some major version changes:
-
MHA 0.50 : This release introduces support for MySQL 5.6, including global transaction ID (GTID) support. This allows the data complement process to better handle master-slave replication in GTID mode.
-
MHA 0.56 : This version adds support for MySQL 5.7, including support for the new JSON data type and virtual columns. In addition, the slave server selection algorithm has been optimized to improve the efficiency of the data supplement process.
-
MHA 0.57 : This version fixes some problems that may be encountered during the data filling process, such as errors encountered when applying binary logs. Additionally, support for MariaDB 10.2 has been added.
-
MHA 0.58 : This version mainly carries out code optimization and bug fixes, and improves the stability of the data filling process.
It should be noted that the core idea of the data supplement process is the same between various versions of MHA. The main differences lie in support for new functions, performance optimization and bug fixes. In order to ensure the best data supplementation effect, it is recommended to use the latest version of MHA. At the same time, pay attention to MHA's official GitHub repository to learn about the latest version updates and functional changes.