MHA实现MySQL主从自动在线切换功能

一：MHA工作原理；                                                                                                     

1、保存宕机的master的二进制日志事件；

2、找最新更新的slave；

3、应用差异的中继日志到其他slave；

4、应用从master保存二进制日志事件；

5、提升一个slave为新的master；

6、使用其他slave指向新的master进行复制；

MHA提供按需在线自动切换master/slave节点；能够在30秒内实现故障切换， 并能在故障切换中， 最大可能的保证数据一致性。

架构图如下所示：

MHA的角色：

manager管理节点：通常单独部署在一*立机器上管理多个master/slave集群(组)， 每个master/slave集群称作一个application， 用来管理统筹整个集群；

node数据节点：运行在每台mysql服务器上（master|slave|manager），接收manager发的指令，在每个节点上执行一系列操作；

常见工具程序：

manager节点：

masterha_check_ssh                        :MHA依赖的ssh环境监测工具

masterha_check_repl                       : MYSQL复制环境检测工具；

masterga_manager                          : MHA 服务主程序

masterha_check_status                    : MHA 运行状态探测工具；

masterha_master_monitor              :MYSQL master节点可用性监测工具；

masterha_master_swith                   :master节点切换工具；

masterha_conf_host                        :添加或删除配置的节点；

masterha_stop                                 :关闭MHA服务的工具。

node节点：

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

apply_diff_relay_logs                    :识别差异的中继日志事件并应用于其他slave；

purge_relay_logs                           :清除中继日志（不会阻塞SQL线程） ；自定义扩展

secondary_check_script                :通过多条网络路由检测master的可用性；

master_ip_failover_script              :更新application使用的masterip；

report_script                                  :发送报告

init_conf_load_script                     :加载初始配置参数；

                 master_ip_online_change_script  :更新master节点ip地址；

二：实现步骤；                                                     

1、环境；MHA对MySQL复制环境有特殊要求， 例如各节点都要开启二进制日志及中继日志， 各从节点必须显示启用其read-only属性， 并关闭relay_log_purge功能等， 这里对配置做事先说明。

    master：172.16.253.35

    slave1：172.16.253.53

    slave2：172.16.253.52

    manager：172.16.253.51

各节点/etc/hosts文件内容：

   172.16.253.53 node1.sjj.comnode1

    172.16.253.53 node2.sjj.comnode2

    172.16.253.52 node3.sjj.comnode3

    172.16.253.51 node4.sjj.comnode4

2、node1节点上master的配置文件；

[[e-mail] ~]# vim /etc/my.cnf
 [mysqld]
server-id = 1
log-bin = master-log
relay-log = relay-log
skip_name_resolve = ON

然后启动mariadb服务;

[[e-mail] ~]# systemctl start mariadb

3、所有的从节点的配置文件；(node2为例)

[[e-mail] ~]# vim /etc/my.cnf   
[mysqld]
server-id = 2 #复制集群中的各节点的id均必须唯一；
relay-log = relay-log
log-bin = master-log
read_only = 1
relay_log_purge = 0 #是否自动清空不再需要中继日志
skip_name_resolve = ON

 然后启动所有从服务器上的mariadb服务；

[[e-mail] ~]# systemctl start mariadb

4、在master节点上授权；

MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'172.16.253.%' identified by 'centos';
MariaDB [(none)]> flush privileges;   #刷新权限；
MariaDB [(none)]> show master status;  #查看master现在的状态，显示的file名字及position位置编号；

5、启动从服务器上的I/O线程和SQL线程；

 MariaDB [(none)]> change master to  
    -> master_host='172.16.253.35', 
    -> master_user='slave',
    -> master_password='centos',
    -> master_log_file='master-log.000001', #第四步中查看到的master的file文件名
    -> master_log_pos=493; #第四步中查看到的master的position位置号
 MariaDB [(none)]> start slave;
 MariaDB [(none)]> show slave status\G; #可查看到如下关键两行，只有全为Yes才表示同步成功
            Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

6、安装配置MHA；

    1）、在master上执行授权，允许所有其他节点远程访问；

MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'172.16.253.%' identified by 'mhapass';

 2）、使所有节点可以进行无密码互相通信,所有节点都要做的操作，例如manager节点上生成秘钥对，分别发给其他节点；

[[e-mail] ~]# ssh-****** -t rsa -P '' -f ~/.ssh/id_rsa #此处实验没有设置密码；
[[e-mail] ~]# ssh-copy-id [e-mail]  #分别发给35、53、52三个节点；

3）、yum安装MHA；

        准备两个安装包：

        mha4mysql-node-0.56-0.el6.noarch.rpm

        mha4mysql-manager-0.56-0.el6.noarch.rpm

[[e-mail] ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y      #所有节点上都执行；
[[e-mail] ~]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm -y  #只在manager上安装；

注意：在manager上要先安装mha4mysql-node再安装manager，因为有些安装manager时所依赖的包；

 4）、关于配置文件：

        Manager节点需要为每个监控的master/slave集群提供一个专用的配置文件，而所有的master/slave集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf，其为可选配置。如果仅监控一组master/slave集群，也可直接通过application的配置来提供各服务器的默认配置信息。而每个application的配置文件路径为自定义。

5）、定义配置文件；

为MHA专门创建一个管理用户，方便以后使用，在mysql的主节点上配置，三个节点自动同步；

[[e-mail]~]#  mkdir /etc/mha_master
[[e-mail] ~]# vim /etc/mha_master/sjj.cnf 
            [server default]
            user=mhaadmin  #MHA管理用户；
            password=mhapass  #MHA管理密码；
            manager_workdir=/etc/mha_master/sjj  #mha_master自己的工作路径，需要手动创建；
            manager_log=/etc/mha_master/manager.log  #mha_master自己的日志文件；
            remote_workdir=/mydata/mha_master/sjj     #每个远程主机的工作目录，自己手动创建；
            ssh_user=root   #基于ssh秘钥认证用户；
            repl_user=slave   #数据库用户名；
            repl_password=centos  #数据库密码；
            ping_interval=1   #ping间隔时长；
            [server1]     #节点1；
            hostname=172.16.253.35   #节点1主机ip；
            ssh_port=22   #节点1 的ssh端口；
            candidate_master=1   #将来可不可以作为master候选主节点；
            [server2]
            hostname=172.16.253.53
            ssh_port=22
            candidate_master=1
            [server3]
            hostname=172.16.253.52
            ssh_port=22
            candidate_master=1

6）、检测各节点ssh互相通信配置是否OK；

[[e-mail] ~]# masterha_check_ssh -conf=/etc/mha_master/sjj.cnf

我在这一步第一次执行时出错了

Sat Dec 16 10:20:59 2017 - [info] Reading default configuration from /etc/masterha_default.cnf..
Sat Dec 16 10:20:59 2017 - [info] Reading application default configuration from     /etc/mha_master/sjj.cnf..
Parameter name repl_interval is invalid!                                #repl_interval这个参数无效
     at /usr/share/perl5/vendor_perl/MHA/SSHCheck.pm line 148.

原因：在写配置文件时将ping_interval=1写成了repl_interval，参数与需要传入/usr/share/perl5/vendor_perl/MHA/SSHCheck.pm里的参数不对应，所以报错；
测试结果显示[info] All SSH connection tests passed successfully.表示测试成功

7）、检查管理的MYSQL复制集群的连接配置参数是否OK； 

[[e-mail] ~]# masterha_check_repl -conf=/etc/mha_master/sjj.cnf

最后显示结果：MySQL Replication Health is OK. 表示成功； 
但在这个测试中有人出错，原因可能是没有在master上授权给所有的从节点，以至于从节点上没有相对应的账号。因为这个架构，任何一个从节点都有可能成为主节点，所以也要创建账号；所以只需在master主节点上再次执行授权操作即可（具体操作见第4步）； 

7、启动MHA； 

在manager节点上执行： 

[[e-mail] ~]# nohup masterha_manager -conf=/etc/mha_master/sjj.cnf &> /etc/mha_master/manager.log &

其中“&>     &”是将输出结果全部重定向到/etc/mha_master/manager.log，也可以使用“2>&1”； 

 [[e-mail] ~]# masterha_check_status -conf=/etc/mha_master/sjj.cnf  #查看master的状态；

显示结果类似： 

sjj (pid:33599) is running(0:PING_OK), master:172.16.253.35

若是需要停止MHA，需要使用master_stop命令； 

[[e-mail] ~]# masterha_stop -conf=/etc/mha_master/sjj.cnf
[[e-mail] ~]# masterha_check_status -conf=/etc/mha_master/sjj.cnf          #可查看到停止状态
sjj is stopped(2:NOT_RUNNING).
[[e-mail] ~]#

三：测试；                                                                                                                              

1、测试MHA故障转移； 
1）、在master节点关闭mariadb服务，模拟主节点数据崩溃； 

[[e-mail] ~]# killall -9 mysqld mysqld_safe
[[e-mail] ~]# rm -rf /var/lib/mysql/*

2）、在manager节点查看日志； 

[[e-mail] ~]# tail -200 /etc/mha_master/manager.log

结果显示如下： 

sjj: MySQL Master failover 172.16.253.35(172.16.253.35:3306) to 172.16.253.53(172.16.253.53:3306) succeeded
 Master 172.16.253.35(172.16.253.35:3306) is down!
 Check MHA Manager logs at manager:/etc/mha_master/manager.log for details.
 Started automated(non-interactive) failover.
 The latest slave 172.16.253.53(172.16.253.53:3306) has all relay logs for recovery.
 Selected 172.16.253.53(172.16.253.53:3306) as a new master.
 172.16.253.53(172.16.253.53:3306): OK: Applying all logs succeeded.
 172.16.253.52(172.16.253.52:3306): This host has the latest relay log events.
 Generating relay diff files from the latest slave succeeded.
 172.16.253.52(172.16.253.52:3306): OK: Applying all logs succeeded. Slave started, replicating from 172.16.253.53(172.16.253.53:3306)
 172.16.253.53(172.16.253.53:3306): Resetting slave info succeeded.
 Master failover to 172.16.253.53(172.16.253.53:3306) completed successfully.

就是说：master节点172.16.253.35down，提升具有最新数据的slave节点172.16.253.53做新的主节点； 

2、增加新节点，并上线； 
若是为了稳定复制集群，将故障服务器剔除，新增一台服务器的话，需要将新服务器的ip配置为故障服务器所用的ip，这样，就不需要修改配置文件/etc/mha_master/sjj.cnf的内容了；再次检测状态，检查无误后，再次启动manager；即：

#1、先将新服务器的ip改为172.16.253.35;安装并启动mariadb服务；
#2、然后将配置文件/etc/my.cnf配置为：
           [mysqld]
        server-id = 4 #复制集群中的各节点的id均必须唯一；
        relay-log = relay-log
        log-bin = master-log
        read_only = 1
        relay_log_purge = 0 #是否自动清空不再需要中继日志
         skip_name_resolve = ON
#3、在新的主节点服务器上再次授权；
MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'172.16.253.%' identified by 'centos';
MariaDB [(none)]> flush privileges;   #刷新权限；
MariaDB [(none)]> show master status;  #查看master现在的状态，显示的file名字及position位置编号；
#4、在新增服务器节点上指定master，开启IO线程和SQL线程；
MariaDB [(none)]> change master to master_host='172.16.253.53',
 -> master_user='slave',
 -> master_password='centos',
 -> master_log_file='master-log.000003',
 -> master_log_pos=503
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G; #可查看到如下关键两行，只有全为Yes才表示同步成功
                 Slave_IO_Running: Yes
                 Slave_SQL_Running: Yes
#5、在新增节点上安装node包；
[[e-mail] ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y
#6、然后在manager上检查测试；
[[e-mail] ~]# masterha_check_status -conf=/etc/mha_master/sjj.cnf
[[e-mail] ~]# masterha_check_repl -conf=/etc/mha_master/sjj.cnf
#7、测试通过后，启动MHA；
[[e-mail] ~]# masterha_manager -conf=/etc/mha_master/sjj.cnf > /etc/mha_master/manager.log 2>&1

新节点上线，故障转移恢复注意事项：

(1)、在生产环境中，当你的主节点挂了后，一定要在从节点上做一个备份，拿着备份文件把主节点手动提升为从节点，并指明从哪一个日志文件的位置开始复制

(2)、每一次自动完成转换后，每一次的(replication health )检测不ok始终都是启动不了必须手动修复主节点， 除非你改配置文件

(3)、手动修复主节点提升为从节点后，再次运行检测命令

[[e-mail] ~]#masterha_check_repl --conf=/etc/mha_master/app1.cnf

app1 (pid:3211) is running(0:PING_OK), master:172.16.5.103

(4)、再次运行起来就恢复成功了

masterha_manager --conf=/etc/mha_master/app1.cnf 

四：在MHA切换主从后需要考虑的问题；                                                 

前端PHP或者Tomcat连接数据库是通过ip+port，但是主库和从库ip不一样，就算MHA实现了从升为新主，但是程序不知道，还是会顺着给定连接的ip端口去访问原来的主，但是原来的主已经宕机无法提供服务，所以我们就可以利用Keepalived，在从节点中选取一台作为BACKUP，即在发现主库故障，MHA实现主从切换时，Keepalived利用VRRP协议将VIP飘到新主服务器上，继续对外提供服务；所以在这个配置中，就需要将

MHA中的配置文件/etc/mha_master/sjj.cnf中server中的配置项：candidate_master=1只配置给其中一台从服务器，同时Keepalived的BACKUP也要在此台从服务器上，也就是说，这时候我们可以指定从节点中的某台服务器可以竞选下一任新主服务器（candidate_master=1），当主库宕机时，MHA升指定的从服务器做新主，同时Keepalived将原主服务器上的VIP飘到新主上；使用Zabbix配置监控项，当主服务器宕机时及时通知运维相关人员，及时介入修复，以免新主宕机；