4. MHA FailOver过程详解 4.1 什么是Failover? 故障转移:主库宕机 一直到业务恢复正常的处理过程(自动) MHA 高可用,是针对物理故障进行处理。 4.2 Failover让你实现怎么做? (1) 快速监控到主库宕机(2) 选择新主 (3) 数据补偿 (4) 解除从库身份 (5) 剩余从库和新主库构建主从关系 (6) 应用透明,VIP (7) 故障节点自愈(待开发...) (8) 故障提醒 4.3 MHA的Failover如何实现? 从启动--->故障--->转移--->业务恢复 (1) MHA通过masterha_manger脚本启动MHA的功能. (2) 在manager启动之前,会自动检查ssh互信(masterha_check_ssh)和主从状态(masterha_check_repl) (3) MHA-manager 通过 masterha_master_monitor脚本(每隔ping_interval秒),实时监控。 (4) masterha_master_monitor探测到主库3次无心跳之后,就认为主库宕机了. (5) 进行选主过程,有 3 种算法。 算法一: 读取配置文件中是否有强制选主的参数? candidate_master=1 check_repl_delay=0 #不检查从库和主库之间的日志差异 默认情况下,如果这个slave落后master 100M的 relay log ,MHA 管理节点将不会选择 这个slave作为新的master,哪怕这个salve,在app1.cnf 配置文件中的server模块下面,添加了 强制选主的参数, 但是,可以通过 ,check_repl_delay=0 这个参数,可以不用去检查,这个日志差异。 算法二: 自动判断所有从库的日志量,将最接近主库数据的从库作为新主。 算法三: 按照配置文件先后顺序的进行选新主. 扩展: candidate_master=1 应用场景? MHA+KeepAlive VIP(早期MHA架构) 多地多中心 facebaook ---- MHA 淘宝-------TMHA(可以只有2台,一主一从) (6) 数据补偿 判断主库SSH的连通性 情况一: SSH能连 调用 save_binary_logs脚本,立即保存缺失部分的binlog到各个从节点,进行恢复。 情况二: SSH无法连接 调用 apply_diff_relay_logs 脚本,计算从库的relaylog的差异,恢复到2号从库 (6.1) 提供额外的数据补偿的功能 @@ (7) 解除从库身份 (8) 剩余从库和新主库构建主从关系 (9) 应用透明 @@ (10) 故障节点自愈(待开发...)@@ (11) 故障提醒@@ 5. MHA 应用透明(vip) dba04:(192.168.189.135) cp /root/master_ip_failover.txt /usr/local/bin/master_ip_failover vim /usr/local/bin/master_ip_failover my $vip = '192.168.189.155/24'; ### 这个IP必须是未被使用的。 my $key = '1'; my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip"; ## 这里是要和你提供服务的网卡对应 my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down"; yum install -y dos2unix dos2unix /usr/local/bin/master_ip_failover chmod +x /usr/local/bin/master_ip_failover vim /etc/mha/app1.cnf ##修改MHA配置文件,指定VIP 切换脚本 master_ip_failover_script=/usr/local/bin/master_ip_failover
dba02(master上):第一次,先手工添加vip (192.168.189.133) ifconfig eth0:1 192.168.189.155/24 dba04: 重启MHA (192.168.189.135) masterha_stop --conf=/etc/mha/app1.cnf
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 &
masterha_check_status --conf=/etc/mha/app1.cnf
6. MHA 故障提醒(192.168.189.135 dba04 上操作) 解压上传的软件包,里面的一个email_2019-最新.zip cd /root && unzip email_2019-最新.zip cp -a email/* /usr/local/bin/ cd /usr/local/bin/ chmod +x * +++++ 测试发邮件: cd /usr/local/bin vim testpl
sendmail 参数说明 : # -f from@163.com # 发件人邮箱地址 # -t to@qq.com # 收件人邮箱地址 # -s smtp.163.com # 发件人邮箱的smtp服务器地址 # -u 'test' # 邮件标题 # -xu from@163.com # 发件人邮箱登录用户名 # -xp 'passwd' # 发件人邮箱授权码 # -m 'test' # 邮件内容 ./testpl
vim /etc/mha/app1.cnf ## 修改配置文件,指定 发邮件的脚本 report_script=/usr/local/bin/send
重启MHA: masterha_stop --conf=/etc/mha/app1.cnf 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 & 7. 额外的数据补偿机制 (binlog_server) 本实验是用 dba04来当做 binlog server 设计理念:就是单独找一台服务器,实时的保存主库的二进制日志。 (1)找一台额外的机器,必须要有5.6以上的版本,支持gtid并开启,我们直接用的第二个slave(dba04) vim /etc/mha/app1.cnf [binlog1] no_master=1 hostname=192.168.189.135 master_binlog_dir=/data/mysql/binlog #### 这里的日志位置,不要与 mysql 的binlog 一致。 (2) 创建必要目录 mkdir -p /data/mysql/binlog chown -R mysql.mysql /data/* (3) 拉取主库binlog日志 cd /data/mysql/binlog -----》必须进入到自己创建好的目录 mysqlbinlog -R --host=192.168.189.135 --user=mha --password=mha789 --raw --stop-never mysql-bin.000001 &
注意: 生产环境中,拉取日志的起点,需要按照目前主库正在使用的binlog为起点. (4) 重启MHA-manager (dba04 192.168.189.135) masterha_stop --conf=/etc/mha/app1.cnf 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 & 8. 故障模拟及故障处理 8.1 宕掉 dba02主库 192.168.189.133 数据库 systemctl stop mysqld
![]()
8.2 恢复故障 (1) 启动故障节点 (原先的master,dba02 192.168.189.133) systemctl start mysqld (2) 恢复1主2从(dba02 192.168.189.133) dba04 slave2 上面进行过滤: [root@dba04 bin]# grep "CHANGE MASTER TO" /var/log/mha/app1/manager
登录原来的master ,dba02,192.168.189.133 CHANGE MASTER TO MASTER_HOST='192.168.189.134', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='repl520'; start slave;
![]()
(3) 恢复配置文件(dba04 192.168.189.135) vim /etc/mha/app1.cnf ### 把sever1的信息,添加进去。 [server1] hostname=192.178.189.133 port=3306 (4) 启动MHA (dba04 192.168.189.135) 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 & masterha_check_status --conf=/etc/mha/app1.cnf
(5)恢复binlogserver (dba04 192.168.189.135) 因为先前的主库down了,binlog server 也down了,现在新的主库是 slave1 ,所以 binlog server 要重新拉取 cd /data/mysql/binlog rm -rf /data/mysql/binlog/* ps -ef|grep mysqlbinlog kill -9 5839 ### 把原来的mysqlbinlog 的进程结束掉 mysqlbinlog -R --host=192.168.189.134 --user=mha --password=mha789 --raw --stop-never mysql-bin.000001 &
(2) 选择新主
(3) 数据补偿
(4) 解除从库身份
(5) 剩余从库和新主库构建主从关系
(6) 应用透明,VIP
(7) 故障节点自愈(待开发...)
(8) 故障提醒
4.3 MHA的Failover如何实现?
从启动--->故障--->转移--->业务恢复
(1) MHA通过
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 &
6. MHA 故障提醒
sendmail 参数说明 :
# -f from@163.com # 发件人邮箱地址
# -t to@qq.com # 收件人邮箱地址
# -s smtp.163.com # 发件人邮箱的smtp服务器地址
vim /etc/mha/app1.cnf
重启MHA:
masterha_stop --conf=/etc/mha/app1.cnf
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 &
注意:
8.2 恢复故障
(1) 启动故障节点 (原先的master,dba02 192.168.189.133)
(5)恢复binlogserver