MHA_MySQL for MySQL high availability kill

MHA bitsCN.com for MySQL high availability kill

Many people think of MySQL Cluster or Heartbeat + DRBD when it comes to the high availability of MySQL. However, the complexity of these solutions is often daunting, using MySQL replication to achieve high availability is much easier. Currently, there are roughly MMM, PRM, MHA and other solutions available: MMM is the most common solution, unfortunately, it often brings more problems than solved (What's wrong with MMM ?); As for PRM, it is still a new project and is not recommended for use in the product environment for the time being. but as a work of Percona, it is worth looking forward to. in this case, only MHA can be selected currently, fortunately, it has been proved to be a reliable tool by DeNA's large-scale practical application.

Installation:

As a prerequisite, you should first configure MySQL replication and set the SSH public key to password-free login. The following uses CentOS as an example to describe how to install EPEL first. otherwise, some software packages may not be found in YUM.

MHA is composed of nodes and managers. the Node runs on each MySQL server. that is to say, whether it is a MySQL master server or a MySQL slave server, Node must be installed, the Manager usually runs on an independent server. However, if the hardware resources are tight, you can use a MySQL slave server to work as a part-time Manager.

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: for details about the parameters in the MHA configuration file, refer to the official documentation.

Check

Check MySQL replication:

Shell> masterha_check_repl -- conf =/etc/masterha_application.cnf

Check SSH public key password-free logon:

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 information such as read_only and relay_log_purge may be prompted.

Then check the MHA status:

Shell> masterha_check_status -- conf =/etc/masterha_application.cnf

Note: If it is normal, "PING_ OK" is displayed; otherwise, "NOT_RUNNING" is displayed 』.

So far, a basic MHA example can run normally, but once the current MySQL master server fails, MHA upgraded a MySQL slave server to a new MySQL master server, how to notify the application? The following two parameters must be added to the configuration file:

Master_ip_failover_script

Master_ip_online_change_script

When it comes to Failover, there are usually two methods: Virtual IP addresses and global configuration files. MHA does not limit which method to use, but allows users to choose it. the virtual IP address method involves other software. I will not go into details here. The following is a brief introduction to the global configuration file, use PHP as the implementation language. the code is as follows:

#! /Usr/bin/env php

　　

$ Longopts = array (

'Command :',

'Ssh _ user :',

'Orig _ master_host :',

'Orig _ master_ip :',

'Orig _ master_port :',

'New _ master_host ::',

'New _ master_ip ::',

'New _ master_port ::',

);

$ Options = getopt (null, $ longopts );

If ($ options ['command'] = 'start '){

$ Params = array (

'IP' => $ options ['new _ master_ip '],

'Port' => $ options ['new _ master_port '],

);

$ String = '';

File_put_contents ('config. php', $ string, LOCK_EX );

}

Exit (0 );

?>

Note: it is OK to implement this script in other languages. do not forget to add the executable attribute to the script.

To test the effect, kill the current MySQL master server. wait a moment, MHA will upgrade a MySQL slave server to a new MySQL master server and call the master_ip_failover_script script, as shown above, in the master_ip_failover_script, the ip address and port information of the new MySQL master server can be persistently stored in the configuration file, so that the application can use the new configuration.

You can use the masterha_master_switch command to manually switch to the MySQL master server. However, it does not call the master_ip_failover_script script, but the master_ip_online_change_script script. However, similar parameters are called, and scripts can be used with each other.

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 for executing commands vary depending on whether the original MySQL master server is down.

It should be noted that if MHA detects that the MySQL master server is down continuously and the interval between the two crashes is less than eight hours, no Failover will be performed, the reason for this restriction is to avoid the ping-pong effect. However, for automation, we often want to remove this restriction. in this case, you can start the Manager as follows:

Shell> nohup masterha_manager -- conf =/etc/masterha_application.cnf -- ignore_last_failover -- remove_dead_master_conf &

Note: ensure that the Manager running user has write permission on masterha_application.cnf.

...

This article is just a brief introduction to MHA. for details, we recommend that you read the official documentation.

BitsCN.com