mha的搭建步骤(一主一从架构)

所需脚本文件到这里下载：http://note.youdao.com/share/web/file.html?id=ae8b11a61f7a8aa7b52aac3fcf0c4b83&type=note

环境：

centos 6.5 x64

192.168.0.32  # master

192.168.0.33  #管理节点和从节点slave

VIP：192.168.0.62

iptables打开mysql端口

selinx关闭：

shell > vim /etc/selinux/config

SELINUX=disabled

1.安装mysql 5.5.x以上的版本(如果是5.6以上的版本，不建议开启GTID复制)，并搭建好双主复制，复制用户：repl，复制用户密码：123456

主从复制搭建好后，从库执行下面两个命令(不要加入到my.cnf中，因为从库随时可能被提升为master)

mysql -e 'set global read_only=1;set global relay_log_purge=0;'

如果是刚刚初始化安装完成的mysql，建议进行安全清理：

mysql > delete from mysql.user where user!='root' or host !='localhost';

mysql > truncate table mysql.db;

mysql > drop database test;

mysql > flush privileges;

2.所有服务器之间建立ssh互信（如果管理节点和数据节点共用，要自己能免密钥登录自己）：

在master上：

shell > ssh-keygen -t rsa  #创建密钥

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.33  #发送ssh密钥到其他服务器

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.32  #发送ssh密钥到自己

在slave上：

shell > ssh-keygen -t rsa  #创建密钥

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.32  #发送ssh密钥到其他服务器

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.33  #发送ssh密钥到自己

3.安装epel源(所有节点)：

shell > rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm
shell > rpm -ivh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

4.安装mha（一主一从的架构建议两个节点都安装manager和node包）

MHA的配置，只需要在manager节点上配置即可正常工作，配置文件最少一个，一般可以分成两个部分，这样一个manager管理多个集群时可以少写一点配置（当然，为了方便故障时快速恢复manager，可以在备主上也进行配置一，只是需要把配置里的主动关系做对应修改）：

master:

shell > yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y

解压mha_packge.zip:
shell > cd packge

shell > rpm -Uvh mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm

shell > cp -ar masterha /etc/

shell > mkdir /var/log/masterha/app1 -p

slave安装：

shell > yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y

解压mha_packge.zip:
shell > cd packge

shell > rpm -Uvh mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm

shell > cp -ar masterha /etc/

shell > mkdir /var/log/masterha/app1 -p

5.配置Mha

master（master中的MHA配置只是用来做备用的，不需要启动管理节点，在主库切换成从库之后，就可以快速切换管理节点，不需要重新配置），全局配置文件内容如下:

shell > cd /etc/masterha

shell > cat masterha_default.conf  #修改全局配置文件

[server default]

#MySQL的用户和密码

user=root

password=4testHIGH

#系统ssh用户

ssh_user=root

#复制用户

repl_user=repl

repl_password= 123456

#监控

ping_interval=1

#shutdown_script=""

#切换调用的脚本

master_ip_failover_script= /etc/masterha/master_ip_failover

master_ip_online_change_script= /etc/masterha/master_ip_online_change

修改集群配置文件：

shell > cat app1.conf

[server default]

user=root

password=4testHIGH

#mha manager工作目录

manager_workdir = /var/log/masterha/app1

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

remote_workdir = /var/log/masterha/app1

[server1]

hostname=192.168.0.33  #主库的配置上，把从库写成主节点

master_binlog_dir = /data/mysql/data

port=3306

[server2]

hostname=192.168.0.32 #主库的配置上，把主库写成备节点

master_binlog_dir=/data/mysql/data

port=3306

candidate_master=1

check_repl_delay = 0     #用防止master故障时，切换时slave有延迟，卡在那里切不过来。

注：如果有一主多从架构，那么只需要在app1/conf文件后面再多添加几个配置即可，类似如下：

[server3]

hostname=192.168.0.x

port=3306

master_binlog_dir=/data/mysql/data

 

6.修改master_ip_failover文件中的VIP和绑定网卡

shell > vim /etc/masterha/master_ip_failover

修改master_ip_online_change文件中的VIP和绑定网卡：

shell > vim /etc/masterha/master_ip_online_change

7.把drop_vip.sh和init_vip.sh中的网卡和VIP都改过来

把脚本赋予执行权限：shell > chmod +x drop_vip.sh init_vip.sh master_ip_*

8.这里我为了故障时能快速恢复MHA管理节点，在备主(slave)上也配置了manager，但是不启动：

shell > cd /etc/masterha

shell > cat masterha_default.conf  #修改全局配置文件

[server default]

#MySQL的用户和密码

user=root

password=4testHIGH

#系统ssh用户

ssh_user=root

#复制用户

repl_user=repl

repl_password= 123456

#监控

ping_interval=1

#shutdown_script=""

#切换调用的脚本

master_ip_failover_script= /etc/masterha/master_ip_failover

master_ip_online_change_script= /etc/masterha/master_ip_online_change

修改集群配置文件：

shell > cat app1.conf

[server default]

user=root

password=4testHIGH

#mha manager工作目录

manager_workdir = /var/log/masterha/app1

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

remote_workdir = /var/log/masterha/app1

[server1]

hostname=192.168.0.32 #从库上的配置，主库就是主节点

master_binlog_dir = /data/mysql/data

port=3306

[server2]

hostname=192.168.0.33 #从库上的配置，从库就是备节点

master_binlog_dir=/data/mysql/data

port=3306

candidate_master=1

check_repl_delay = 0     #用防止master故障时，切换时slave有延迟，卡在那里切不过来。

修改master_ip_failover文件中的VIP和绑定网卡

shell > vim /etc/masterha/master_ip_failover

修改master_ip_online_change文件中的VIP和绑定网卡：

shell > vim /etc/masterha/master_ip_online_change

把drop_vip.sh和init_vip.sh中的网卡和VIP都改过来

把脚本赋予执行权限：shell > chmod +x drop_vip.sh init_vip.sh master_ip_*

9.配置文件测试（一主一从架构的主库和从库上的管理节点建议都要进行测试，不单单只测试从库上的管理节点）：

测试ssh连通性：

shell > masterha_check_ssh --conf=/etc/masterha/app1.conf

注意：如果你是用虚拟机做实验，很可能碰到这步骤报错，碰到两边都无法ssh或者一边可以，一边不可以，此时，可以重新创建密钥试试，如果多次尝试仍然不行，那么就把发起ssh连接而失败的虚拟机换一台再试。或者，看看你的架构是不是把管理节点和数据节点放一起，而管理节点上又没有配置自己到自己免密钥登录。

看到最后提示：[info] All SSH connection tests passed successfully.表示测试通过

测试集群中的主从复制：

shell > masterha_check_repl --conf=/etc/masterha/app1.conf  --global_conf=/etc/masterha/masterha_default.conf

注意：执行这个检测命令的时候使用的是user=root帐号去检测，注意user=root帐号也要有远程权限,另外，把mysql目录下的命令做个链接：ln -s /usr/local/mysql/bin/* /usr/bin/

看到最后提示：MySQL Replication Health is OK.表示测试通过

10.启动管理节点(只在从库上启动管理节点)：

启动管理节点最好使用screen启动：

shell > nohup masterha_manager --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf  --remove_dead_master_conf --ignore_last_failover> /tmp/mha_manager.log 2>&1 &

sh /etc/masterha/init_vip.sh
确认VIP 绑定成功，如果业务按VIP 配置的访问DB，应该已经可以正常访问

注意：
第一次起动，主库上的VIP 不会自动绑定，需要手功调用init_vip.sh 去绑定，主库发生故障切换会进行vip 的漂移

11.启动之后查看控制台输出日志：

/tmp/mha_manager.log

查看app1日志输出：

/var/log/masterha/app1/app1.log

查看master的健康状况日志：

/var/log/masterha/app1/app1.master_status.health

检查是否启动成功：

shell > masterha_check_status --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

12.切换测试：

1）.在线手工切换（维护切换，需要把MHA监控进程关掉）：

shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.0.33 --orig_master_is_new_slave --running_updates_limit=10000

--orig_master_is_new_slave：把旧的master配置为从库

--running_updates_limit=10000：如果主从库同步延迟在10000s内都允许切换，但是但是切换的时间长短是由recover时relay 日志的大小决定

切换成功需要看到类似下面的提示：

info] Switching master to 192.168.0.33(192.168.0.33:3306) completed successfully

同时要查看VIP是否已经漂移到了新的主库上面

2）.故障手工切换（MHA进程没启动或者挂了的同时主库也挂了）：

shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --dead_master_host=old_ip --master_state=dead --new_master_host=new_ip --ignore_last_failover

切换成功需要看到类似如下提示：

Started manual(interactive) failover.

Invalidated master IP address on 192.168.0.32(192.168.0.32:3306)

The latest slave 192.168.0.33(192.168.0.33:3306) has all relay logs for recovery.

Selected 192.168.0.33(192.168.0.33:3306) as a new master.

192.168.0.33(192.168.0.33:3306): OK: Applying all logs succeeded.

192.168.0.33(192.168.0.33:3306): OK: Activated master IP address.

Generating relay diff files from the latest slave succeeded.

192.168.0.33(192.168.0.33:3306): Resetting slave info succeeded.

Master failover to 192.168.0.33(192.168.0.33:3306) completed successfully.

注意：如果是主库服务器还活着，只是mysqld挂了的时候，VIP在切换的时候也会自动漂移，如果是服务器挂了，那么在挂掉的主库重启后，注意不要让VIP随开机启动，因为此时VIP已经漂移到了从库上，从库上可能正在接管业务，故障主库起来后，需要确认数据是否跟新的主库一样，如果一样，那么就把故障主库作为新的从库加入新主库下

3）.故障自动切换（启动MHA监控进程）手动把主库mysqld停掉，观察/var/log/masterha/app1.log日志输出，看到如下信息：

Started automated(non-interactive) failover.

Invalidated master IP address on 192.168.0.32(192.168.0.32:3306)

The latest slave 192.168.0.33(192.168.0.33:3306) has all relay logs for recovery.

Selected 192.168.0.33(192.168.0.33:3306) as a new master.

192.168.0.33(192.168.0.33:3306): OK: Applying all logs succeeded.

192.168.0.33(192.168.0.33:3306): OK: Activated master IP address.

Generating relay diff files from the latest slave succeeded.

192.168.0.33(192.168.0.33:3306): Resetting slave info succeeded.

Master failover to 192.168.0.33(192.168.0.33:3306) completed successfully.

表示成功切换，切换成功后，查看VIP是否漂移到了从库上(切换成功后，MHA进程会自动停止)，同时查看/etc/masterha/app1.conf文件中的[server1]的配置是否都被删除掉了

故障主库起来后，需要确认数据是否跟新的主库一样，如果一样，那么就把故障主库作为新的从库加入新主库下。然后在故障主库上启动MHA进程。

附：

MHA 日常维护命令集：

1）.查看ssh 登陆是否成功
shell > masterha_check_ssh --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf
2）.查看复制是否建立好
shell > masterha_check_repl --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

3）.检查启动的状态
shell > masterha_check_status--global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

4）.停止mha
shell > #masterha_stop --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

5）.启动mha
shell > nohup masterha_manager --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf > /tmp/mha_manager.log < /dev/null 2>&1 &

注意：当有slave 节点宕掉的情况是启动不了的，加上--ignore_fail_on_start 即使有节点宕掉也能启动mha，需要在配置文件中设置ignore_fail=1

6）.failover 后下次重启
每次failover 切换后会在管理目录生成文件app1.failover.complete ，下次在切换的时候会发现有这个文件导致切换不成功，需要手动清理掉。
shell > rm -rf /masterha/app1/app1.failover.complete
也可以加上参数--ignore_last_failover

7）.手工failover
手工failover 场景，master 死掉，但是masterha_manager 没有开启，可以通过手工failover：
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --dead_master_host=old_ip --master_state=dead --new_master_host=new_ip --ignore_last_failover

8）.masterha_manager 是一种监视和故障转移的程序。另一方面,masterha_master_switch 程序不监控主库。masterha_master_switch 可以用于主库故障转移,也可用于在线总开关。

9）.手动在线切换(master还或者，比如做维护切换时)
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.199.78 --orig_master_is_new_slave
或者
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.199.78 -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。这种方法适用于增减索引，如果是增加字段就需要额外注意。

注意：Online master switch 开始只有当所有下列条件得到满足。
1）. IO threads on all slaves are running // 在所有slave 上IO 线程运行。
2）. SQL threads on all slaves are running //SQL 线程在所有的slave 上正常运行。
3）. Seconds_Behind_Master on all slaves are less or equal than --running_updates_limit
seconds // 在所有的slaves 上Seconds_Behind_Master 要小于等于running_updates_limit
seconds
4）. On master, none of update queries take more than --running_updates_limit seconds in the
show processlist output // 在主上，没有更新查询操作多于running_updates_limit seconds