mha mysql 两台机器_MySQL主从复制（8）MHA实现主从高可用

一、MHA介绍

1、MHA的作用

MHA是实现MySQL高可用的一种成熟解决方案，可以在主从故障时自动完成主从切换，切换速度在30-60秒，并且可以最大程度的去保持数据一致性。MHA由管理节点(Manager)和数据节点(Node)组成，一套MHA Manager可以管理多套MySQL集群。当Manager发现MySQL Master出现故障时自动将一个拥有最新数据的Slave提升为Master，并让另外的Slave重新指向到新的Master上来。除此之外MHA还可以在线进行主从切换，大概2秒内就可以完成。

2、MHA工作流程

· 主库发生故障时，MHA把binlog通过scp传到其他节点。如果主库已经无法SSH，则在两个从库中进行差异补偿。所以建议准备一台专门存放binlog的机器。

·将所有从库的relaylog进行对比，找到一个拥有最新position信息的slave，如slave01

·通过slave01的relaylog对其它从库的relaylog进行补全，保持和slave01一致

·将slalve01提升为Master，并让其它从库指向到slave01

·将第一步所保存的binlog信息补全到slave01

·开启其它节点slave的主从复制，保持和slave01一致

二、MHA的部署(至少一主两从，否则MHA无法启动，另外最好再配置一台存放binlog的服务器)

1、首先在每个节点都安装上perl-DBD-MySQL，该组件会对MHA所需软件提供依赖，因为所用MHA软件是perl语言写的程序(Xtrabackup也是)

yum install perl-DBD-MySQL

2、下载MHA的Manager和Node安装包(下载地址https://github.com/yoshinorim/mha4mysql-manager)。虽然Manager可以装在某个从节点上，但建议单独找机器部署，这样可以避免节点故障导致MHA无法工作，而且一套MHA是可以同时监控多套MySQL主从。而Node则需要装在每一个MySQL节点上(没有Node的话Manager也装不上)

rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm #每个节点都要装Node

yum localinstall mha4mysql-manager-0.58-0.el7.centos.noarch.rpm #找一个从节点或者独立服务器装Manager

3、在每个数据库节点上都创建一个用于主从复制的账号，因为发生主从切换后其他节点就会用到该账号。在所有节点创建mha用户并授权，这里在主库执行授权语句即可，由于之前已经是主从关系，所以该语句也会同步到其他从库上。另外还要保证主从节点都要开启binlog，另外从库的只读选项不能写在配置文件里，需要使用命令行临时设置

GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO repl@'192.168.36.11' IDENTIFIED BY '123456789'; #为每个节点创建一个主从复制账号

grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha'; #为mha创建账号

set global read_only=1 #只在从库配置

4、在Manager节点上创建MHA配置文件，配置文件样例文件可以在安装包里获取到。对于MHA binlog server的实时同步可以参考本站文章《【MySQL运维】使用mysqlbinlog实时同步binlog日志》

mkdir -p /etc/mha /var/log/mha

vi /etc/mha/linuxe_mha.cnf #多套主从可以建立多个配置文件

[server default]

manager_log=/var/log/mha/manager.log #MHA日志，发生主从切换时都会在这里详细记录

manager_workdir=/var/log/mha #MHA日志存放目录

master_binlog_dir=/data/mysql/ #主库binlog路径，如果MHA管理多个主从，有主节点路径不一致则可以单独写在主机标签中

user=mha #MHA管理用户

password=mha #管理用户密码

ping_interval=2 #每2秒检查一次主库状态，4次不可连就触发切换

repl_password=123456 #主从复制的密码

repl_user=repl #主从复制的用户，用于发生主从切换后告知MHA用什么账号来构建新的主从

ssh_user=root #MHA 会使用scp传输日志，所以节点之间做好密钥登录

ssh_port=22

[server1] #主机标签，数字大小会影响优先级

hostname=10.0.0.51

port=3306

master_binlog_dir=/data/mysql/binlog #单独定义了一个binlog路径

[server2]

#candidate_master=1 #强制该节点成为候选master，由于少了判断过程，可以节约切换时间，通常用于两地三中心架构，优先切就近节点为主

#check_repl_delay=0 #和上面配置配合使用，忽略从库复制延时的问题，否则延迟大于100M的话候选master也不会被选举为master

hostname=10.0.0.51

port=3306

[server3]

hostname=10.0.0.52

port=3306

[binlog1] #配置一台binlog服务器用来实时备份binlog，防止主库断电导致binlog无法传输。该机器需要自行使用mysqlbinlog实时获取binlog

no_master=1 #该节点不会被提升为master

hostname=10.0.0.54

master_binlog_dir=/data/mysql/binlog

5、通过Manager自带脚本masterha_check_ssh检查各节点免密登录是否正常；通过masterha_check_repl脚本检查主从复制是否正常

masterha_check_ssh --conf=/etc/mha/mha.cnf #各节点配置好免密登录

masterha_check_repl --conf=/etc/mha/mha.cnf #至少一主两从

6、启动MHA

nohup masterha_manager --conf=/etc/mha/mha.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/manager.log 2>&1 &

# remove_dead_master_conf：会在MHA配置文件中去掉已经宕机的主库配置信息

# ignore_last_failover：MHA默认8小时内只切换一次，加该选项可以忽略这个限制

# ignore_fail_on_start：不加该参数的话如果有一个或多个从库处于宕机状态,MHA不会启动

7、MHA部署完成后使用masterha_check_status脚本检查MHA状态

masterha_check_status --conf=/etc/mha/mha.cnf

三、MHA故障转移与修复

· masterha_master_switch手动故障转移

适用于管理节点没有启动MHA manager或需要手动切换主从的场景

masterha_master_switch --master_state=dead --conf=/etc/mha.cnf --dead_master_host=192.168.0.100 --dead_master_port=3306 --new_master_host=192.168.0.101 --new_master_port=3306 --ignore_last_failover

# --master_state=dead：指定主库状态，alive代表在线主从切换，dead则是故障切换

· 主从切换后故障节点的修复

1、当主节点故障并发生主从切换后，原Master就处于暂停服务状态，需要手动修复数据才可以使用。在重新部署主从时，通过MHA日志可以找到发生切换时的Position信息，然后直接复制那条CHANGE MASTER语句即可让其成为从库，日志内容大致如下：

All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.2.129', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=61791, MASTER_USER='repl', MASTER_PASSWORD='xxx';

2、MHA发生切换后，配置文件会被重写，原有的Master节点的信息会被删除(可以理解为配置文件如果发生了变化，那就意味发生过切换)，所以在恢复了服务后还需要手动在MHA配置文件中增加一台节点

3、binlog server上的mysqlbinlog会自动停止，所以重新运行mysqlbinlog拉取日志，运行前修改节点IP为新的主库、binlog名字

四、MHA的VIP漂移

传统的VIP管理通常是keepalive，但是用它做MHA VIP管理的话无法保证VIP漂移到拥有最新数据的Slave上，因为keepalive并不知道节点的数据情况。所以需要使用MHA自带的脚本进行VIP管理。下面是配置步骤：

1、编辑mha配置文件，在[server default]标签增加一行

master_ip_failover_script=/usr/local/bin/master_ip_failover #脚本可以从manager源码包samples/script目录中复制，然后修改一些VIP配置等信息

2、增加执行权限

chmod +x /usr/local/bin/master_ip_failover

3、检查脚本

masterha_check_repl --conf=/etc/mha/mha.cnf

4、第一次需要在主库手动配置VIP，然后重启MHA

ifconfig eth0:1 192.168.10.199/24 #创建一个VIP

masterha_stop --conf=/etc/mha/mha1.cnf #停止MHA

nohup masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/manager.log 2>&1 &