MHA高可用切换工具

主库 /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 [email protected]

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解析到所有集群节点，减少更改配置的的麻烦，效率还高！

MHA高可用切换工具

猜你喜欢