MHA官方文档翻译

翻译by 胡儿胡儿

文中翻译有一些不足之处和略过没做翻译的部分。具体请參考英文官方文档

http://code.google.com/p/mysql-master-ha/wiki/TableOfContents?tm=6

转载请注明出处

 

Overview

MHA可以在较短的时间内实现自己主动故障检測和故障转移，通常在10-30秒以内;在复制框架中，MHA可以非常好地解决复制过程中的数据一致性问题，因为不须要在现有的replication中加入额外的server，仅须要一个manager节点。而一个Manager能管理多套复制，所以能大大地节约server的数量;另外，安装简单，无性能损耗，以及不须要改动现有的复制部署也是它的优势之处。

MHA还提供在线主库切换的功能，可以安全地切换当前执行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内就可以完毕。

MHA提供了上述功能，使得其在适用于对高可用性，数据完整性要求高的场合。还有要求差点儿non-stop的主库维护。

◎自己主动故障检測和自己主动故障转移

MHA可以在一个已经存在的复制环境中监控MySQL。当检測到Master故障后可以实现自己主动故障转移，通过鉴定出最“新”的Salve的relay log，并将其应用到全部的Slave。这样MHA就行保证各个slave之间的数据一致性，即使有些slave在主库崩溃时还没有收到最新的relay log事件。通常情况下MHA可以达到例如以下指标：9-12秒检測到主库故障，7-10秒关闭master所在的mysqld服务以防止故障扩散，并在几秒内实现各个slave上的relay log重放到新的master。总共的down time通常控制在10-30秒内。一个slave节点是否能成为候选的主节点可通过在配置文件里配置它的优先级。因为master可以保证各个slave之间的数据一致性，所以全部的slave节点都有希望成为主节点。在通常的replication环境中因为复制中断而极easy产生的数据一致性问题，在MHA中将不会发生。

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

MHA能够被定义成手动地实现故障转移，而不必去理会master的状态，即不监控master状态，确认故障发生后可通过MHA手动切换。

◎非交互式的故障转移

即不监控Master状态，可是发生问题后可通过MHA实现自己主动转移。

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

通常当RAID控制器或者RAM损坏。或者须要将现有的masterserver进行升级的时候，我们就须要切换当前的master到其它的主机中。这并非主库崩溃，可是却须要我们手动切换。这一般是越快越好。由于这段时间内主库是写禁止的。所以。你还须要堵塞或删除正在进行的会话，由于不禁止写就会导致数据一致性问题。

举个样例。updating master1, updating master 2,committing master1, getting error on committing master 2就会导致数据一致性问题。

所以说，高速的切换和优美平滑的堵塞写都是须要的。

MHA可以在0.5-2秒内实现切换，0.5-2秒的写堵塞一般是可接受的。所以你甚至能在非维护期间就在线切换master。诸如升级到高版本号，升级到更快的server之类的工作，将会变得更easy。

 

Architecture of MHA

当主库发生崩溃，MHA通过下面方式修复

关于MHA怎样修复一致性问题，具体请查看例如以下链接地址，这里我不做具体研究

http://www.slideshare.net/matsunobu/automated-master-failover

 

MHA Components

MHA由Manager节点和Node节点组成。

 

Manaer模块：能够管理多套Master-Slave Replication

Masterha_manager：提供实现自己主动故障检測和故障转移的命令

其它帮助脚本：提供手工故障转移，在线master切换，con 检查等功能

Node模块：部署在全部的MySQL Server上

Save_binary_logs:如有必要。复制master的二进制日志

Apply_diff_relay_logs:从数据最新的slave上产生不同的relay log，而且将其应用到不同的binlog events中

Purge_relay_log：清除relay log

MHA manager节点上执行着这些程序：监控mysql状态，master故障转移等。

MHA node节点上有实现自己主动故障转移的helper脚本，比方分析mysql binary/relay log，认出哪一个relay log应该应用到其它的slave。并识别出这个relay log的位置。并将events应用到目标slave上等。

Node节点应该执行在每个mysql server上。

假设MHA Manager挂掉了。MHA会尝试通过SSH连接到node节点并运行node节点的命令

 

 

Advantages of MHA

这一节简略介绍，大致内容在上面的叙述中已经有提到。

1    Masterfailover and slave promotion can be done very quickly

自己主动故障转移快

2    Mastercrash does not result in data inconsistency

主库崩溃不存在数据一致性问题

3    Noneed to modify current MySQL settings (MHA works with regular MySQL (5.0 orlater))

不须要对当前mysql环境做重大改动

4    Noneed to increase lots of servers

不须要加入额外的server(仅一台manager就可管理上百个replication)

5    Noperformance penalty

性能优秀，可工作在半同步复制和异步复制。当监控mysql状态时，仅须要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你能够理解为MHA的性能和简单的主从复制框架性能一样。

6  Works with any storage engine

仅仅要replication支持的存储引擎。MHA都支持，不会局限于innodb

 

Typical Use cases

怎么部署Manager节点

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

因为MHA manager只使用了非常少的cpu和内存资源，所以你能够让一个manager管理非常多个replication。甚至超过100个replication

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

    假如你仅仅有一个replication环境，并且你可能不喜欢为配置一个专门的manager而花费了很多其它的硬件开销，那么你能够让manager和一个slave节点复用。值得注意的是，假设这么配置了，虽然manager和slave在同一台机子上了，可是manger依然通过SSH连接到slave，所以你依然须要配置SSH无password登陆。

 

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

Singlemaster, multiple slaves

一主多从，这是最普遍的情况。

Singlemaster, multiple slaves (one on remote datacenter)

一主多从，将当中一个从配置成远程数据中心。其永远不会成为master

Singlemaster, multiple slaves, one candidate master

一主多从，并仅仅配置一个候选主节点

Multiplemasters, multiple slaves

Threetier replication

 

管理MasterIP地址

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

    通用的方法就是创建一个全局的文件夹库，在库中存放着全部应用和IP地址之间的映射关系。用以代替VIP。在这样的方案下。假设master崩溃，那么你就须要改动这个文件夹库。

两种方案都各有优缺点,MHA不会强制使用哪一种。

MHA能够调用其它的脚本来禁用激活write ip地址。通过设置master_ip_failover_script 脚本的參数，该脚本可在manager节点中找到。你能够在该脚本中更新文件夹库，或者实现VIP漂移等不论什么你想干的事。

你相同能够借用现有的HA方案的软件实现IP故障转移，比方Pacemaker。在这样的情况下MHA将不会做IP故障转移。

和MySQL半同步复制配合使用

虽然MHA试图从崩溃的master上保存binarylog，但这并不总是可行的。

比如。假设master是由于H/W故障或者是SSH故障。则MHA无法保存binlog，从而无法应用仅存在master上的binlog进行故障转移，这将会导致丢失近期的数据。

使用半同步复制可以极大地降低这样的丢失数据的风险。因为它也是基于mysql的复制机制，所以MHA可以配合半同步复制一起使用。值得一提的是。仅仅要有一台slave收到最新的binlog events。则MHA就会将它应用到全部的slave，从而保证了数据的一致性。

Tutorial

创建通用的复制环境

MHA不会自己创建replication环境。所以你须要自己手动搭建。换句话说，你能够将MHA部署在现有的复制环境中。

举个样例，如果有四台主机：host1，host2。host3。host4.我们将host1配置成master，host2和host3配置成slave。而host4配置成manager

 

在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节点

MHA的manager节点提供masterha_manager,masterha_master_switch等命令行的功能。依赖与Perl模块。在安装manager节点之前，你须要安装下面prel模块。另外别忘了在manager节点安装node节点。

• MHA Node package
• DBD::mysql
• Config::Tiny
• Log::Dispatch
• Parallel::ForkManager
• Time::HiRes (included from Perl v5.7.3)

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的username，password，复制账户的username和password，工作文件夹等。全部的參数列表详见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无password登陆。

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的自己主动故障转移

如今master执行正常，manager监控也正常，下一步就是停止master。測试自己主动故障转移。你能够简单地停止master上的mysqld服务

  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进程所在的server的username和password。mysql服务的username和password，工作文件夹等等。整个參数列表设置具体请见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參数，比如，假设全部的mysqlserver的管理账户和密码都是一样的，你就能够在这里设置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的mysqlserver上设置

9 全部mysqlserver的复制过滤规则必须一致

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

11全部Mysqlserver上必须设置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配置參数列表例如以下

Parameter Name	Required?	Parameter Scope	Default Value	Example
hostname	Yes	Local Only	-	hostname=mysql_server1, hostname=192.168.0.1, etc
ip	No	Local Only	gethostbyname($hostname)	ip=192.168.1.3
port	No	Local/App/Global	3306	port=3306
ssh_host	No	Local Only	same as hostname	ssh_host=mysql_server1, ssh_host=192.168.0.1, etc
ssh_ip	No	Local Only	gethostbyname($ssh_host)	ssh_ip=192.168.1.3
ssh_port	No	Local/App/Global	22	ssh_port=22
ssh_connection_timeout	No	Local/App/Global	5	ssh_connection_timeout=20
ssh_options	No	Local/App/Global	""(empty string)	ssh_options="-i /root/.ssh/id_dsa2"
candidate_master	No	Local Only	0	candidate_master=1
no_master	No	Local Only	0	no_master=1
ignore_fail	No	Local Only	0	ignore_fail=1
skip_init_ssh_check	No	Local Only	0	skip_init_ssh_check=1
skip_reset_slave	No	Local/App/Global	0	skip_reset_slave=1
user	No	Local/App/Global	root	user=mysql_root
password	No	Local/App/Global	""(empty string)	password=rootpass
repl_user	No	Local/App/Global	Master_User value from SHOW SLAVE STATUS	repl_user=repl
repl_password	No	Local/App/Global	- (current replication password)	repl_user=replpass
disable_log_bin	No	Local/App/Global	0	disable_log_bin=1
master_pid_file	No	Local/App/Global	""(empty string)	master_pid_file=/var/lib/mysql/master1.pid
ssh_user	No	Local/App/Global	current OS user	ssh_user=root
remote_workdir	No	Local/App/Global	/var/tmp	remote_workdir=/var/log/masterha/app1
master_binlog_dir	No	Local/App/Global	/var/lib/mysql	master_binlog_dir=/data/mysql1,/data/mysql2
log_level	No	App/Global	info	log_level=debug
manager_workdir	No	App	/var/tmp	manager_workdir=/var/log/masterha
client_bindir	No	App	-	client_bindir=/usr/mysql/bin
client_libdir	No	App	-	client_libdir=/usr/lib/mysql
manager_log	No	App	STDERR	manager_log=/var/log/masterha/app1.log
check_repl_delay	No	App/Global	1	check_repl_delay=0
check_repl_filter	No	App/Global	1	check_repl_filter=0
latest_priority	No	App/Global	1	latest_priority=0
multi_tier_slave	No	App/Global	0	multi_tier_slave=1
ping_interval	No	App/Global	3	ping_interval=5
ping_type	No	App/Global	SELECT	ping_type=CONNECT
secondary_check_script	No	App/Global	null	secondary_check_script= masterha_secondary_check -s remote_dc1 -s remote_dc2
master_ip_failover_script	No	App/Global	null	master_ip_failover_script=/usr/local/custom_script/master_ip_failover
master_ip_online_change_script	No	App/Global	null	master_ip_online_change_script= /usr/local/custom_script/master_ip_online_change
shutdown_script	No	App/Global	null	shutdown_script= /usr/local/custom_script/master_shutdown
report_script	No	App/Global	null	report_script= /usr/local/custom_script/report
init_conf_load_script	No	App/Global	null	report_script= /usr/local/custom_script/init_conf_loader

• Local Scope: Per-server scope parameters. Local scope parameters should be set under [server_xxx] blocks within application configuration file.
• App Scope: Parameters for each {master, slaves} pair. These parameters should be set under a [server_default] block withinapplication configuration file.
• Global Scope: Parameters for all {master, slaves} pairs. Global scope parameters are useful only when you manage multiple {master, slaves} pairs from single manager server. These parameters should be set in a global configuration file.

hostname

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

MySQLserver的主机名称或IP地址，写在[server_xxx]下，xxx相当于各个mysqlserver。

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服务的port号，默认3306.

ssh_host

Ssh所在server，默认和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账户password

repl_user

复制账户，通常不用设置

repl_password

复制账户相应的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的mysqlserver顺序决定。

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应该被设置在不同的网段上。

该脚本在通用场合中都适用，当然你也能够自己写脚本来实现很多其它的功能。以下是该脚本的參数列表。

• --user=(SSH username of the remote hosts. ssh_user parameter value will be passed)
• --master_host=(master's hostname)
• --master_ip=(master's ip address)
• --master_port=(master's port number)

注意该脚本须要依赖于IO::Socket::INET Perl包，Perl v5.6.0中默认已经包含。

而该脚本同意连接不论什么一个远程server，所以须要配置SSH public key。

而且，该脚本尝试建立远程server到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所在的server，这样就能够防止灾难扩散，下面是范例

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

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

• --command=stopssh
• --ssh_user=(ssh username so that you can connect to the master)
• --host=(master's hostname)
• --ip=(master's ip address)
• --port=(master's port number)
• --pid_file=(master's pid file)

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

• --command=stop
• --host=(master's hostname)
• --ip=(master's ip address)

该脚本以例如以下方式执行。

假设--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，所以非常简易在这里检測电源状态。

假设你哪里配置错了。在启动监控的时候你须要特别小心。

• --command=status
• --host=(master's hostname)
• --ip=(master's ip address)

report_script

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

• --orig_master_host=(dead master's hostname)
• --new_master_host=(new master's hostname)
• --new_slave_hosts=(new slaves' hostnames, delimited by commas)
• --subject=(mail subject)
• --body=(body)

默认情况下该參数为空，即MHA不正确其做不论什么事。在MHAmanager包的

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

init_conf_load_script

这个脚本能被应用于你不想在配置文件里填写清楚的文本信息，比方password和复制账户的password。通过从这个脚本中返回name=value对，你能够重写这个全局配置文件。

范比例如以下

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

缺省參数为空。所以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

Status Code(Exit code)	Status String	Description
0	PING_OK	Master is running and MHA Manager is monitoring. Master state is alive.
1	---	Unexpected error happened. For example, config file does not exist. If this error happens, check arguments are valid or not.
2	NOT_RUNNING	MHA Manager is not running. Master state is unknown.
3	PARTIALLY_RUNNING	MHA Manager main process is not running, but child processes are running. This should not happen and should be investigated. Master state is unknown.
10	INITIALIZING_MONITOR	MHA Manager is just after startup and initializing. Wait for a while and see how the status changes. Master state is unknown.
20	PING_FAILING	MHA Manager detects ping to master is failing. Master state is maybe down.
21	PING_FAILED	MHA Manager detects either a) ping to master failed three times, b) preparing for starting master failover. Master state is maybe down.
30	RETRYING_MONITOR	MHA Manager internal health check program detected that master was not reachable from manager, but after double check MHA Manager verified the master is alive, and currently waiting for retry. Master state is very likely alive.
31	CONFIG_ERROR	There are some configuration problems and MHA Manager can't monitor the target master. Check a logfile for detail. Master state is unknown.
32	TIMESTAMP_OLD	MHA Manager detects that ping to master is ok but status file is not updated for a long time. Check whether MHA Manager itself hangs or not. Master state is unknown.
50	FAILOVER_RUNNING	MHA Manager confirms that master is down and running failover. Master state is dead.
51	FAILOVER_ERROR	MHA Manager confirms that master is down and running failover, but failed during failover. Master state is dead.

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复制，这很easy。仅仅要为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漂移的功能。你也能够自己使用手工脚本实现这些功能。