MHA高可用切换工具

共计 5715 个字符，预计需要花费 15 分钟才能阅读完成。

MHA 简介
MHA 是一位日本 MySQL 大牛用 Perl 写的一套 MySQL 故障切换方案，来保证数据库系统的高可用，在宕机时间内（通常 10-30 秒），完成故障切换，部署 HA, 可避免主从不一致问题节约购买服务器的费用，易安装，不改变现有部署。

MHA 解决课题

MHA 高可用切换工具
MySQL 主从复制架构中，当 master 发生故障时，有可能会发生一部分（或者全部）的 slave 未能获取到最新 binglog 日志，导致 slave 从库和 master 数据不一致情况，甚至各 salve 之间数据也存在偏差
而 master 能够消除各 slave 之间数据的差异，最大程度地保证数据一致性，实现真正意义上的高可用 1）从宕机崩溃的 master 保存二进制日志事件（binlog events）;2）识别含有最新更新的 slave；3）应用差异的中继日志（relay log）到其他的 slave；4）提升一个 slave 为新的 master；5）使其他的 slave 连接新的 master 进行复制

MHA 架构
MHA 高可用切换工具
MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。MHA Node 运行在每台 MySQL 服务器上，MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明在 MHA 自动故障切换过程中，MHA 试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过 ssh 访问，MHA 没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用 MySQL 5.5 的半同步复制，可以大大降低数据丢失的风险。MHA 可以与半同步复制结合起来。如果只有一个 slave 已经收到了最新的二进制日志，MHA 可以将最新的二进制日志应用于其他所有的 slave 服务器上，因此可以保证所有节点的数据一致性。

MHA 特点 从 master 的监控到故障转移全部自动完成，故障也可以选择手动执行

可在秒级单位内实现故障转移

可将任意 salve 提升为 master

安装和卸载 MHA 不用停止当前正在运行的 mysql 进程

MHA 本身不会增加服务器负担，不会降低性能，不用另外追加服务器

不依赖 Storage Engine

不依赖 binglog 日志文件格式（statement 或者 row）

具备在多个点上调用外部脚本技能，可以在电源 OFF 或者 IP 地址的故障上转移

MHA 部署 环境：CentOS 6.7_x64 MySQL5.5 多实例（已经实现主从复制）

主库 /data/3306/ 172.16.2.10 端口 3306 #master
    从库 /data/3307/ 172.16.2.10 端口 3307 #candicate master 备选主库
从库兼管理 /data/3308/ 172.16.2.10 端口 3308 #slave

1) 虽然我这里采用的是本地多实例环境，但是还是要配置 SSH 远程分发密钥，以便 MHA 管理主机能不用输入密码和其他节点从库通信，如果是不同主机，记得每台都要分发公钥，管理节点自己也要给自己发一次

[root@db02 ~]# ssh-keygen -t rsa
[root@db02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.16.2.10

2) 所有节点安装 mha 的 node 包

[root@db02 ~]# yum install perl-DBD-MySQL -y #安装依赖包
[root@db02 ~]# rpm -ivh tools/mha4mysql-node-0.54-0.el6.noarch.rpm #mha 的 node 节点包（下载地址：https://downloads.mariadb.com/files/MHA/mha4mysql-node-0.54-0.el6.noarch.rpm）

3) 管理节点安装 manager 和相关依赖包

[root@db02 ~]# yum install perl-DBD-MySQL -y
[root@db02 ~]# yum install perl-Config-Tiny -y
[root@db02 ~]# yum install perl-Log-Dispatch -y
[root@db02 ~]# yum install perl-Parallel-ForkManager -y
[root@db02 ~]# yum localinstall tools/mha4mysql-manager-0.55-0.el6.noarch.rpm #localinstall 解决循环依赖问题

4) 从库服务器配置从库服务器配置文件里 my.cnf 需要添加 relay_log_purge= 0 参数
MySQL 数据库主从复制在默认情况下从库的 relay logs 会在 SQL 线程执行完毕后被自动删除，但是对于 MHA 场景下，对于某些滞后从库的恢复依赖于其他的从库 relay log，因此需要禁止自动删除功能：

mysql> set global relay_log_purge = 0;

编辑配置文件

my.cnf
 [mysqld]
 relay_log_purge = 0

5) 在所有节点服务器上添加管理账号

mysql> grant all privileges on *.* to mha@'172.16.2.%' identified by 'mha';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

6) 在管理端配置 /etc/mha/app1.cnf

[root@db02 ~]# mkdir /etc/mha #新建 MHA 配置文件夹
[root@db02 ~]# mkdir -p /var/log/mha/app1 #MHA 日志管理文件夹
[root@db02 ~]# vim /etc/mha/app1.cnf #管理端配置文件
[server default]
manager_log=/var/log/mha/app1/manager.log #manager 日志
manager_workdir=/var/log/mha/app1.log #manager 的工作目录
master_binlog_dir=/data/3306/ #master 保存 binlog 的位置，以便 MHA 可以找到 master 的日志
user=mha #设置监控用户 root
password=mha #设置监控用户密码
ping_interval=2 #设置监控主库，发送 ping 包的时间间隔，默认是 3 秒，尝试三次没有回应的时候自动进行 railover
repl_password=123456 #设置主从复制用户的密码
repl_user=rep #设置主从复制用户
ssh_user=root #SSH 远程连接用户名
[server1]
hostname=172.16.2.10
port=3306
[server2]
candidate_master=1 #设置为候选 master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的 slave
check_repl_delay=0 #默认情况下如果一个 slave 落后 master 100M 的 relay logs 的话，MHA 将不会选择该 slave 作为一个新的 master，因为对于这个 slave 的恢复需要花费很长时间，通过设置 check_repl_delay=0,MHA 触发切换在选择一个新的 master 的时候将会忽略复制延时，这个参数对于设置了 candidate_master= 1 的主机非常有用，因为这个候选主在切换的过程中一定是新的 master
hostname=172.16.2.10
port=3307
[server3]
hostname=172.16.2.10
port=3308

检查 mha manage 是否配置成功
1）检查 SSH 登陆

[root@db02 ~]# masterha_check_ssh --conf=/etc/mha/appl.cnf
...
Sun Jul 10 23:43:10 2016 - [info] All SSH connection tests passed successfully.

2）检查 mysql replication 主从复制是否成功

[root@db02 ~]# ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog #所有节点执行
[root@db02 ~]# ln -s /application/mysql/bin/mysql /usr/bin/mysql #所有节点执行
[root@db02 ~]# masterha_check_repl --conf=/etc/mha/appl.cnf
...
Mon Jul 11 00:11:14 2016 - [info] Checking replication health on 172.16.2.10..
Mon Jul 11 00:11:14 2016 - [info]  ok.
Mon Jul 11 00:11:14 2016 - [info] Checking replication health on 172.16.2.10..
Mon Jul 11 00:11:14 2016 - [info]  ok.
Mon Jul 11 00:06:56 2016 - [warning] shutdown_script is not defined.
Mon Jul 11 00:06:56 2016 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

3）管理端启动监控和测试启动监控

[root@db02 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
[1] 100414
#--remove_dead_master_conf    该参数代表当发生主从切换后，老的主库的 ip 将会从配置文件中移除
#--ignore_last_failover   在缺省情况下，如果 MHA 检测到连续发生宕机，且两次宕机间隔不足 8 小时的话，则不会进行 Failover，之所以这样限制是为了避免 ping-pong 效应。该参数代表忽略上次 MHA 触发切换产生的文件，默认情况下，MHA 发生切换后会在日志目录，也就是上面我设置的 /data 产生 app1.failover.complete 文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为 --ignore_last_failover
[root@db02 ~]# masterha_check_status --conf=/etc/mha/app1.cnf #查看主库及节点状态
app1 (pid:100414) is running(0:PING_OK), master:172.16.2.10

这里 MHA 配置就算结束了，我们来试试停掉主库 master，模拟故障
此时 3308 从库兼管理机器上

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.16.2.10 
                  Master_User: rep
                  Master_Port: 3306 #显示 master 是 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000023
          Read_Master_Log_Pos: 3887
               Relay_Log_File: relay-bin.000031
                Relay_Log_Pos: 701
        Relay_Master_Log_File: mysql-bin.000023
             Slave_IO_Running: Yes

我们停掉 3306

[root@db02 ~]# mysqladmin -uroot -pli123456 -S /data/3306/mysql.sock shutdown

再来看各同步信息

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.16.2.10
                  Master_User: rep
                  Master_Port: 3307 #显示主库已经切换为 3307 了，而且速度非常快
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 3529
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000002

而 3307 上面，此时已经看不到从库信息了，说明已经被 MHA 自动变为主库了~

mysql> show slave status\G;
Empty set (0.00 sec)

说明：实际工作中，当真的碰到主库宕机，要秒级切换主库时，这种 MHA 高可用方案涉及到要变更集群架构中 DB 的 IP 操作，会影响很多后端 web 应用，所有我们最好在连接解析数据库时采用解析主机名的方式，一旦主库宕机，MHA 重新选出主库以后，我们可以一键分发 hosts 解析到所有集群节点，减少更改配置的的麻烦，效率还高！

本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-07/133514.htm