Overview MHA能够在较短的时间内实现自动故障检测和故障转移，通常在10-30秒以内;在复制框架中，MHA能够很好地解决复制过程中的数据一致性问题，由于不需要在现有的replication中添加额外的服务器，仅需要一个manager节点，而一个Manager能管理多套复制，所

Overview

◎自动故障检测和自动故障转移

◎交互式（手动）故障转移

◎非交互式的故障转移

◎在线切换Master到不同的主机

Architecture of MHA

MHA Components

Manaer模块：可以管理多套Master-Slave Replication

Node模块：部署在所有的MySQL Server上

Advantages of MHA

Typical Use cases

怎么部署Manager节点

◎设置一个专门的Manager Server和多个Replication环境

◎Manager节点和一个salve节点复用

复制配置（这一部分简略翻译）

Singlemaster, multiple slaves

Singlemaster, multiple slaves (one on remote datacenter)

Singlemaster, multiple slaves, one candidate master

Multiplemasters, multiple slaves

Threetier replication

管理MasterIP地址

和MySQL半同步复制配合使用

Tutorial

创建通用的复制环境

在host1-host4上安装node节点

RHEL/Centos系统

 ## If you have not installed DBD::mysql, install it like below, or install from source.
  # yum install perl-DBD-MySQL

  ## Get MHA Node rpm package from "Downloads" section.
  # rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm

Ubuntu/Debian系统

## If you have not installed DBD::mysql, install it like below, or install from source.
  # apt-get install libdbd-mysql-perl

  ## Get MHA Node deb package from "Downloads" section.
  # dpkg -i mha4mysql-node_X.Y_all.deb

源码安装

  ## Install DBD::mysql if not installed
  $ tar -zxf mha4mysql-node-X.Y.tar.gz
  $ perl Makefile.PL
  $ make
  $ sudo make install

在host4上安装manager节点

RHEL/Centos系统

## Install dependent Perl modules
  # yum install perl-DBD-MySQL
  # yum install perl-Config-Tiny
  # yum install perl-Log-Dispatch
  # yum install perl-Parallel-ForkManager

  ## Install MHA Node, since MHA Manager uses some modules provided by MHA Node.
  # rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm

  ## Finally you can install MHA Manager
  # rpm -ivh mha4mysql-manager-X.Y-0.noarch.rpm

Ubuntu/Debian系统

  ## Install dependent Perl modules
  # apt-get install libdbd-mysql-perl
  # apt-get install libconfig-tiny-perl
  # apt-get install liblog-dispatch-perl
  # apt-get install libparallel-forkmanager-perl

  ## Install MHA Node, since MHA Manager uses some modules provided by MHA Node.
  # dpkg -i mha4mysql-node_X.Y_all.deb

  ## Finally you can install MHA Manager
  # dpkg -i mha4mysql-manager_X.Y_all.deb

源码安装

  ## Install dependent Perl modules
  # MHA Node (See above)
  # Config::Tiny
  ## perl -MCPAN -e "install Config::Tiny"
  # Log::Dispatch
  ## perl -MCPAN -e "install Log::Dispatch"
  # Parallel::ForkManager 
  ## perl -MCPAN -e "install Parallel::ForkManager"
  ## Installing MHA Manager
  $ tar -zxf mha4mysql-manager-X.Y.tar.gz
  $ perl Makefile.PL
  $ make
  $ sudo make install

创建配置文件

下一步就是创建manager的配置文件，参数主要包括mysql server的用户名，密码，复制账户的用户名和密码，工作目录等。所有的参数列表详见parameter表。

manager_host$ cat /etc/app1.cnf
  
  [server default]
  # mysql user and password
  user=root
  password=mysqlpass
  ssh_user=root
  # working directory on the manager
  manager_workdir=/var/log/masterha/app1
  # working directory on MySQL servers
  remote_workdir=/var/log/masterha/app1
  
  [server1]
  hostname=host1
  
  [server2]
  hostname=host2
  
  [server3]
  hostname=host3

注意到host1是当前的master，MHA会自动检测到它。

检查SSH连接

MHA manager通过SSH访问所有的node节点，各个node节点也同样需要通过SSH来相互发送不同的relay log 文件，所以有必要在每一个node和manager上配置SSH无密码登陆。MHAmanager可通过masterha_check_ssh脚本检测SSH连接是否配置正常。

# masterha_check_ssh --conf=/etc/app1.cnf
  
  Sat May 14 14:42:19 2011 - [warn] Global configuration file /etc/masterha_default.cnf not found. Skipping.
  Sat May 14 14:42:19 2011 - [info] Reading application default configurations from /etc/app1.cnf..
  Sat May 14 14:42:19 2011 - [info] Reading server configurations from /etc/app1.cnf..
  Sat May 14 14:42:19 2011 - [info] Starting SSH connection tests..
  Sat May 14 14:42:19 2011 - [debug]  Connecting via SSH from root@host1(192.168.0.1) to root@host2(192.168.0.2)..
  Sat May 14 14:42:20 2011 - [debug]   ok.
  Sat May 14 14:42:20 2011 - [debug]  Connecting via SSH from root@host1(192.168.0.1) to root@host3(192.168.0.3)..
  Sat May 14 14:42:20 2011 - [debug]   ok.
  Sat May 14 14:42:21 2011 - [debug]  Connecting via SSH from root@host2(192.168.0.2) to root@host1(192.168.0.1)..
  Sat May 14 14:42:21 2011 - [debug]   ok.
  Sat May 14 14:42:21 2011 - [debug]  Connecting via SSH from root@host2(192.168.0.2) to root@host3(192.168.0.3)..
  Sat May 14 14:42:21 2011 - [debug]   ok.
  Sat May 14 14:42:22 2011 - [debug]  Connecting via SSH from root@host3(192.168.0.3) to root@host1(192.168.0.1)..
  Sat May 14 14:42:22 2011 - [debug]   ok.
  Sat May 14 14:42:22 2011 - [debug]  Connecting via SSH from root@host3(192.168.0.3) to root@host2(192.168.0.2)..
  Sat May 14 14:42:22 2011 - [debug]   ok.
  Sat May 14 14:42:22 2011 - [info] All SSH connection tests passed successfully.

如果有报错，则表示SSH配置有问题，影响MHA工作。你需要修复它并重试，通常的错误都是SSH public key认证没有正确配置。

检查复制配置

为了让MHA正常工作，所有的master和slave必须在配置文件中正确配置，MHA可通过masterha_check_repl 脚本检测复制是否正确配置。

  manager_host$ masterha_check_repl --conf=/etc/app1.cnf
  ...
  MySQL Replication Health is OK.

如果有报错，可通过查看日志修复它。当前的master一定不能是slave，其他所有的slave必须正确从master中复制。常见的错误可参考 TypicalErrors 页。

开启Manager

当你正确配置了mysql复制，正确安装了manager和node节点，SSH配置也正确，那么下一步就是开启manager，可通过 masterha_manager 命令开启

  manager_host$ masterha_manager --conf=/etc/app1.cnf
  ....
  Sat May 14 15:58:29 2011 - [info] Connecting to the master host1(192.168.0.1:3306) and sleeping until it doesn't respond..

如果所有的配置都正确，masterha_manager会检查mastermaster是否可用直到master崩溃。如果在监控master之前masterha_manager报错，你可以检查下logs并修改配置。所有的日志都会以标准错误的方式打印出来，也可以在manager配置文件中指定错误日志位置。典型的错误有复制配置问题，ssh无访问relay log的权限问题。默认情况下masterha_manager不是运行在后台，按下crtl+c键就会终止masterha_manager。

检查manager状态

当MHA manager启动监控以后，如果没有异常则不会打印任何信息。我们可通过masterha_check_status命令检查manager的状态，以下是范例

manager_host$ masterha_check_status --conf=/etc/app1.cnf
  app1 (pid:5057) is running(0:PING_OK), master:host1

app1是MHA内部的应用名称，该名称可在manager配置文件中指定，如果manager终止或者配置得有错误，将会显示以下信息

  manager_host$ masterha_check_status --conf=/etc/app1.cnf
  app1 is stopped(1:NOT_RUNNING).

终止manager

你可以通过 masterha_stop命令来停止manager

manager_host$ masterha_stop --conf=/etc/app1.cnf
  Stopped app1 successfully.

如果无法停止，尝试加--abort参数，知道了怎么停止，下面我们重新开启manager。

测试master的自动故障转移

  host1$  killall -9 mysqld mysqld_safe

这时候检查manager的log日志，看看host2是否成功成为新的master，并且host3从host2中复制。

当完成一次正常的故障转移后，manager进程将会终止。如果你需要将manager进程运行在后台，可运行如下指令，或者通过安装daemontools来实现(这里略)

manager_host$ nohup masterha_manager --conf=/etc/app1.cnf < /dev/null > /var/log/masterha/app1/app1.log 2>&1 &

Writing an application configuration file

为了MHA正常运行，你需要创建一个配置文件并设置参数，参数主要包括每个mysql进程所在的服务器的用户名和密码，mysql服务的用户名和密码，工作目录等等。整个参数列表设置详细请见Parameters 页。

下面是一个配置文件的设置范例

manager_host$ cat /etc/app1.cnf



[server default]

# mysql user and password

user=root

password=mysqlpass

# working directory on the manager

manager_workdir=/var/log/masterha/app1

# manager log file

manager_log=/var/log/masterha/app1/app1.log

# working directory on MySQL servers

remote_workdir=/var/log/masterha/app1



[server1]

hostname=host1



[server2]

hostname=host2



[server3]

hostname=host3

所有的参数设置必须是"param=value"格式，打个比方，以下设置时错误的。

[server1]

hostname=host1

# incorrect: must be"no_master=1"

no_master

Application-scope参数必须写在[server default]块下，而在 [serverN]块下，你需要设置的是local-scope参数,比如hostname是一个local-scope参数，所以必须写在这个块下面。块名称必须是字母”server”开头。

Writing a global configuration file

如果你计划只用一台manager管理两个或以上的master-slave对，那么建议你创建一个全局配置文件，这样你就不需要为每一个复制都配置相同的参数。如果你创建了一个文件/etc/masterha_default.cnf，那么它默认就是全局配置文件。

你可以在全局配置文件中设置application scope参数，例如，如果所有的mysql服务器的管理账户和密码都是一样的，你就可以在这里设置user和password

以下是全局配置文件范例

Global configuration file (/etc/masterha_default.cnf)

[serverdefault]

user=root

password=rootpass

ssh_user=root

master_binlog_dir= /var/lib/mysql

remote_workdir=/data/log/masterha

secondary_check_script= masterha_secondary_check-s remote_host1 -s remote_host2

ping_interval=3

master_ip_failover_script=/script/masterha/master_ip_failover

shutdown_script= /script/masterha/power_manager

report_script= /script/masterha/send_master_failover_mail

以上这些参数可适用于所有的applications。

Application配置文件应该被单独配置，以下是app1(host1-4)和app2(host11-14)的范例

app1:

manager_host$ cat /etc/app1.cnf



[server default]

manager_workdir=/var/log/masterha/app1

manager_log=/var/log/masterha/app1/app1.log



[server1]

hostname=host1

candidate_master=1



[server2]

hostname=host2

candidate_master=1



[server3]

hostname=host3



[server4]

hostname=host4

no_master=1

app2:

manager_host$ cat /etc/app2.cnf



[server default]

manager_workdir=/var/log/masterha/app2

manager_log=/var/log/masterha/app2/app2.log



[server1]

hostname=host11

candidate_master=1



[server2]

hostname=host12

candidate_master=1



[server3]

hostname=host13



[server4]

hostname=host14

no_master=1

Requirements and Limitations

1 这一部分做简要翻译，安装MHA的依赖和限制

2 SSH public key认证

3 仅支持Liunx操作系统

4 只有一台master能被设置成readonly=0，其他设置为只读

5如果是Master1 -> Master2-> Slave3这样的三级复制框架，在配置文件中只需要设置master1和master2这样的二级复制结构，并设置multi_tier_slave=1来支持三级复制结构。

6 MHA仅支持mysql 5.0及以后的版本

7 mysqlbinlog必须是3.3及以上版本

8 log-bin必须在每一个可称为master的mysql服务器上设置

9 所有mysql服务器的复制过滤规则必须一致

10 必须在能成为master的服务器上设置复制账户

11所有Mysql服务器上必须设置relay_log_purge=1，使得能够保存一段时间的relay log

12 基于语句的复制时，不要使用load datainfile命令

What MHA does on monitoring and failover

这一部分很多内容与上述重复，我只做简要翻译，在监控和故障转移过程中，MHA主要做了以下几项工作

Verifying replicationsettings and identifying the current master

核实复制配置并识别出当前的master

Monitoring the masterserver

Detecting the masterserver failure

Verifying slaveconfigurations again

Shutting down failedmaster server (optional)

Recovering a newmaster

Activating the newmaster

Recovering the restslaves

Notifications(optional)

监控master server直到master崩溃，在这一步时manager不再监控slave的状态。所以如果需要添加或删除slave节点，最好重新修改manager配置文件并重启MHA

检测到master故障

重新扫描配置文件，各种重连，核实master确实已经崩溃。如果最近一次的报错和现在一样并且时间相隔非常之短，MHA将会停止继续报错并进入下一步

关闭崩溃的主机(可选)，防止错误继续扩散

重新选举出一个新的master。如果崩溃的主机能够通过SSH连接，则复制崩溃主机的binlog到最新的slave上，并指向他的end_log_pos。在选择新的master上遵守manager上的配置文件，如果某个slave能成为master，则设置candidate_master=1。如果某个slave永远不能成为master，则设置no_master=1。识别出最新的slave并将其选举为新的master，最新的slave即接受到最新的relay log的那台slave。

激活新的master

重新设置其余的slave使其指向新选举出来的master

发送通告（可选），比如发送邮件，禁用新master上backup工作等，可通过 report_script脚本设置

What MHA does on online(fast) master switch

简要翻译，在线master切换过程中，MHA主要做了以下工作

Verifying replication settings and identifying the current master

Identifying the new mater

Rejecting writes on the current master

Waiting for all slaves to catch up replication

Granting writes on the new master

Switching replication on all the rest slaves

核实复制配置并识别出当前的master，这个过程还会检测以下几个条件是否满足：

Slave上的IO线程is running

Salve上的SQL线程is running

Slave上所有的复制延迟少于2s

在master上的update操作没有超过2秒的

识别出新的master

在当前master上执行FLUSHTABLES WITH READ LOCK阻塞写操作防止数据一致性问题

等待所有的slave的复制跟上master

在新的master上执行SHOW MASTER STATUS，记录下binlog文件名称和pos，并执行SET GLOBAL read_only=0授权其写操作

在其他salve上并行执行CHANGE MASTER, START SLAVE，指向新的master，并start slave

Parameters

MHA manager配置参数列表如下

hostname

Hostname or IP address of the target MySQL server. This parameteris mandatory, and must be configured under [server_xxx]blockswithin applicationconfiguration file.

MySQL服务器的主机名称或IP地址，写在[server_xxx]下，xxx相当于各个mysql服务器。

ip

IP address of the target MySQL server. Default isgethostbyname($hostname). MHA Manager and MHA Node internally uses this IPaddress to connect via MySQL and SSH. Normally you don't need to configure thisparameter because it's automatically resolved from hostname parameter.

通常不需要配置

port

Port number of the target MySQL server. Default is 3306. MHAconnects to MySQL servers by using IP address and port.

Mysql服务的端口号，默认3306.

ssh_host

Ssh所在服务器，默认和hostname一样，不需要配置。

ssh_ip

(Supported from 0.53) IP address of the target MySQL server thatis used via SSH. Default is gethostbyname($ssh_host).通常不用配置

ssh_port

(Supported from 0.53) Port number of the target MySQL server usedvia SSH. Default is 22.

ssh_connection_timeout

(Supported from 0.54) Default is 5 seconds. Before adding thisparameter timeout was hard coded.

ssh_options

(Supported from 0.53) Additional SSH command line options.

candidate_master

在[server_xxx]下配置，值为1代表该mysql可以成为master，如果有两个以上mysql都设置为1，那么谁写在前面，谁的优先级就高。

no_master

设置为1代表该mysql永远无法成为master，通常在RAID0或者远程数据中心设置该mysql的no_master为1，或者manager和slave复用的主机上也这么设置。

ignore_fail

默认情况下，manager在slave出现故障的时候不会自动故障转移，比如SSH连接或者SQL线程有问题等。如果设置为1则该slave出现故障时会自动切换

skip_init_ssh_check

跳过初始化过程中的ssh检查

skip_reset_slave

0.56版本后支持当master崩溃，跳过执行resetslave

user

mysql管理账户，最好是root账户，默认也就是root账户

password

user对应的mysql账户密码

repl_user

复制账户，通常不用设置

repl_password

复制账户对应的密码，通常不用设置

disable_log_bin

如果这个选项被设置，那么当将不同的relay log应用到各个slave的过程中，slave不产生binlog

master_pid_file

设置master的pid文件，通常不用设置

ssh_user

默认是当前登陆manager的OS的用户，需要拥有读取mysql binlog和relay log的权限

remote_workdir

每一个MHA node节点产生log文件的目录，如果不存在MHA会自动创建，需要给出相应目录的权限，默认在/var/tmp,最好自己指定

master_binlog_dir

master产生binlog文件的目录，最好自己指定，因为当master崩溃后，如果master还能连通SSH，就会复制其binlog，默认路径为/var/lib/mysql.

log_level

通常不用设置,表示日志级别

manager_workdir

manager产生自身状态的文件的目录，默认/var/tmp

client_bindir

If MySQL command line utilities are installed under a non-standarddirectory, use this option to set the directory.

client_libdir

If MySQL libraries are installed under a non-standard directory,use this option to set the directory.

manager_log

Manager日志的全路径名称，若未设置，默认输出到STDOUT/STDERR；

如果手动故障切换时，MHA则忽略参数设置，而直接输出到STDOUT/STDERR。

Full path file name that MHA Manager generates logs. If not set,MHA Manager prints to STDOUT/STDERR. When executing manual failover(interactive failover), MHA Manager ignores manager_log setting and alwaysprints to STDOUT/STDERR.

check_repl_delay

默认情况下，如果某个slave的复制延迟超过100MB，MHA则不会使其成为新的master，因为这需要很长的时间来恢复。如果设为0，MHA在选举新的master时会忽略复制延迟

若设置该参数为0，MHA在选择新的Master时，会忽略复制延迟。当某个mysql设置candidate_master=1时，再将check_repl_delay设置为0就很有必要，确保它能成为新的master

check_repl_filter

检查复制过滤，默认情况下如果master和slave拥有不同的过滤规则就会报错，通过设置为0可以忽略复制过滤检查，当然你得特别小心，确保没有问题。

latest_priority

默认情况下MHA在master崩溃后，选举复制延迟最低的slave为新的master，但允许你自己控制每个slave成为主节点的优先级和顺序，通过设置该参数为0，并由写入candidate_master=1的mysql服务器顺序决定。

multi_tier_slave

从0.52版本开始，MHA支持多级复制配置。默认情况下，不允许设置三层以上的复制结构，比如h2从h1复制，而h3又从h2复制，MHA将会报错。通过设置multi_tier_slave参数，则h1崩溃后，h2被选举为新的master，而h3依旧从h2复制

ping_interval

这个参数指定了MHA manager应该多长时间执行ping SQL一次去连接master，当超过三次连接不上master，manager将判定master已经死亡。默认3秒ping一次，所以，总的检测时间大概就是12秒。如果由于连接错误或者连接数过多而导致的错误不会计入master死亡统计。

ping_type

0.53版本默认连接到master并执行select 1，即ping_type=SELECT。但是在某些场合，更好地方式是通过创建连接后又断开连接的方式，因为这个更加严格，并且能更快地发现tcp连接问题，即ping_type=CONNECT。从5.6版本以后还支持ping_type=INSERT

secondary_check_script

通常情况下，我们建议使用两个或以上的网络路由来检测master是否存活。但默认情况下，manager仅通过单个路由来检查，即from Manager节点to Master节点。MHA实际上可以支持多个路由检测，只要通过调用额外的脚本masterha_check_script即可，下面是范例。

  secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2

masterha_secondary_check脚本在manager节点上，通常情况下能够运行良好。

在这个范例中，MHA通过Manager-(A)->remote_host1-(B)->master_host

和Manager-(A)->remote_host2-(B)->master_host来检测master状态。如果在上述两步中都是A连接成功而B连接不成功，则MHA能够判断是master确实已经死亡并返回0，进行故障切换。如果A连接不成功，该脚本会返回2，MHA认为可能是自身的网络问题而不进行故障转移。如果此时B连接成功，则实际上master是存活的。通俗地说，remote_host1和remote_host2应该被设置在不同的网段上。

该脚本在通用场合中都适用，当然你也可以自己写脚本来实现更多的功能。下面是该脚本的参数列表。

注意该脚本需要依赖于IO::Socket::INET Perl包，Perl v5.6.0中默认已经包括。而该脚本允许连接任何一个远程服务器，所以需要配置SSH public key。并且，该脚本尝试建立远程服务器到master的tcp连接，意味着如果tcp连接成功，则mysql配置文件中的max_connections设置不受影响，而aborts_connects的值会自动加1

master_ip_failover_script

HA方案中，很多情况下人们会在master上绑定一个虚拟IP。当master崩溃的时候，软件比如Keepalived会将虚拟IP重新指向正常的Server。

通用的方法就是创建一个全局的目录库，在库中存放着所有应用和IP地址之间的映射关系，用以取代VIP。在这种方案下，如果master崩溃，那么你就需要修改这个目录库。

都各有优缺点,MHA不会强制使用哪一种，允许用户使用任何的ip漂移技术。master_ip_failover_script 脚本能用于该目的。换句话说，你需要自己写脚本实现应用层连接到新的master，并且必须定义master_ip_failover_script 脚本参数，下面是使用范例

  master_ip_failover_script= /usr/local/sample/bin/master_ip_failover

MHA Manager需要调用3次该脚本，第一次是在启动监控master之前(检查脚本是否可用)，，第二次是在调用shutdown_script脚本之前，而第三次是在新的Master应用完所有的

relay logs之后。MHA Manager会传递如下参数(这些参数不需要你自己配置)：

Checking phase
--command=status --ssh_user=(current master's ssh username) --orig_master_host=(current master's hostname) --orig_master_ip=(current master's ip address) --orig_master_port=(current master's port number)
Current master shutdown phase
--command=stop or stopssh --ssh_user=(dead master's ssh username, if reachable via ssh) --orig_master_host=(current(dead) master's hostname) --orig_master_ip=(current(dead) master's ip address) --orig_master_port=(current(dead) master's port number)
New master activation phase
--command=start --ssh_user=(new master's ssh username) --orig_master_host=(dead master's hostname) --orig_master_ip=(dead master's ip address) --orig_master_port=(dead master's port number) --new_master_host=(new master's hostname) --new_master_ip=(new master's ip address) --new_master_port(new master's port number) --new_master_user=(new master's user) --new_master_password(new master's password)

如果你在master上使用了VIP，当master关闭阶段你可能不需要做任何事，只要你能够让VIP漂移到新的master。如果你使用的目录库方案，你可能需要删除或更新在master上的记录。在新的master激活阶段，你可以在新的master上插入/更新一条记录。并且，你可以做任何事使得应用层能够向新master中插入数据，比如设置read_only=0,创建用户的写权限等。

MHA manager会检查这个脚本返回的运行结果，如果返回0或10，则MHA manager继续运行。如果返回的不是0或10，mangaer就会终止。默认参数空置，所以MHA manager不会做任何事。

master_ip_online_change_script

这个和master_ip_failover_script参数相似，但它并不是用在master故障切换上，而是用在master在线手动切换命令上，传递参数过程如下

Current master write freezing phase
--command=stop or stopssh --orig_master_host=(current master's hostname) --orig_master_ip=(current master's ip address) --orig_master_port=(current master's port number) --orig_master_user=(current master's user) --orig_master_password=(current master's password) --orig_master_ssh_user=(from 0.56, current master's ssh user) --orig_master_is_new_slave=(from 0.56, notifying whether the orig master will be new slave or not)
New master granting write phase
--command=start --orig_master_host=(orig master's hostname) --orig_master_ip=(orig master's ip address) --orig_master_port=(orig master's port number) --new_master_host=(new master's hostname) --new_master_ip=(new master's ip address) --new_master_port(new master's port number) --new_master_user=(new master's user) --new_master_password=(new master's password) --new_master_ssh_user=(from 0.56, new master's ssh user)

shutdown_script

你或许希望强制关闭master所在的服务器，这样就可以防止灾难扩散，以下是范例

  shutdown_script= /usr/local/sample/bin/power_manager

MHA manager包中有一个范例脚本，在调用该命令前，MHA内部会检查master能否通过SSH连接。如果可连接(OS存活但是mysqld服务终止)，MHA manager传递如下参数

If the master is not reachable via SSH, MHA Manager passes thefollowing arguments.

该脚本以如下方式运行。如果--command=stopssh被通过，则该脚本会通过ssh在mysqld和mysqld_safe进程上执行kill -9操作。如果—pid_file同样被通过，该脚本就会尝试只杀死代理的进程，而不是所有的mysql进程，这在单个master上运行多实例时是非常有用的。如果成功地通过SSH停止了该服务，则脚本运行结果返回10，并且后续manager会通过SSH连接到master并保存必要的binlog。如果该脚本无法通过SSH连接到master或者—command命令通过的话，那么该脚本将会尝试关闭机器电源。关闭电源依赖于H/W。如果电源关闭成功，该脚本返回0，否则返回1。当MHA接到返回的0时即开始故障切换。如果返回的代码既不是0也不是10，MHA将会终止故障转移工作。缺省参数为空，所以默认情况下MHA不对其做任何事。

并且，MHA在开始监控之后就会调用该脚本，以下参数将会在这个时候被传递过去，你可以在这里检测脚本设置。是否控制电源很多程度上决定于H/W，所以非常简易在这里检测电源状态。如果你哪里配置错了，在启动监控的时候你需要特别小心。

report_script

当故障切换完成或返回错误的时候，你或许希望可以发送一个报告给你，report_script参数可适用于这种场合。MHA manager将会传递如下参数

默认情况下该参数为空，即MHA不对其做任何事。在MHAmanager包的

Default parameter is empty, so MHA Manager does not invokeanything by default. /samples/scripts/send_report目录下有使用范例。

init_conf_load_script

这个脚本能被应用于你不想在配置文件中填写清楚的文本信息，比如密码和复制账户的密码。通过从这个脚本中返回name=value对，你可以重写这个全局配置文件。范例如下

  #!/usr/bin/perl
  
  print "password=$ROOT_PASS\n";
  print "repl_password=$REPL_PASS\n";

缺省参数为空，所以MHA不对其做任何事。

Command reference

这一部分不做翻译，通常情况下只需要运行范例的命令，参数的详细介绍请见官方文档。

masterha_manager: 开启MHA Manager

  # masterha_manager --conf=/etc/conf/masterha/app1.cnf

masterha_master_switch：切换master，分故障master切换和在线master切换两种

交互式故障master切换

$ masterha_master_switch --master_state=dead --conf=/etc/app1.cnf--dead_master_host=host1

指定新的master

$ masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=host1 --new_master_host=host5

非交互式

$ masterha_master_switch --master_state=dead --conf=/etc/conf/masterha/app1.cnf --dead_master_host=host1 --new_master_host=host2 --interactive=0

在线master切换

$ masterha_master_switch --master_state=alive --conf=/etc/app1.cnf --new_master_host=host2

masterha_check_status：检查MHA运行状态

$ masterha_check_status --conf=/path/to/app1.cnf
  app1 (pid:8368) is running(0:PING_OK), master:host1
  $ echo $?
  0

masterha_check_repl：检查复制健康状态

manager_host$ masterha_check_repl --conf=/etc/app1.cnf
  ...
  MySQL Replication Health is OK.

masterha_stop：停止MHA manager运行

manager_host$ masterha_stop --conf=/etc/app1.cnf
  Stopped app1 successfully.

Masterha_conf_host：在配置文件中添加或移除host

# masterha_conf_host --command=add--conf=/etc/conf/masterha/app1.cnf --hostname=db101

Then the following lines will be added to theconf file.

[server_db101]

hostname=db101

You can add several parameters in the configfile by passing --param parameters, separated by semi-colon(;).

# masterha_conf_host --command=add--conf=/etc/conf/masterha/app1.cnf --hostname=db101 --block=server100--params="no_master=1;ignore_fail=1"

The following lines will be added to the conffile.

[server100]

hostname=db101

no_master=1

ignore_fail=1

You can also remove specified block. Thebelow command will remove the etire block server100.

# masterha_conf_host --command=delete--conf=/etc/conf/masterha/app1.cnf --block=server100

masterha_conf_host takes below arguments

master_check_ssh:ssh认证检查

# masterha_check_ssh --conf=/etc/app1.cnf
  
  Sat May 14 14:42:19 2011 - [warn] Global configuration file /etc/masterha_default.cnf not found. Skipping.
  Sat May 14 14:42:19 2011 - [info] Reading application default configurations from /etc/app1.cnf..
  Sat May 14 14:42:19 2011 - [info] Reading server configurations from /etc/app1.cnf..
  Sat May 14 14:42:19 2011 - [info] Starting SSH connection tests..
  Sat May 14 14:42:19 2011 - [debug]  Connecting via SSH from root@host1(192.168.0.1) to root@host2(192.168.0.2)..
  Sat May 14 14:42:20 2011 - [debug]   ok.
  Sat May 14 14:42:20 2011 - [debug]  Connecting via SSH from root@host1(192.168.0.1) to root@host3(192.168.0.3)..
  Sat May 14 14:42:20 2011 - [debug]   ok.
  Sat May 14 14:42:21 2011 - [debug]  Connecting via SSH from root@host2(192.168.0.2) to root@host1(192.168.0.1)..
  Sat May 14 14:42:21 2011 - [debug]   ok.
  Sat May 14 14:42:21 2011 - [debug]  Connecting via SSH from root@host2(192.168.0.2) to root@host3(192.168.0.3)..
  Sat May 14 14:42:21 2011 - [debug]   ok.
  Sat May 14 14:42:22 2011 - [debug]  Connecting via SSH from root@host3(192.168.0.3) to root@host1(192.168.0.1)..
  Sat May 14 14:42:22 2011 - [debug]   ok.
  Sat May 14 14:42:22 2011 - [debug]  Connecting via SSH from root@host3(192.168.0.3) to root@host2(192.168.0.2)..
  Sat May 14 14:42:22 2011 - [debug]   ok.
  Sat May 14 14:42:22 2011 - [info] All SSH connection tests passed successfully.

purge_relay_logs script：删除旧的relay log

[app@slave_host1]$ cat /etc/cron.d/purge_relay_logs
  # purge relay logs at 5am
  0 5 * * * app /usr/bin/purge_relay_logs --user=root --password=PASSWORD --disable_relay_log_purge >> /var/log/masterha/purge_relay_logs.log 2>&1

Monitoring multiple applications

你或许在一台机子上希望监控多套master-salve复制，这非常容易，只要为application2创建一个新的配置文件并启动manager

  # masterha_manager --conf=/etc/conf/masterha/app1.cnf
  # masterha_manager --conf=/etc/conf/masterha/app2.cnf

如果你在app1和app2上有一些共有的参数，可在全局配置文件中配置。

Using with clustering software

如果你在master上使用虚拟IP，你可能已经使用了类似于Pacemaker的集群软件。如果你使用了相似的工具，你或许需要使用它们来管理虚拟IP地址，而不是让所有的事都由MHA完成。MHA仅用于故障切换，所以你需要使用配合使用其他集群工具来实现高可用。

下面是一个简要的Pacemaker配置(Heartbeat v1 模式)

# /etc/ha.d/haresources on host2

host2 failover_start IPaddr::192.168.0.3

# failover_start script example

start)

`masterha_master_switch --master_state=dead--interactive=0 --wait_on_failover_error=0 --dead_master_host=host1--new_master_host=host2`

exit

stop)

# do nothing

# Application configuration file:

[server1]

hostname=host1

candidate_master=1

[server2]

hostname=host2

candidate_master=1

[server3]

hostname=host3

no_master=1

因为数据文件不是共享的，所以数据资源也不用被集群工具或DRBD管理。处于这个目的，集群工具仅仅实现一个执行masterha_master_switch脚本和虚拟IP漂移的功能，你也可以自己使用手工脚本实现这些功能。