Shulou(Shulou.com)05/31 Report--

This article shows you how to use MHA in MySQL. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

When it comes to MySQL high availability, many people will think of, or +, but the complexity of these solutions is often daunting. In contrast, it is much easier to use MySQL replication to achieve high availability. At present, there are general options to choose from: MMM is the most common solution, but it has too many problems. As for PRM, it is still a new project and is not recommended for the production environment, but as a work, it is worth looking forward to; so it seems that we can only choose MHA for now, fortunately, it has been proved to be a reliable tool after large-scale practical application.

Installation:

As a prerequisite, you should first configure MySQL replication and set SSH public key password-free login. Take CentOS as an example, it is best to install EPEL first, otherwise YUM may not be able to find some software packages.

MHA consists of Node and Manager, and Node runs on every MySQL server, that is, whether it is a MySQL master server or a MySQL slave server, you have to install Node, while Manager usually runs on a separate server, but if hardware resources are tight, you can also use a MySQL slave server to take part-time Manager role.

Install Node:

Shell > yum install perl-DBD-MySQL

Shell > rpm-Uvh http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52-0.noarch.rpm install Manager:

Shell > yum install perl-DBD-MySQL

Shell > yum install perl-Config-Tiny

Shell > yum install perl-Log-Dispatch

Shell > yum install perl-Parallel-ForkManager

Shell > rpm-Uvh http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52-0.noarch.rpm

Shell > rpm-Uvh http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52-0.noarch.rpm configuration:

Configure global settings:

Shell > cat / etc/masterha_default.cnf

[server default]

User=...

Password=...

Ssh_user=... Configure application settings:

Shell > cat / etc/masterha_application.cnf

[server_1]

Hostname=...

[server_2]

Hostname=... Note: please refer to the official documentation for a detailed description of the parameters in the MHA configuration file.

Check

Check MySQL replication:

Shell > masterha_check_repl-- conf=/etc/masterha_application.cnf check SSH public key password-free login:

Shell > masterha_check_ssh-- conf=/etc/masterha_application.cnf practice

Start the MHA process first:

Shell > masterha_manager-- conf=/etc/masterha_application.cnf Note: depending on the configuration, warning messages such as read_only,relay_log_purge may be prompted.

Then check the MHA status:

Shell > masterha_check_status-- conf=/etc/masterha_application.cnf Note: if normal, "PING_OK" will be displayed, otherwise "NOT_RUNNING" will be displayed.

So far, a basic MHA example will work, but if the current MySQL master server fails and MHA promotes a MySQL server from a server to a new MySQL master server, how do you notify the application? This requires the following two parameters to be added to the configuration file:

Master_ip_failover_script

Master_ip_online_change_script

When it comes to Failover, there are usually two ways: one is the virtual IP address, the other is the global configuration file. MHA does not limit which method to use, but allows users to choose. The method of virtual IP address will involve other software. I will not repeat it here. Let's briefly talk about the global configuration file, which is implemented in PHP with the code as follows:

#! / usr/bin/env

Note: OK is also used to implement this script in other languages, so don't forget to add executable attributes to the script.

If you want to test the effect, you can kill the current MySQL master server. In a moment, MHA will promote some MySQL server from the server to the new MySQL master server and call the master_ip_failover_script script. As shown above, we can persist the ip and port information of the new MySQL master server into the configuration file in the master_ip_failover_script script, so that the application can use the new configuration.

Sometimes you need to switch the MySQL master server manually, you can use the masterha_master_switch command, but it calls not a master_ip_failover_script script, but a master_ip_online_change_script script, but the call parameters are similar, and the scripts can be used interchangeably.

Shell > masterha_master_switch-conf=/etc/masterha_application.cnf-master_state=dead-dead_master_host=...

Shell > masterha_master_switch-conf=/etc/masterha_application.cnf-master_state=alive-new_master_host=... Note: the parameters required to execute the command vary depending on whether the original MySQL master server has been down.

It is important to note that by default, if MHA detects continuous downtime and the interval between two outages is less than eight hours, Failover will not occur, and this restriction is to avoid the ping-pong effect. However, in order to automate, we often want to remove this restriction, and we can start Manager in the following ways:

Shell > nohup masterha_manager-- conf=/etc/masterha_application.cnf-- ignore_last_failover-- remove_dead_master_conf & Note: make sure that the user running Manager has write permission to masterha_application.cnf.

The above is how to use MHA in MySQL. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.