您的位置：首页 > 其它

MHA官方文档翻译

2017-12-06 13:17 344 查看

英文官方文档

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

转载请注明出处

Overview

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

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

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

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

[b]◎交互式（手动）故障转移[/b]
MHA可以被定义成手动地实现故障转移，而不必去理会master的状态，即不监控master状态，确认故障发生后可通过MHA手动切换。

[b]◎非交互式的故障转移[/b]
即不监控Master状态，但是发生故障后可通过MHA实现自动转移。

[b]◎在线切换Master到不同的主机[/b]
通常当RAID控制器或者RAM损坏，或者需要将现有的master服务器进行升级的时候，我们就需要切换当前的master到其他的主机中。这并不是主库崩溃，但是却需要我们手动切换。这通常是越快越好，因为这段时间内主库是写禁止的。所以，你还需要阻塞或删除正在进行的会话，因为不禁止写就会导致数据一致性问题。举个例子，updatingmaster1,updatingmaster2,committingmaster1,gettingerroroncommittingmaster2就会导致数据一致性问题。所以说，快速的切换和优美平滑的阻塞写都是需要的。

MHA能够在0.5-2秒内实现切换，0.5-2秒的写阻塞通常是可接受的，所以你甚至能在非维护期间就在线切换master。诸如升级到高版本，升级到更快的服务器之类的工作，将会变得更容易。

ArchitectureofMHA

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

关于MHA如何修复一致性问题，详细请查看如下链接地址，这里我不做详细研究

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

MHAComponents

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

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

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

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

Node模块：部署在所有的MySQLServer上

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

Apply_diff_relay_logs:从数据最新的slave上产生不同的relaylog，并且将其应用到不同的binlogevents中

Purge_relay_log：清除relaylog

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

MHAnode节点上有实现自动故障转移的helper脚本，比如分析mysqlbinary/relaylog，认出哪一个relaylog应该应用到其他的slave，并识别出这个relaylog的位置，并将events应用到目标slave上等。Node节点应该运行在每一个mysqlserver上。

如果MHAManager挂掉了，MHA会尝试通过SSH连接到node节点并执行node节点的命令

AdvantagesofMHA

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

1Masterfailoverandslavepromotioncanbedoneveryquickly

自动故障转移快

2Mastercrashdoesnotresultindatainconsistency

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

3NoneedtomodifycurrentMySQLsettings(MHAworkswithregularMySQL(5.0orlater))

不需要对当前mysql环境做重大修改

4Noneedtoincreaselotsofservers

不需要添加额外的服务器(仅一台manager就可管理上百个replication)

5Noperformancepenalty

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

6Workswithanystorageengine

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

TypicalUsecases

怎么部署Manager节点

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

由于MHAmanager仅仅使用了非常少的cpu和内存资源，所以你可以让一个manager管理很多个replication，甚至超过100个replication

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

假如你只有一个replication环境，而且你可能不喜欢为配置一个专门的manager而花费了更多的硬件开销，那么你可以让manager和一个slave节点复用。值得注意的是，如果这么配置了，尽管manager和slave在同一台机子上了，但是manger依旧通过SSH连接到slave，所以你依旧需要配置SSH无密码登陆。

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

Singlemaster,multipleslaves

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

Singlemaster,multipleslaves(oneonremotedatacenter)

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

Singlemaster,multipleslaves,onecandidatemaster

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

Multiplemasters,multipleslaves

Threetierreplication

管理MasterIP地址

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

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

两种方案都各有优缺点,MHA不会强制使用哪一种。MHA可以调用其他的脚本来禁用\激活writeip地址，通过设置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收到最新的binlogevents，则MHA就会将它应用到所有的slave，从而保证了数据的一致性。

Tutorial

创建通用的复制环境

MHA不会自己创建replication环境，所以你需要自己手动搭建。换句话说，你可以将MHA部署在现有的复制环境中。举个例子，假设有四台主机：host1，host2，host3，host4.我们将host1配置成master，host2和host3配置成slave，而host4配置成manager

在host1-host4上安装node节点

RHEL/Centos系统

##IfyouhavenotinstalledDBD::mysql,installitlikebelow,orinstallfromsource.
#yuminstallperl-DBD-MySQL

##GetMHANoderpmpackagefrom"Downloads"section.
#rpm-ivhmha4mysql-node-X.Y-0.noarch.rpm

Ubuntu/Debian系统

##IfyouhavenotinstalledDBD::mysql,installitlikebelow,orinstallfromsource.
#apt-getinstalllibdbd-mysql-perl

##GetMHANodedebpackagefrom"Downloads"section.
#dpkg-imha4mysql-node_X.Y_all.deb

源码安装

##InstallDBD::mysqlifnotinstalled
$tar-zxfmha4mysql-node-X.Y.tar.gz
$perlMakefile.PL
$make
$sudomakeinstall

在host4上安装manager节点

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

MHANodepackage

DBD::mysql

Config::Tiny

Log::Dispatch

Parallel::ForkManager

Time::HiRes(includedfromPerlv5.7.3)

RHEL/Centos系统

##InstalldependentPerlmodules
#yuminstallperl-DBD-MySQL
#yuminstallperl-Config-Tiny
#yuminstallperl-Log-Dispatch
#yuminstallperl-Parallel-ForkManager

##InstallMHANode,sinceMHAManagerusessomemodulesprovidedbyMHANode.
#rpm-ivhmha4mysql-node-X.Y-0.noarch.rpm

##FinallyyoucaninstallMHAManager
#rpm-ivhmha4mysql-manager-X.Y-0.noarch.rpm

Ubuntu/Debian系统

##InstalldependentPerlmodules
#apt-getinstalllibdbd-mysql-perl
#apt-getinstalllibconfig-tiny-perl
#apt-getinstallliblog-dispatch-perl
#apt-getinstalllibparallel-forkmanager-perl

##InstallMHANode,sinceMHAManagerusessomemodulesprovidedbyMHANode.
#dpkg-imha4mysql-node_X.Y_all.deb

##FinallyyoucaninstallMHAManager
#dpkg-imha4mysql-manager_X.Y_all.deb

源码安装

##InstalldependentPerlmodules
#MHANode(Seeabove)
#Config::Tiny
##perl-MCPAN-e"installConfig::Tiny"
#Log::Dispatch
##perl-MCPAN-e"installLog::Dispatch"
#Parallel::ForkManager
##perl-MCPAN-e"installParallel::ForkManager"
##InstallingMHAManager
$tar-zxfmha4mysql-manager-X.Y.tar.gz
$perlMakefile.PL
$make
$sudomakeinstall

创建配置文件

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

manager_host$cat/etc/app1.cnf

[serverdefault]
#mysqluserandpassword
user=root
password=mysqlpass
ssh_user=root
#workingdirectoryonthemanager
manager_workdir=/var/log/masterha/app1
#workingdirectoryonMySQLservers
remote_workdir=/var/log/masterha/app1

[server1]
hostname=host1

[server2]
hostname=host2

[server3]
hostname=host3

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

检查SSH连接

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

#masterha_check_ssh--conf=/etc/app1.cnf

SatMay1414:42:192011-[warn]Globalconfigurationfile/etc/masterha_default.cnfnotfound.Skipping.
SatMay1414:42:192011-[info]Readingapplicationdefaultconfigurationsfrom/etc/app1.cnf..
SatMay1414:42:192011-[info]Readingserverconfigurationsfrom/etc/app1.cnf..
SatMay1414:42:192011-[info]StartingSSHconnectiontests..
SatMay1414:42:192011-[debug]ConnectingviaSSHfromroot@host1(192.168.0.1)toroot@host2(192.168.0.2)..
SatMay1414:42:202011-[debug]ok.
SatMay1414:42:202011-[debug]ConnectingviaSSHfromroot@host1(192.168.0.1)toroot@host3(192.168.0.3)..
SatMay1414:42:202011-[debug]ok.
SatMay1414:42:212011-[debug]ConnectingviaSSHfromroot@host2(192.168.0.2)toroot@host1(192.168.0.1)..
SatMay1414:42:212011-[debug]ok.
SatMay1414:42:212011-[debug]ConnectingviaSSHfromroot@host2(192.168.0.2)toroot@host3(192.168.0.3)..
SatMay1414:42:212011-[debug]ok.
SatMay1414:42:222011-[debug]ConnectingviaSSHfromroot@host3(192.168.0.3)toroot@host1(192.168.0.1)..
SatMay1414:42:222011-[debug]ok.
SatMay1414:42:222011-[debug]ConnectingviaSSHfromroot@host3(192.168.0.3)toroot@host2(192.168.0.2)..
SatMay1414:42:222011-[debug]ok.
SatMay1414:42:222011-[info]AllSSHconnectiontestspassedsuccessfully.

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

检查复制配置

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

manager_host$masterha_check_repl--conf=/etc/app1.cnf
...
MySQLReplicationHealthisOK.

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

开启Manager

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

manager_host$masterha_manager--conf=/etc/app1.cnf
....
SatMay1415:58:292011-[info]Connectingtothemasterhost1(192.168.0.1:3306)andsleepinguntilitdoesn'trespond..

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

检查manager状态

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

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

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

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

终止manager

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

manager_host$masterha_stop--conf=/etc/app1.cnf
Stoppedapp1successfully.

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

测试master的自动故障转移

现在master运行正常，manager监控也正常，下一步就是停止master，测试自动故障转移，你可以简单地停止master上的mysqld服务

host1$killall-9mysqldmysqld_safe

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

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

manager_host$nohupmasterha_manager--conf=/etc/app1.cnf</dev/null>/var/log/masterha/app1/app1.log2>&1&

Writinganapplicationconfigurationfile

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

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

manager_host$cat/etc/app1.cnf

[serverdefault]
#mysqluserandpassword
user=root
password=mysqlpass
#workingdirectoryonthemanager
manager_workdir=/var/log/masterha/app1
#managerlogfile
manager_log=/var/log/masterha/app1/app1.log
#workingdirectoryonMySQLservers
remote_workdir=/var/log/masterha/app1

[server1]
hostname=host1

[server2]
hostname=host2

[server3]
hostname=host3

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

[server1]
hostname=host1
#incorrect:mustbe"no_master=1"
no_master

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

Writingaglobalconfigurationfile

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

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

以下是全局配置文件范例

Globalconfigurationfile(/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-sremote_host1-sremote_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

[serverdefault]
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

[serverdefault]
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

RequirementsandLimitations

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

2SSHpublickey认证

3仅支持Liunx操作系统

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

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

6MHA仅支持mysql5.0及以后的版本

7mysqlbinlog必须是3.3及以上版本

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

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

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

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

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

WhatMHAdoesonmonitoringandfailover

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

Verifyingreplicationsettingsandidentifyingthecurrentmaster

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

Monitoringthemasterserver
Detectingthemasterserverfailure
Verifyingslaveconfigurationsagain
Shuttingdownfailedmasterserver(optional)
Recoveringanewmaster
Activatingthenewmaster
Recoveringtherestslaves
Notifications(optional)

监控masterserver直到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即接受到最新的relaylog的那台slave。

激活新的master

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

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

WhatMHAdoesononline(fast)masterswitch

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

Verifyingreplicationsettingsandidentifyingthecurrentmaster
Identifyingthenewmater
Rejectingwritesonthecurrentmaster
Waitingforallslavestocatchupreplication
Grantingwritesonthenewmaster
Switchingreplicationonalltherestslaves

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

Slave上的IO线程isrunning

Salve上的SQL线程isrunning

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

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

识别出新的master

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

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

在新的master上执行SHOWMASTERSTATUS，记录下binlog文件名称和pos，并执行SETGLOBALread_only=0授权其写操作

在其他salve上并行执行CHANGEMASTER,STARTSLAVE，指向新的master，并startslave

Parameters

MHAmanager配置参数列表如下

ParameterName	Required?	ParameterScope	DefaultValue	Example
hostname	Yes	LocalOnly	-	hostname=mysql_server1,hostname=192.168.0.1,etc
ip	No	LocalOnly	gethostbyname($hostname)	ip=192.168.1.3
port	No	Local/App/Global	3306	port=3306
ssh_host	No	LocalOnly	sameashostname	ssh_host=mysql_server1,ssh_host=192.168.0.1,etc
ssh_ip	No	LocalOnly	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	""(emptystring)	ssh_options="-i/root/.ssh/id_dsa2"
candidate_master	No	LocalOnly	0	candidate_master=1
no_master	No	LocalOnly	0	no_master=1
ignore_fail	No	LocalOnly	0	ignore_fail=1
skip_init_ssh_check	No	LocalOnly	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	""(emptystring)	password=rootpass
repl_user	No	Local/App/Global	Master_UservaluefromSHOWSLAVESTATUS	repl_user=repl
repl_password	No	Local/App/Global	-(currentreplicationpassword)	repl_user=replpass
disable_log_bin	No	Local/App/Global	0	disable_log_bin=1
master_pid_file	No	Local/App/Global	""(emptystring)	master_pid_file=/var/lib/mysql/master1.pid
ssh_user	No	Local/App/Global	currentOSuser	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-sremote_dc1-sremote_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

LocalScope:Per-serverscopeparameters.Localscopeparametersshouldbesetunder[server_xxx]blockswithinapplicationconfigurationfile.

AppScope:Parametersforeach{master,slaves}pair.Theseparametersshouldbesetundera[server_default]blockwithinapplicationconfigurationfile.

GlobalScope:Parametersforall{master,slaves}pairs.Globalscopeparametersareusefulonlywhenyoumanagemultiple{master,slaves}pairsfromsinglemanagerserver.Theseparametersshouldbesetinaglobalconfigurationfile.

hostname

HostnameorIPaddressofthetargetMySQLserver.Thisparameterismandatory,andmustbeconfiguredunder[server_xxx]blockswithinapplicationconfigurationfile.

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

ip

IPaddressofthetargetMySQLserver.Defaultisgethostbyname($hostname).MHAManagerandMHANodeinternallyusesthisIPaddresstoconnectviaMySQLandSSH.Normallyyoudon'tneedtoconfigurethisparameterbecauseit'sautomaticallyresolvedfromhostnameparameter.

通常不需要配置

port

PortnumberofthetargetMySQLserver.Defaultis3306.MHAconnectstoMySQLserversbyusingIPaddressandport.

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

ssh_host

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

ssh_ip

(Supportedfrom0.53)IPaddressofthetargetMySQLserverthatisusedviaSSH.Defaultisgethostbyname($ssh_host).通常不用配置

ssh_port

(Supportedfrom0.53)PortnumberofthetargetMySQLserverusedviaSSH.Defaultis22.

ssh_connection_timeout

(Supportedfrom0.54)Defaultis5seconds.Beforeaddingthisparametertimeoutwashardcoded.

ssh_options

(Supportedfrom0.53)AdditionalSSHcommandlineoptions.

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

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

master_pid_file

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

ssh_user

默认是当前登陆manager的OS的用户，需要拥有读取mysqlbinlog和relaylog的权限

remote_workdir

每一个MHAnode节点产生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

IfMySQLcommandlineutilitiesareinstalledunderanon-standarddirectory,usethisoptiontosetthedirectory.

client_libdir

IfMySQLlibrariesareinstalledunderanon-standarddirectory,usethisoptiontosetthedirectory.

manager_log

Manager日志的全路径名称，若未设置，默认输出到STDOUT/STDERR；
如果手动故障切换时，MHA则忽略参数设置，而直接输出到STDOUT/STDERR。

FullpathfilenamethatMHAManagergenerateslogs.Ifnotset,MHAManagerprintstoSTDOUT/STDERR.Whenexecutingmanualfailover(interactivefailover),MHAManagerignoresmanager_logsettingandalwaysprintstoSTDOUT/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

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

ping_type

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

secondary_check_script

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

secondary_check_script=masterha_secondary_check-sremote_host1-sremote_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=(SSHusernameoftheremotehosts.ssh_userparametervaluewillbepassed)

--master_host=(master'shostname)

--master_ip=(master'sipaddress)

--master_port=(master'sportnumber)

注意该脚本需要依赖于IO::Socket::INETPerl包，Perlv5.6.0中默认已经包括。而该脚本允许连接任何一个远程服务器，所以需要配置SSHpublickey。并且，该脚本尝试建立远程服务器到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

MHAManager需要调用3次该脚本，第一次是在启动监控master之前(检查脚本是否可用)，，第二次是在调用shutdown_script脚本之前，而第三次是在新的Master应用完所有的
relaylogs之后。MHAManager会传递如下参数(这些参数不需要你自己配置)：

Checkingphase

--command=status

--ssh_user=(currentmaster'ssshusername)

--orig_master_host=(currentmaster'shostname)

--orig_master_ip=(currentmaster'sipaddress)

--orig_master_port=(currentmaster'sportnumber)

Currentmastershutdownphase

--command=stoporstopssh

--ssh_user=(deadmaster'ssshusername,ifreachableviassh)

--orig_master_host=(current(dead)master'shostname)

--orig_master_ip=(current(dead)master'sipaddress)

--orig_master_port=(current(dead)master'sportnumber)

Newmasteractivationphase

--command=start

--ssh_user=(newmaster'ssshusername)

--orig_master_host=(deadmaster'shostname)

--orig_master_ip=(deadmaster'sipaddress)

--orig_master_port=(deadmaster'sportnumber)

--new_master_host=(newmaster'shostname)

--new_master_ip=(newmaster'sipaddress)

--new_master_port(newmaster'sportnumber)

--new_master_user=(newmaster'suser)

--new_master_password(newmaster'spassword)

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

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

master_ip_online_change_script

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

Currentmasterwritefreezingphase

--command=stoporstopssh

--orig_master_host=(currentmaster'shostname)

--orig_master_ip=(currentmaster'sipaddress)

--orig_master_port=(currentmaster'sportnumber)

--orig_master_user=(currentmaster'suser)

--orig_master_password=(currentmaster'spassword)

--orig_master_ssh_user=(from0.56,currentmaster'ssshuser)

--orig_master_is_new_slave=(from0.56,notifyingwhethertheorigmasterwillbenewslaveornot)

Newmastergrantingwritephase

--command=start

--orig_master_host=(origmaster'shostname)

--orig_master_ip=(origmaster'sipaddress)

--orig_master_port=(origmaster'sportnumber)

--new_master_host=(newmaster'shostname)

--new_master_ip=(newmaster'sipaddress)

--new_master_port(newmaster'sportnumber)

--new_master_user=(newmaster'suser)

--new_master_password=(newmaster'spassword)

--new_master_ssh_user=(from0.56,newmaster'ssshuser)

shutdown_script

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

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

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

--command=stopssh

--ssh_user=(sshusernamesothatyoucanconnecttothemaster)

--host=(master'shostname)

--ip=(master'sipaddress)

--port=(master'sportnumber)

--pid_file=(master'spidfile)

IfthemasterisnotreachableviaSSH,MHAManagerpassesthefollowingarguments.

--command=stop

--host=(master'shostname)

--ip=(master'sipaddress)

该脚本以如下方式运行。如果--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'shostname)

--ip=(master'sipaddress)

report_script

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

--orig_master_host=(deadmaster'shostname)

--new_master_host=(newmaster'shostname)

--new_slave_hosts=(newslaves'hostnames,delimitedbycommas)

--subject=(mailsubject)

--body=(body)

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

Defaultparameterisempty,soMHAManagerdoesnotinvokeanythingbydefault./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不对其做任何事。

Commandreference

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

masterha_manager:开启MHAManager

#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)isrunning(0:PING_OK),master:host1
$echo$?
0

StatusCode(Exitcode)	StatusString	Description
0	PING_OK	MasterisrunningandMHAManagerismonitoring.Masterstateisalive.
1	---	Unexpectederrorhappened.Forexample,configfiledoesnotexist.Ifthiserrorhappens,checkargumentsarevalidornot.
2	NOT_RUNNING	MHAManagerisnotrunning.Masterstateisunknown.
3	PARTIALLY_RUNNING	MHAManagermainprocessisnotrunning,butchildprocessesarerunning.Thisshouldnothappenandshouldbeinvestigated.Masterstateisunknown.
10	INITIALIZING_MONITOR	MHAManagerisjustafterstartupandinitializing.Waitforawhileandseehowthestatuschanges.Masterstateisunknown.
20	PING_FAILING	MHAManagerdetectspingtomasterisfailing.Masterstateismaybedown.
21	PING_FAILED	MHAManagerdetectseithera)pingtomasterfailedthreetimes,b)preparingforstartingmasterfailover.Masterstateismaybedown.
30	RETRYING_MONITOR	MHAManagerinternalhealthcheckprogramdetectedthatmasterwasnotreachablefrommanager,butafterdoublecheckMHAManagerverifiedthemasterisalive,andcurrentlywaitingforretry.Masterstateisverylikelyalive.
31	CONFIG_ERROR	TherearesomeconfigurationproblemsandMHAManagercan'tmonitorthetargetmaster.Checkalogfilefordetail.Masterstateisunknown.
32	TIMESTAMP_OLD	MHAManagerdetectsthatpingtomasterisokbutstatusfileisnotupdatedforalongtime.CheckwhetherMHAManageritselfhangsornot.Masterstateisunknown.
50	FAILOVER_RUNNING	MHAManagerconfirmsthatmasterisdownandrunningfailover.Masterstateisdead.
51	FAILOVER_ERROR	MHAManagerconfirmsthatmasterisdownandrunningfailover,butfailedduringfailover.Masterstateisdead.

masterha_check_repl：检查复制健康状态

manager_host$masterha_check_repl--conf=/etc/app1.cnf
...
MySQLReplicationHealthisOK.

masterha_stop：停止MHAmanager运行

manager_host$masterha_stop--conf=/etc/app1.cnf
Stoppedapp1successfully.

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

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

Thenthefollowinglineswillbeaddedtotheconffile.

[server_db101]
hostname=db101

Youcanaddseveralparametersintheconfigfilebypassing--paramparameters,separatedbysemi-colon(;).

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

Thefollowinglineswillbeaddedtotheconffile.

[server100]
hostname=db101
no_master=1
ignore_fail=1

Youcanalsoremovespecifiedblock.Thebelowcommandwillremovetheetireblockserver100.

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

masterha_conf_hosttakesbelowarguments

master_check_ssh:ssh认证检查

#masterha_check_ssh--conf=/etc/app1.cnf

SatMay1414:42:192011-[warn]Globalconfigurationfile/etc/masterha_default.cnfnotfound.Skipping.
SatMay1414:42:192011-[info]Readingapplicationdefaultconfigurationsfrom/etc/app1.cnf..
SatMay1414:42:192011-[info]Readingserverconfigurationsfrom/etc/app1.cnf..
SatMay1414:42:192011-[info]StartingSSHconnectiontests..
SatMay1414:42:192011-[debug]ConnectingviaSSHfromroot@host1(192.168.0.1)toroot@host2(192.168.0.2)..
SatMay1414:42:202011-[debug]ok.
SatMay1414:42:202011-[debug]ConnectingviaSSHfromroot@host1(192.168.0.1)toroot@host3(192.168.0.3)..
SatMay1414:42:202011-[debug]ok.
SatMay1414:42:212011-[debug]ConnectingviaSSHfromroot@host2(192.168.0.2)toroot@host1(192.168.0.1)..
SatMay1414:42:212011-[debug]ok.
SatMay1414:42:212011-[debug]ConnectingviaSSHfromroot@host2(192.168.0.2)toroot@host3(192.168.0.3)..
SatMay1414:42:212011-[debug]ok.
SatMay1414:42:222011-[debug]ConnectingviaSSHfromroot@host3(192.168.0.3)toroot@host1(192.168.0.1)..
SatMay1414:42:222011-[debug]ok.
SatMay1414:42:222011-[debug]ConnectingviaSSHfromroot@host3(192.168.0.3)toroot@host2(192.168.0.2)..
SatMay1414:42:222011-[debug]ok.
SatMay1414:42:222011-[info]AllSSHconnectiontestspassedsuccessfully.

purge_relay_logsscript：删除旧的relaylog

[app@slave_host1]$cat/etc/cron.d/purge_relay_logs
#purgerelaylogsat5am
05***app/usr/bin/purge_relay_logs--user=root--password=PASSWORD--disable_relay_log_purge>>/var/log/masterha/purge_relay_logs.log2>&1

Monitoringmultipleapplications

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

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

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

Usingwithclusteringsoftware

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

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

#/etc/ha.d/haresourcesonhost2
host2failover_startIPaddr::192.168.0.3

#failover_startscriptexample

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

stop)
#donothing

#Applicationconfigurationfile:

[server1]
hostname=host1
candidate_master=1

[server2]
hostname=host2
candidate_master=1

[server3]
hostname=host3
no_master=1

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

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航