mha

简介：https://code.google.com/p/mysql-master-ha/
架构：https://code.google.com/p/mysql-master-ha/wiki/Architecture

mha的主要目标就是master故障的自动转移,通常是在10s~30s内的宕机时间范围内，不需要改变当前的部署结构，同时提供在线的switch，通常在0.5-2s的时间内不允许写
自动master监控及转移（主要使用）
mha可以监控master存活并在检测失败后自动进行master故障转移，即使一些slave没有收到最近的relay log事件，mha自动在最近的slave中标识不同的relay日志事件，并应用事件到别的slave上，以便使所有的slave处于一致的状态，mha在9~12s内检测master失败，7-10秒来关闭master的机器来避免脑裂，几秒的时间来应用增量relay log到新master，所以总的宕机时间通常是10-30秒，此外，你可以在配置文件中定义新的master，因为mha在slave之间修复不一致的问题，你可以提升任意的slave成为master，不一致的问题将不会发生。
交互（手工）master 故障转移
使用mha做故障转移，不去监控master
非交互master故障转移
非交互master故障转移，不去监控master，但是自动的故障转移，
在线切换master到别的机器（主要使用）
很多情况下，需要迁移一个存在的master到一个不同的机器，需要kill当前正在运行的语句，否则可能导致数据不一致的问题，mha提供一个方法来实现，可以在0。5~2s的时间内阻塞写完成切换，这个时间对很多应用来说是可以接受的。所以很方便。
mha需要的资源很少，所以一个manager 可以管理100+的master-slave
mha允许你自己定义管理master的ip，通常的做法是在manager的配置文件中使用master_ip_failover_script参数
建议是使用半同步复制的模式，这样保证数据不会丢失
Using Semi-Synchronous replication greatly reduces the risk of such data loss. MHA works with Semi-Synchronous replication, since it is based on MySQL replication mechanism. It is worth to note that if only one of the slaves have received the latest binary log events, MHA can apply the events to all other slaves so they can be consistent each other.
安装部署：http://blog.csdn.net/aoerqileng/article/details/52712688
masterha_manager的具体参数：https://code.google.com/p/mysql-master-ha/wiki/masterha_manager

(1)、 Manager工具:

• masterha_check_ssh : 检查MHA的SSH配置。

• masterha_check_repl : 检查MySQL复制。

• masterha_manager : master监控及在master宕掉后自动运行故障转移

• masterha_check_status : 检测当前MHA运行状态。

• masterha_master_monitor : 监测master是否宕机。

• masterha_master_switch : 控制故障转移(手动或非交互式master故障转移或在线master转换)。

• masterha_conf_host : 添加或删除配置的server信息。

(2)、 Node工具(这些工具通常由MHAManager的脚本触发,无需人手操作)。

• save_binary_logs : 保存和复制master的二进制日志。

• apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。

• filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。

• purge_relay_logs : 清除中继日志(不会阻塞SQL线程)。

master_manager是监控master状态并且自动的做故障转移，masterha_master_switch是做手工的failover

常用命令：
启动mha manager:
masterha_manager –global_conf=/etc/masterha_default.cnf –conf=/etc/conf/masterha/app1.cnf
手工failover
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是运行在交换模式下，如果要运行在非交互模式下，使用
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
在线切换的情况下，不必像自动故障转移那样关闭master的server，但是需要确保master上不会执行写操作，可以在master_ip_online_change_scripts脚本中设置，可以通过参数–orig_master_is_new_slave设置master成为新master的slave，默认情况下不是的。
在线切换需要满足一些条件才能执行：
IO threads on all slaves are running
SQL threads on all slaves are running
Seconds_Behind_Master on all slaves are less or equal than –running_updates_limit seconds
On master, none of update queries take more than –running_updates_limit seconds in the show processlist output

参数–running_updates_limit_seconds可以指定，默认是1s
参数–remove_orig_master_conf控制是否在配置文件中删除原master信息
停止manager,不会停止mysql，只是停止监控
masterha_stop –conf=/etc/app1.cnf
配置文件信息自动生成
# masterha_conf_host –command=add –conf=/etc/conf/masterha/app1.cnf –hostname=db101 –block=server100 –params=”no_master=1;ignore_fail=1”
产生的配置文件信息如下：
[server100]
hostname=db101
no_master=1
ignore_fail=1
配置文件信息的删除
masterha_conf_host –command=delete –conf=/etc/conf/masterha/app1.cnf –block=server100

masterha_check_ssh –conf=/etc/masterha/app1.cnf –检查ssh配置,这个命令不需要全局配置文件，只需要app的配置文件
masterha_check_repl –conf=/etc/masterha/app1.cnf –检查复制情

在执行检测的时候遇到了下面的错误
Can’t exec “mysqlbinlog”: No such file or directory at /usr/share/perl5/vendor_perl/MHA/BinlogManager.pm line 106.
mysqlbinlog version command failed with rc 1:0, please verify PATH, LD_LIBRARY_PATH, and client options
at /usr/bin/apply_diff_relay_logs line 493
Fri Jul 1 02:37:41 2016 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln205] Slaves settings check failed!
Fri Jul 1 02:37:41 2016 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln413] Slave configuration failed.
Fri Jul 1 02:37:41 2016 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations. at /usr/bin/masterha_check_repl line 48
Fri Jul 1 02:37:41 2016 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Fri Jul 1 02:37:41 2016 - [info] Got exit code 1 (Not master dead).

MySQL Replication Health is NOT OK!
[root@ mysql_3307]# which mysqlbinlog
/usr/local/mysql/bin/mysqlbinlog
需要做软连接到/usr/bin目录下
[root@mysql_3307]# ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog

mysql命令也是一样处理
masterha_manager –conf=/etc/masterha/app1.cnf 启动
masterha_check_status –conf=/etc/masterha/app1.cnf 监控状态
masterha_stop –conf=/etc/masterha/app1.cnf 停止
masterha_check_repl –conf=/etc/masterha/app2.cnf –监控复制状态
mha的配置文件
[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
user=root
password=xxx
ssh_user=root
repl_user=xxx
repl_password=xxx
ping_interval=1
shutdown_script=””
master_ip_online_change_script=””
report_script=”“

[server1]
hostname=127.0.0.1
port=3307
candidate_master=1
master_binlog_dir=”/data/mysql_3307”

[server2]
hostname=127.0.0.1
port=3308
candidate_master=1
master_binlog_dir=”/data/mysql_3308”

[server3]
hostname=127.0.0.1
port=3309
candidate_master=1
master_binlog_dir=”/data/mysql_3309”
安装完mha后，在关闭3307后，是有自动切换3308作为主库，但是manager自动关闭了，3307在启动后，也是独立存在的，没有添加到主从结构中。
下面测试下手工的切换：
先停止manager,在停止主库，这样才能手工failover，3308是主库
命令如下
masterha_master_switch –master_state=dead –conf=/etc/masterha/app1.cnf –dead_master_host=127.0.0.1 –dead_master_ip=127.0.0.1 –dead_master_port=3308

—– Failover Report —–

app1: MySQL Master failover 127.0.0.1(127.0.0.1:3308) to 127.0.0.1(127.0.0.1:3307) succeeded

Master 127.0.0.1(127.0.0.1:3308) is down!

Check MHA Manager logs at aws_db_203079 for details.

Started manual(interactive) failover.
The latest slave 127.0.0.1(127.0.0.1:3307) has all relay logs for recovery.
Selected 127.0.0.1(127.0.0.1:3307) as a new master.
127.0.0.1(127.0.0.1:3307): OK: Applying all logs succeeded.
127.0.0.1(127.0.0.1:3309): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
127.0.0.1(127.0.0.1:3309): OK: Applying all logs succeeded. Slave started, replicating from 127.0.0.1(127.0.0.1:3307)
127.0.0.1(127.0.0.1:3307): Resetting slave info succeeded.
Master failover to 127.0.0.1(127.0.0.1:3307) completed successfully.

在切换后，3308已经关闭了的，但是信息还是在配置文件中，需要移除
可以设置–remove_dead_master_conf这个参数自动删除
另外，通常情况下主从是在不同的机器下的，所以如果使用了keepalive vip漂移还需要在脚本中切换下vip，这样就可以正常对外提供服务了

网络摘抄的例子，来自：http://www.linuxidc.com/Linux/2015-04/116493.htm

注意点：
1在masterha_secondary_check -s 中如果指定的s的地址需要与master的地址ssh互通，否则在master宕掉后，检测的时候会认为是出现了网络的故障，导致无法failover。
2第一次故障转移后，如果恢复了之前的拓扑结构，需要删除掉workdir中的complete文件