企业——MYSQL高可用之MHA

1.原理：

--从崩溃的master报错二进制日志事件（binlog events）
--识别含有最新更新的slave
--应用差异的relay log到   其他的slave
--应用从master保存的二进制日志事件
--提升一个slave为新的master
--使其他的slave连接到新的master进行复制
　　　　　　

   MHA软件由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
   该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。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主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器

   在我们试验的时候：需要准备四个虚拟机，一个做manager，一个做master，剩下两个做slave。

Manager工具包主要包括以下几个工具：

masterha_check_ssh              检查MHA的SSH配置状况
masterha_check_repl             检查MySQL复制状况
masterha_manger                 启动MHA
masterha_check_status           检测当前MHA运行状态
masterha_master_monitor         检测master是否宕机
masterha_master_switch          控制故障转移（自动或者手动）
masterha_conf_host              添加或删除配置的server信息

Node工具包（这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：

save_binary_logs                保存和复制master的二进制日志
apply_diff_relay_logs           识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog              去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs                清除中继日志（不会阻塞SQL线程）

2.实验步骤

（1）给Manager下载安装MHA的一些安装包
   cd MHA/
   ls
   yum install mha4mysql-manager-0.56-0.el6.noarch.rpm perl-* mha4mysql-node-0.56-0.el6.noarch.rpm -y      ##需要解决依赖性的问题
   scp mha4mysql-node-0.56-0.el6.noarch.rpm root@172.25.254.1(2,3):/root　　## node节点需要给每一个mysql节点安装
　　　　　　

（2）在master和slave上下载node的安装包
   yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y

（3）编写MHA的配置文件
   mkdir /etc/masterha
   cd /etc/masterha/
   ls
   vim app1.cnf

　　　　　　

    [server default]
    manager_workdir=/etc/masterha  　　##工作目录
    manager_log=/etc/masterha/manager.log  　　##设置manager的日志 
    master_binlog_dir=/var/lib/mysql   　　##设置master保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据目录
    #master_ip_failover_script= /usr/local/bin/master_ip_failover  　　##设置自动failover时候，切换脚本  
    #master_ip_online_change_script= /usr/local/bin/master_ip_online_change　　 ##设置failover的时候，手动切换脚本    
    password=Wang+1212  　　##设置mysql中的root用户的密码
    user=root    　　##设置监控用户
    ping_interval=1  　　 ##设置监控主库，发送ping包的时间间隔，默认是3秒。常是三次没有回应的时候，则自动进行failover
    remote_workdir=/tmp   　　##社会自远端mysql在发生切换的时候binlog保存的位置
    repl_password=Wang+1212   　　##设置复制用户的密码
    repl_user=repl    　　##设置复制环境中的复制用户名
    #report_script=/usr/local/send_report  　　　　##设置发生切换后发送的报警的脚本
    secondary_check_script=/usr/bin/masterha_secondary_check -s wf1 -s wf2
    #shutdown_script=""  　　##设置故障发生后关闭故障主机脚本
    ssh_user=root   　　##设置ssh的登陆用户名

    [server1]
    hostname=172.25.254.1
    port=3306

    [server2]
    hostname=172.25.254.2
    port=3306
    candidate_master=1    　　 ##手动设置语句，如果master挂掉，这个slave将自动切换成为master
    check_repl_delay=0　　　　##默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

    [server3]
    hostname=172.25.254.3
    port=3306
    no_master=1  　　　　##这个命令表示：这台服务器不会去争抢master 这个命令和上面的切换命名二选一添加
　　　　　　

               ##注意：服务器的服务名，必须由server default开始，如果更改的话，会报错。显示服务名，不对。

   masterha_check_ssh --help
   masterha_check_ssh --conf=/etc/masterha/app1.cnf   

   <1>需要生成密钥.配置SSH登录无密码验证:
    ssh-copy-id 172.25.254.4   　　##生成authorized_keys，然后发送到各个结点，使manager可以对各个节点进行免密登录
　　　　　　

   <2>发送密钥之前，需要删除之前的 .ssh/:
    在wf1，2，3上： rm -fr .ssh/
   <3>删除完之前的 .ssh/ 之后，在manager上，将生成的key发送到各个结点上：
    scp -r .ssh/ root@172.25.254.1(2,3):/root
   <4>在manager上分别连接各个结点，使其可以直接连接：
    ssh 172.25.254.1(2,3)

　　　　　　

   <5>直接连接后，再重新编译一下 ssh
   masterha_check_ssh --conf=/etc/masterha/app1.cnf

　　　　　　

   masterha_check_repl --conf=/etc/masterha/app1.cnf　　　　##检查整个复制的健康的状况
    ##有回出现新的报错，显示root用户访问被拒绝，因此，需要给root用户给与权限

　　　　　　

   <6>在master上更改权限，因为半同步复制，所有slave也会有。
   mysql -p
   mysql> grant all on *.* to root@'%' identified by 'Wang+1212';

　　　　　　

   <7>再次编译：
   masterha_check_repl --conf=/etc/masterha/app1.cnf  
    ##回出现新的一个报错，显示slave上可能没有repl这个用户，所以需要添加用户

　　　　　　

   <8>在master上更改权限，因为半同步复制，所有slave也应该有相应的用户存在。
   mysql -p
   mysql> grant replication slave on *.* to repl@'%' identified by 'Wang+1212';
   <9>再次在manager上编译：
   masterha_check_repl --conf=/etc/masterha/app1.cnf    ##编译完成
　　　　　　

（4）开启MHA Manager的监控
   nohup masterha_manager --conf=/etc/masterha/app1.cnf --ignore_last_failover &
   cd /etc/masterha/
   ls
   cat app1.master_status.health    ##查看健康状态启动参数介绍:

=========================================================================================
--remove_dead_master_conf      该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。

--manger_log                            日志存放位置

--ignore_last_failover                 在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failover。
    4538    0:PING_OK   master:172.25.254.1
========================================================================================

========================================================================================
(1)检查SSH配置
    masterha_check_ssh --conf=/etc/masterha/app1.cnf 检查MHA Manger到所有MHA Node的SSH连接状态
(2)检查整个复制环境状况:
   通过masterha_check_repl脚本查看整个集群的状态
========================================================================================

（5）手动在线切换master

下面的操作是：在master没有出现问题的时候，手动执行命令将master手动切换到另一个slave上。

   masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=172.25.254.2 --new_master_port=3306 --orig_master_is_new_slave
    It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 172.25.35.52(172.25.35.52:3306)? (YES/no): YES
    Starting master switch from 172.25.35.52(172.25.35.52:3306) to 172.25.35.54(172.25.35.54:3306)? (yes/NO): yes
    master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes
　　　　　　

   查看切换结果：（注意 原master为1，切换为了2）
   <1>在切换以后，登上数据库，因为切换了master，所以导致二进制文件内的事件，有不同，会报错。
   所以，要在三个服务器上，reset master 和 reset slave ，然后再开启slave。
   原本2是slave，在reset之后，show slave statusG; 就会显示没有slave的状态。

　　　　　　

（6）手动故障切换
   在master上：
   ps ax
   kill -9 把所有的相关进程杀掉
   　　　　　　

   在manager上：
    masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=dead --dead_master_host=172.25.254.2 --dead_master_post=3306 --new_master_host=172.25.254.1 --new_master_port=3306
    Master 172.25.35.54(172.25.35.54:3306) is dead. Proceed? (yes/NO): yes
    Starting master switch from 172.25.35.54(172.25.35.54:3306) to 172.25.35.52(172.25.35.52:3306)? (yes/NO): yes
　　　　　　

   在原本是master变成slave的主机上手动添加新的master的信息：
   mysql> change master to master_host='172.25.254.1',master_user='repl',master_password='Wang+1212',master_auto_position=1;
   mysql> start slave;
   mysql> show slave statusG;

  如果还是不行的话，将所有的slave 都reset一下，就好了。
　　　　　　
   查看切换结果：
　　　　　　

 （注意 原master为2，切换为了1）

 　　　　　　

（7）自动切换测试

   将manager的配置文件删除掉
   vim app1.cnf
    candidate_master=1    
    check_repl_delay=0
   rm -f mha.failover.complete　　##不删除的话，会故障切换不了。
   nohup masterha_manager --conf=/etc/masterha/app1.cnf --ignore_last_failover &　　　　##打入到后台运行
   ps ax
   kill -9 把所有的相关进程杀掉
  
  测试：会自动切换

（8）VIP