该文档介绍了基于 MHA (Master High Availability) 的 MySQL 高可用方案，详细讲解了 MHA 的特性、切换过程、构建步骤及所需条件。MHA 通过自动化主服务器故障转移，能够快速将从服务器誉为主服务器，确保数据的一致性。文档还包含了常用操作命令和注意事项，旨在帮助用户有效部署和管理高可用的 MySQL 环境。

1. 基于 MHA 的 MySQL 高可用方案
DBA Team
二零一三年三月
文档修订版历史
日期 版本 说明 作者 审阅
2013-03-21 刘浩
2013-03-24 V1.0 邱伟胜
1

2. 目录
目录
2.MHA 的特性....................................................................................................................................3
3.MHA 所需条件................................................................................................................................4
4.MHA 切换过程................................................................................................................................6
4.1 故障转移过程...................................................................................................................6
4.2 在线切换过程...................................................................................................................8
4.3 recover 机制....................................................................................................................8
4.4 Typical timeline.........................................................................................................10
5. MHA 构建步骤............................................................................................................................10
5.1 第一步：master slave................................................................................................. 10
5.2 第二步：mha rpm 安装.................................................................................................. 10
5.3 第三步：ssh 互信..........................................................................................................11
5.4 第四步：MHA 配置..........................................................................................................11
5.5 第五步：手工添加 VIP.................................................................................................. 13
6. 常用操作命令...........................................................................................................................13
6.1 检查 MHA 的配置.............................................................................................................13
6.2 检查 ssh 的配置.............................................................................................................14
6.3 检查 MHA manager 的状态.............................................................................................14
6.4 停止 MHA manager..........................................................................................................14
6.5 启动 MHA manager..........................................................................................................14
6.6 手工 failover................................................................................................................15
6.7 在线切换.........................................................................................................................15
7. 注意事项...................................................................................................................................16
7.1 修复 crash master........................................................................................................... 16
7.2 DBA 专有备用 slave.........................................................................................................17
7.3 mysqlbinlog 工具的问题............................................................................................. 17
7.4 VIP 问题..........................................................................................................................18
7.5 发邮件与发短信..............................................................................................................18
7.6 常用的命令合集.............................................................................................................18
8. 参考资料...................................................................................................................................19
2

3. 1.MHA 介绍
MHA 自动化主服务器故障转移，快速将从服务器晋级为主服务器 (通常在
10-30s)，而不影响复制的一致性，不需要花钱买更多的新服务器，不会有性能
损耗，容易安装，不必更改现有的部署环境，适用于任何存储引擎。
MHA 提供在线主服务器切换，改变先正运行的主服务器到另外一台上，这个
过程只需 0.5-2s 的时间，这个时间内数据无法写入。
MHA Manager 通过 ssh 连接 mysql slave 服务器。
虽然 MHA 试图从挡掉的主服务器上保存二进制日志，并不是总是可行的。 例
如，如果主服务器硬件故障或无法通过 ssh 访问，MHA 没法保存二进制日志，只
进行故障转移而丢失最新数据。
使用半同步复制，可以大大降低数据丢失的风险。MHA 可以与半同步复制结
合起来。如果只有一个 slave 已经收到了最新的二进制日志，MHA 可以将最新的
二进制日志应用于其他所有的 slave 服务器上，因此他们彼此保持一致性。
2.MHA 的特性
1.主服务器的自动监控和故障转移
MHA 监控复制架构的主服务器，一旦检测到主服务器故障，就会自动进行故障转
移。即使有些从服务器没有收到最新的 relay log，MHA 自动从最新的从服务器
上识别差异的 relay log 并把这些日志应用到其他从服务器上，因此所有的从服
务器保持一致性了。 MHA 通常在几秒内完成故障转移，9-12 秒可以检测出主服务
器故障， 7-10 秒内关闭故障的主服务器以避免脑裂，几秒中内应用差异的 relay
log 到新的主服务器上，整个过程可以在 10-30s 内完成。还可以设置优先级指
定其中的一台 slave 作为 master 的候选人。由于 MHA 在 slaves 之间修复一致性，
因此可以将任何 slave 变成新的 master，而不会发生一致性的问题，从而导致
复制失败。
2.交互式主服务器故障转移
可以只使用 MHA 的故障转移，而不用于监控主服务器，当主服务器故障时，人工
调用 MHA 来进行故障故障。
3.非交互式的主故障转移
不监控主服务器，但自动实现故障转移。这种特征适用于已经使用其他软件来监
3

4. 控主服务器状态，比如 heartbeat 来检测主服务器故障和虚拟 IP 地址接管，可
以使用 MHA 来实现故障转移和 slave 服务器晋级为 master 服务器。
4.在线切换主服务器
在许多情况下，需要将现有的主服务器迁移到另外一台服务器上。比如主服务器
硬件故障，RAID 控制卡需要重建，将主服务器移到性能更好的服务器上等等。
维护主服务器引起性能下降，导致停机时间至少无法写入数据。另外，阻塞或杀
掉当前运行的会话会导致主主之间数据不一致的问题发生。MHA 提供快速切换和
优雅的阻塞写入，这个切换过程只需要 0.5-2s 的时间，这段时间内数据是无法
写入的。在很多情况下，0.5-2s 的阻塞写入是可以接受的。因此切换主服务器
不需要计划分配维护时间窗口。
3.MHA 所需条件
1.SSH 公钥验证
MHA 管理节点通过 ssh 连接 mysql 服务器， 节点通过 scp 发送最新的 relay log
MHA
到其他 slaves 服务器上。为了使这些过程自动化，使用 SSH 公钥验证密码。
2.操作系统
MHA 目前只支持 Linux 系统
3.单台可写主服务器和多台从服务器或只读主服务器
当主服务器当掉时，MHA 修复从服务器之间数据一致性。MHA 试图从当掉的主服
务器上保存尚未发送的二进制日志文件并应用于所有从服务器。 如果只有一个从
服务器，就不需在意从服务器之间一致性问题。即使只有一个从服务器，MHA 也
会从当掉的主服务器上保存尚未发送的二进制日志事件只要能通过 ssh 访问到
主服务器。使用半同步复制可以解决当主服务器当掉后，无法 ssh 到主服务器上
保存尚未发送的二进制日志事件。
从 MHA Manager0.52 版本开始，支持多主复制结构。只允许其中一台主服务器可
写，其他主服务器必须设置 read-only=1。默认情况下，被管理服务器应该是两
层复制结构。
4.在三层或三层以上复制情况下
默认情况下，MHA 不支持三层或三层以上的复制结构。如 master1—master2—
-slave3。MHA 故障转移和恢复是直接从从服务器中选择一台作为当前的主主服
4

5. 务器。MHA 可以管理 master1 和 master2，当 master1 当掉后，将 master2 作为
主，MHA 不会监控和恢复 slave3 因为 slave3 是从不同的主服务器上(master2)
复制的。为了使 MHA 工作在这种架构下，需要做如下设置：
只在 MHA 配置文件中配置 master1 和 master2
在 MHA 配置文件中所有主机上设置 multi_tier_slave=1
在这种情况下，MHA 只管理主主服务器和二层的从服务器，在故障转移过程中，
三层从服务器仍然可以正常工作的。
5.mysql 版本 5.0 或更高
MHA 支持 mysql5.0 或以上版本。因为从 mysql5.0 版本起二进制日志格式(binlog
v4 格式)改变了。当 MHA 解析二进制日志来确定目标中继日志位置，是使用 v4
格式的。MySQL 版本不得低于 5.0.60。
6.mysqlbinlog 版本 3.3 或更高
MHA 在目标从服务器上应用二进制事件使用 mysqlbinlog。如果主服务器使用基
于行格式复制，基于行格式的事件写入到二进制文件中，这种二进制日志格式的
文件只能被 MySQL5.1 或更高版本的 mysqlbinlog 解析。MySQL5.0.60 以下版本
中的 mysqlbinlog 不支持基于行格式的。
7.候选主服务器 log-bin 必须开启
如果当前的从服务器没有开启 log-bin，那么将不可能成为主服务器。MHA 管理
节点会检测是否有配置 log-bin。如果当前所有从服务器都没有设置 log-bin，
那么 MHA 不进行故障转移。
8.所有服务器上的二进制日志和中继日志过滤规则必须相同
binlog-do-db 和 replicate-ignore-db 设置必须相同。 在启动时候会检测过
MHA
滤规则，如果过滤规则不同，MHA 不启动监控和故障转移。
9.候选主服务器上的复制用户必须存在
当故障转移后，所有从服务器上将执行 change master to 命令。
10.保留中继日志和定期清理
默认情况下，从服务器上的中继日志在 SQL 线程执行完后会被自动删除的。但是
这些中继日志在恢复其他从服务器时候可能会被用到， 因此需要禁用中继日志的
5

6. 自动清除和定期清除旧的中继日志。 定期清除中继日志需要考虑到复制延时的问
题。在 ext3 文件系统下，删除大的文件需要一定的时间，会导致严重的复制延
时。为了避免复制延时，暂时为中继日志创建硬链接。
MHA 节点包含 pure_relay_logs 命令工具，它可以为中继日志创建硬链接，执行
SET GLOBAL relay_log_purge=1，等待几秒中以便 SQL 线程切换到新的中继日志，
再执行 SET GLOBAL relay_log_purge=0。
pure_relay_logs 参数如下所示：
–user mysql 用户名
–password mysql 密码
–host mysql 服务器地址
–port 端口号
–workdir 创建和删除中继日志硬链接目录。成功执行脚本后，硬链接的中继日
志文件将被删除。默认目录是/var/tmp。
–disable_relay_log_purge 如果 relay_log_purge=1，purge_relay_logs 脚
本 将 退 出 不 做 任 何 事 情 。 设 置 – disable_relay_log_purge 参 数 ，
purge_relay_logs 脚本不会退去，且自动设置 relay_log_purge=0。
定期执行 purge_relay_logs 脚本：
Purge_relay_logs 脚本删除中继日志不会阻塞 SQL 线程。因此在每台从服务器
上设置计划任务定期清除中继日志。
00 00 * * * /usr/bin/purge_relay_logs –user=root –password=passwd
–disable_relay_log_purge >> /data/masterha/log/purge_relay_logs.log
2>&1
最好在每台从服务器上不同时间点执行计划任务。
11. LOAD DATA INFILE 不要使用基于语句型的二进制日志
如果使用非事务性存储引擎，在执行完 LOAD DATA INFILE 基于语句型二进制日
志时，主服务器当掉，MHA 可能不会产生差异的中继日志事件。使用 LOAD DATA
INFILE 基于语句型二进制日志有一些已知问题， mysql5.1 版本中不建议使用，
在
同时还会引起严重的复制延时，因此没有理由使用它。
6

7. 4.MHA 切换过程
4.1 故障转移过程
大概的过程：
监控主服务器
检测主服务器当掉
再次检测从服务器配置
关闭当掉的主服务器(可选)
选举一个新的主服务器
激活新的主服务器
恢复其余的从服务器到新的 master
告警，发送 failover 报告，停止监控
7

8. 4.2 在线切换过程
大概的过程：
检测复制设置和确定当前主服务器
确定新的主服务器
阻塞写入到当前主服务器
等待所有从服务器赶上复制
授予写入到新的主服务器
重新设置从服务器
4.3 recover 机制
Steps for recovery:
8

9. Recovery procedure:
9

10. 4.4 Typical timeline
• Usually no more than 10-30 seconds
• 0-10s: Master failover detected in around 10 seconds
• (optional) 10-20s: 10 seconds to power off master
• 10-20s: apply differential relay logs to new master
• Practice: 4s @ DeNA, usually less than 10s
5. MHA 构建步骤
以下以一主三从为例，如：
10.0.0.11 slave 节点 mha node
10.0.0.74 slave 节点 mha Manager 节点
10.0.0.75 slave 节点 mha node
10.0.0.13 master 节点 mha node
5.1 第一步：master slave
搭建 mysql master slave，为 1 一个 master，3 个 slave 架构
注意 slave 节点要设置:
read_only=1
relay_log_purge=off
log_bin= log_bin
另外，需要授予其他 node 对应的权限：
grant all privileges on *.* to 'root'@'db-11' identified by '111111';
grant all privileges on *.* to 'root'@'db-13' identified by '111111';
grant all privileges on *.* to 'root'@'db-75' identified by '111111';
grant all privileges on *.* to 'root'@'db-74' identified by '111111';
5.2 第二步：mha rpm 安装
所有节点安装 mha node
yum install perl-DBD-MySQL
rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
10.0.0.74 节 点 mha Manager 节 点 安 装 mha manager, 以 下 rpm 可 以 在
http://pkgs.repoforge.org/上去下载
yum install perl-DBD-MySQL
10

11. yum install perl-Config-Tiny
yum install perl-Log-Dispatch
yum install perl-Parallel-ForkManager
rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
rpm -ivh mha4mysql-manager-X.Y-0.noarch.rpm
5.3 第三步：ssh 互信
第三步：ssh
安装完成后，所有节点配置 root（因为涉及到 ifconfig vip 的执行，需要 root
或者 sudo 权限）用户下 ssh 互信，注意这里不能禁止 password 登陆，否则会
出现错误：
mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa
ssh-keygen -t dsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh db-11 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db-11 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh db-13 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db-13 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh db-75 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh db-75 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
scp ~/.ssh/authorized_keys db-11:~/.ssh/authorized_keys
scp ~/.ssh/authorized_keys db-13:~/.ssh/authorized_keys
scp ~/.ssh/authorized_keys db-75:~/.ssh/authorized_keys
5.4 第四步：MHA 配置
第四步：MHA
1）、几个概念：
Application：是指 master-slave 对， 一个 manager 可以管理多个 Applications
appxx.cnf 和默认 masterha_default.cnf：全局范围参数配置和应用参数配置，
全局参数配置是对该 MHA manager 管理下的所有 Applications 生效，并从默认
的全局配置文件/etc/masterha_default.cnf 读取；Application 范围参数配置
只对一个 Applicattion 生效，配置文件需要独立创建，如/etc/app1.cnf。
manager 管 理 的 多 个 application 可 以 分 别 设 置 ， 如 :/etc/app2.cnf
/etc/app3.cnf 等；
11

12. Application 范围的参数配置，必须包含在[server default]定义块中， Node
而
本地的配置必须包含在[server 1...N]块中。多个 Application 的相关名称必须
唯一；
如果同时配置了全局范围参数和 Application 范围参数，最终以 Application
范围参数生效，因此参数分 Local/App/Global 三种范围
2）、配置 MHA cnf
配 置 文 件 中 各 参 数 的 含 义 具 体 可 以 参 考 以 下 的 网 址
（http://code.google.com/p/mysql-master-ha/wiki/Parameters）。注意配置
mha 配置文件时需要将 check_repl_delay=0 加到参数文件中，如果候选 master
有延迟的话，relay 日志超过 100m 会 failover 切换不能成功。加上此参数后会
忽略延迟日志大小
[server default]
manager_workdir=/masterha/app1
manager_log=/masterha/app1/manager.log
# mysql user and password
user=root
password=111111
ssh_user=root
repl_user=repl
repl_password=repl
ping_interval=1
shutdown_script=""
master_ip_online_change_script="/masterha/app1/master_ip_online_chang
e.pl"
report_script="/masterha/app1/send_report.pl"
master_ip_failover_script="/masterha/app1/master_ip_failover.pl"
[server1]
hostname=10.0.0.13
master_binlog_dir=/data/mysql/arch
candidate_master=1 ---表示候选 master 候选 master，根据 servern 来判断
候选优先级
check_repl_delay=0 ---当 slave 有延迟的时候， 如果没有这个参数是切换不
过去的
[server2]
hostname=10.0.0.74
master_binlog_dir=/data/mysql/arch
candidate_master=1
check_repl_delay=0
[server3]
hostname=10.0.0.11
12

13. master_binlog_dir=/data/mysql/arch
no_master=1
ignore_fail=1 ----如果这个节点挂了，mha 将不可用，加上这个参数，
slave 挂了一样可以用
[server4]
hostname=10.0.0.75
master_binlog_dir=/data/mysql/arch
ignore_fail=1
no_master=1
5.5 第五步：手工添加 VIP
因为该方案没有引入单独的 VIP 管理软件，一开始 VIP 并不存在，故在主服务器
提供服务的时候需要手工执行类似以下的脚本，以后通过 MHA failover 或者
online exchange 都会自动管理这个 VIP：
/sbin/ifconfig eth0:1 10.0.0.119/24
ifconfig -a
eth0 Link encap:Ethernet HWaddr F0:4D:A2:3C:C0:7D
inet addr:10.0.0.13 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::f24d:a2ff:fe3c:c07d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:59902267967 errors:0 dropped:0 overruns:0 frame:0
TX packets:61499897760 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14229951939009 (12.9 TiB) TX bytes:20909756586354 (19.0
TiB)
Interrupt:170 Memory:e6000000-e6012800
eth0:1 Link encap:Ethernet HWaddr F0:4D:A2:3C:C0:7D
inet addr:10.0.0.119 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:170 Memory:e6000000-e6012800
13

14. 6. 常用操作命令
6.1 检查 MHA 的配置
masterha_check_repl --conf=/etc/app1.cnf
检查 mha 的配置，如有错误根据错误提示进行修改，会有如下的信息：
........
Tue Mar 19 10:14:35 2013 - [info]
10.0.0.13 (current master)
+--10.0.0.74
+--10.0.0.11
+--10.0.0.75
..........
MySQL Replication Health is OK.
6.2 检查 ssh 的配置
masterha_check_ssh --conf=/etc/app1.cnf
MHA Manager internally connects to MySQL servers via SSH. MHA Node on the
latest slave also internally sends relay log files to other slaves via
SSH(scp). To make these procedures automated, it is generally recommended
to enable SSH public key authentication without pass-phrase. You can use
masterha_check_ssh command included in MHA Manager to check whether SSH
connections work properly.
6.3 检查 MHA manager 的状态
masterha_check_status --conf=/etc/app1.cnf
检查 mha 的运行状态，如下表明 mha 没有启动
app1 is stopped(2:NOT_RUNNING).
14

15. 6.4 停止 MHA manager
masterha_stop --conf=/etc/app1.cnf
可以通过上面命令停止 mha
6.5 启动 MHA manager
----------后台启动 mha
nohup masterha_manager --conf=/etc/app1.cnf < /dev/null >
/var/log/masterha/app1/app1.log 2>&1 &
----------后台启动 mha ，当有 slave 节点宕掉的情况是启动不了的，加上
-ignore_fail_on_start 即使有节点宕掉也能启动 mha
nohup masterha_manager --conf=/etc/app1.cnf --ignore_fail_on_start <
/dev/null > /var/log/masterha/app1/app1.log 2>&1 &
--------检查 mha 状态，并且告诉你 master 节点为 10.0.0.74
masterha_check_status --conf=/etc/app1.cnf
app1 (pid:16372) is running(0:PING_OK), master:10.0.0.74
注意每次 failover 切换后会在管理目录生成文件 app1.failover.complete ，
下次在切换的时候会发现有这个文件导致切换不成功，需要手动清理掉。
rm -rf /masterha/app1/app1.failover.complete
也可以加上参数--ignore_last_failover
6.6 手工 failover
手工 failover，场景，master 死掉，但是 masterha_manager 没有开启，可以通
过手工 failover：
masterha_master_switch --conf=/etc/app1.cnf
--dead_master_host=10.0.0.74 --master_state=dead
--new_master_host=10.0.0.13 --ignore_last_failover
会有如下提示信息：
From:
10.0.0.74 (current master)
+--10.0.0.13
+--10.0.0.11
15

16. +--10.0.0.75
To:
10.0.0.13 (new master)
+--10.0.0.11
+--10.0.0.75
6.7 在线切换
masterha_master_switch 命令维护操作时手动在线切换命令各参数解释网址
http://code.google.com/p/mysql-master-ha/wiki/masterha_master_switch
具体命令如下：
masterha_master_switch --conf=/etc/app1.cnf --master_state=alive
--new_master_host=10.0.0.74 --orig_master_is_new_slave
或者
masterha_master_switch --conf=/etc/app1.cnf --master_state=alive
--new_master_host=10.0.0.74 --orig_master_is_new_slave
--running_updates_limit=10000
--orig_master_is_new_slave 切换时加上此参数是将原 master 变为 slave 节
点，如果不加此参数，原来的 master 将不启动
--running_updates_limit=10000 切换时候选 master 如果有延迟的话，mha 切
换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为 s） ，但是
切换的时间长短是由 recover 时 relay 日志的大小决定
手动在线切换 mha，切换时需要将在运行的 mha 停掉后才能切换。
在备库先执行 DDL，一般先 stop slave，一般不记录 mysql 日志，可以通过 set
SQL_LOG_BIN = 0 实现。然后进行一次主备切换操作，再在原来的主库上执行 DDL。
这种方法适用于增减索引，如果是增加字段就需要额外注意。
可以通过如下命令停止 mha
masterha_stop --conf=/etc/app1.cnf
16

17. 7. 注意事项
7.1 修复 crash master
每次 failover 切换之后，原来的 master 可能就废弃掉了，如果还想用，服务器
文件完整的情况下，可以继续尝试 change master 运行，日志恢复的点可以在
mha 的 manager 日志中找到：
less manager.log
Tue Mar 19 17:31:18 2013 - [info] Starting recovery on
10.0.0.74(10.0.0.74:3306)..
Tue Mar 19 17:31:18 2013 - [info] This server has all relay logs. Waiting
all logs to be applied..
Tue Mar 19 17:31:18 2013 - [info] done.
Tue Mar 19 17:31:18 2013 - [info] All relay logs were successfully
applied.
Tue Mar 19 17:31:18 2013 - [info] Getting new master's binlog name and
position..
Tue Mar 19 17:31:18 2013 - [info] mysql-bin.000008:3921
Tue Mar 19 17:31:18 2013 - [info] All other slaves should start
replication from here. Statement should be: CHANGE MASTER TO
MASTER_HOST='10.0.0.74', MASTER_PORT=3306, MASTER_LOG_FILE='mysql
-bin.000008', MASTER_LOG_POS=3921, MASTER_USER='repl',
MASTER_PASSWORD='xxx';
7.2 DBA 专有备用 slave
对于一个 mysql 集群，如果有 DBA 专有的备用 slave，自动监控的节点里可以不
包括这个节点，如下面的集群里，可以只自动监控 10.0.0.74,10.0.0.13 和
10.0.0.11，这样在 10.0.0.75 上的备份、分析等操作不会影响整个集群，但是
维护操作是要把整个集群考虑在内，这个可以通过两个配置文件实现，
/etc/app1.cnf 和 /etc/app1_monitor.cnf（这个里没有 10.0.0.75）
/etc/app1.cnf 里的结构：
10.0.0.74 (current master)
+--10.0.0.13
+--10.0.0.11
+--10.0.0.75
/etc/app1_monitor.cnf 里的结构：
10.0.0.74 (current master)
+--10.0.0.13
17

18. +--10.0.0.11
7.3 mysqlbinlog 工具的问题
MHA uses mysqlbinlog for applying binlog events to target slaves. If the
master uses row based format, row based events are written in the binary
log. Such binary logs can be parsed by mysqlbinlog in MySQL 5.1 or higher
only because mysqlbinlog in MySQL 5.0 does not support row based format.
mysqlbinlog (and mysql) version can be checked as below.
mysqlbinlog 需要位于 ssh 用户可以访问的地方，可通过类似软连接来实现
[root@oel58 ~]# chmod +x mysqlbinlog
[root@oel58 ~]#
[root@oel58 ~]# ln -s /root/mysqlbinlog /usr/bin/mysqlbinlog
[root@oel58 ~]#
[root@oel58 ~]# which mysqlbinlog
/usr/bin/mysqlbinlog
[root@oel58 ~]# mysqlbinlog -V
mysqlbinlog Ver 3.3 for Linux at i686
mysqlbinlog version should be 3.3 or higher if it's included in MySQL 5.1.
MHA internally checks both MySQL and mysqlbinlog version on all slaves.
If mysqlbinlog version is 3.2 or earlier and if MySQL version is 5.1 or
higher, MHA stops with errors before starting monitoring.
7.4 VIP 问题
如 果 调 整 了 虚 拟 IP ， 请 修 改 master_ip_online_change.pl 和
master_ip_failover.pl 里 的 下 列 代 码 ： my $vip = '10.0.0.119/24'; #
Virtual IP
同时注意对应的 ssh 用户要有执行权限。
7.5 发邮件与发短信
需要安装 Oracle dbd，所以需要 oracle 的 lib；
配置对应的 Tns；
增加或者删除下面的代码组：
$sql1 = "insert into
edm_user.tb_queue(ID,PHONE,MSG,STATUS,SENDLEVEL,svrtype,INSERTTIME)
values(edm_user.SEQ_QUE.NEXTVAL,'13800000000','$subject','',1,'11',sy
18

19. sdate)";
$sth1 = $dbh->prepare($sql1) ;
$sth1->execute();
下面为发邮件的实现，其中 sendEmail 为一个 perl 实现的发邮件的组件
my $semailstr=`/usr/bin/sendEmail -s mail.qwsh.com -f dba@qwsh.com -t
dba@qwsh.com -u $subject -m "++++Failover_Report++++" -a
"/tmp/mha_send_report_tmplog.log"`;
以上的实现位于 send_report.pl，同时注意对应的 ssh 用户要有执行权限。
7.6 常用的命令合集
/sbin/ifconfig eth0:1 10.0.0.119/24
nohup masterha_manager --conf=/etc/app1.cnf --ignore_fail_on_start <
/dev/null > /var/log/masterha/app1/app1.log 2>&1 &
nohup masterha_manager --conf=/etc/app1.cnf < /dev/null >
/var/log/masterha/app1/app1.log 2>&1 &
masterha_check_repl --conf=/etc/app1.cnf
masterha_check_status --conf=/etc/app1.cnf
masterha_master_switch --conf=/etc/app1.cnf --master_state=alive
--new_master_host=10.0.0.74 --orig_master_is_new_slave
masterha_master_switch --conf=/etc/app1.cnf
--dead_master_host=10.0.0.74 --master_state=dead
--new_master_host=10.0.0.13 --ignore_last_failover
CHANGE MASTER TO MASTER_HOST='10.0.0.13', MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000033', MASTER_LOG_POS=107,
MASTER_USER='repl', MASTER_PASSWORD='repl';
8. 参考资料
1 Automated, Non-Stop MySQL Operations and Failover(Yoshinori Matsunobu)
2 MHA: Getting Started & Moving Past Quirks
3 https://code.google.com/p/mysql-master-ha/
4 http://space.itpub.net/758322/viewspace-721183
5 一些网上的资料
19