MHA架构软件结构说明

节点规划

数据库节点必须是一主两从独立实例，
MHA的管理节点最好是一台独立的机器

mha.png

MHA的软件构成

manager工具主要包括以下几个工具

masterha_manager     启动mha
masterha_check_ssh   检查mha的ssh配置状况
masterha_check_repl   检查mysql的复制状况
masterha_master_monitor  检查master是否宕机
masterha_master_switch  控制故障转移（自动或手动）
masterha_conf_host  添加或删除配置的server信息

Node工具软件

save_binary_logs  保存和复制master的二进制日志
apply_diff_relay_logs  识别差异的中继日志事件将差异事件应用于其他的
purge_relay_logs     清除中继日志（不会阻塞SQL线程）

MHA 配置过程细节说明

软连接

ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql  /usr/bin/mysql
# 这是为了让MHA调用命令，MHA并不能走环境变量

配置互信

主库宕机了，从库没有追上主库日志，需要ssh连上主库，获取二进制日志。以补全数据

配置文件说明

一套manager可以管理多套应用，通过配置文件区分不同的业务

[root@db03 ~]# cat /etc/mha/app1.cnf 
[server default]       # server端的默认配置
manager_log=/var/log/mha/app1/manager        #manager程序的日志
manager_workdir=/var/log/mha/app1               #manager日志的目录
master_binlog_dir=/data/binlog       #主库二进制节点的位置
user=mha                             #     mha的管理用户   
password=mha                               
ping_interval=2           #探测心跳时间（如果3次ping不通，就认为主库宕机默认3次）
repl_password=123       # 复制用户相关的信息
repl_user=repl
ssh_user=root                   #配置互信的用户            
[server1]                            #后端节点         
hostname=10.0.0.11
port=3306                                  
[server2]            
hostname=10.0.0.12
port=3306
[server3]
hostname=10.0.0.13
port=3306

状态检查

masterha_check_ssh  --conf=/etc/mha/app1.cnf
masterha_check_repl  --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.cnf  2>&1 &
# --conf  指定使用哪个配置文件
# --remove_dead_master_conf:  当主库宕机时，自动在配置文件中将宕机主库去掉
# --ignore_last_failover： 忽略上一次切换，mha自动切换有保护机制，在第一次切换成功后。多少时间内，不能再次进行故障切换

什么是failover

故障转移，主库宕机一直到业务恢复正常的处理过程

自己如何实现failover

• 快速监控主键宕机 mysqladmin ping（可以）
• 选择新主
• 数据补偿
• 解除从库
• 重新构建主从关系
• 应用透明VIP
• 故障节自愈
• 故障提醒

MHA如何是的的failover

• masterha_manager 启动MHA的功能
• 在manager 启动之前，会先自动进行互信masterha_check_ssh和主从复制检查masterha_check_repl
• MHA-manager节点是通过masterha_master_monitor脚本检测主库状态的(每隔ping_interval秒)
• masterha_master_monitor探测主库3次，无心跳之后，就认为主库宕机了
• 进行选主
  算法一

读取配置文件中是否有强制选主的参数
candidate_master=1 强制选主
check_repl_delay=0 从库延时不检查
都在server标签下设置，如果只设置candidate_master=1这个参数，当选主时，会自动进行从库延时检查。如果这个从库延时过大，比如超过100M，就不选这个从库为主了

应用场景

1.早期的MHA+Keepalive
Keepalive只能负责主和备的VIP漂移，而MHA的VIP漂移是到两个从库。不确定往哪个从库漂
2.多地多中心
将此参数放于最接近运维的server标签下，方便出现故障。运维能快速过去解决

算法二

如果配置文件中没有配置参数，就根据两个从库的哪个数据最接近主库，就选哪个

算法三

如果两个主库日志量一致，就根据配置文件中server标签的顺序

• 数据补偿
  判断ssh联通性
  情况一:ssh能连

调用save_binary_logs 脚本，立即保存缺失部分的binlog，到各个节点恢复

情况二:ssh不能连

调用apply_diff_relay_logs脚本计算从库的relaylog差异，恢复到2号从库

为什么要用GTID

因为在数据补偿阶段，在对比binlog差异。如果没有gtid，会花费很长的时间。有了gtid花费资源更少，减少故障切换时间

• 解除从库关系
• 重新构建主从关系
• 进行切换
  配置VIP

cp master_ip_failover  /usr/local/bin
vim /usr/local/bin/master_ip_failover
my $vip = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";

chmod +x /usr/local/bin/master_ip_failover
vim /etc/mha/app1.cnf
[server default]
master_ip_failover_script=/usr/local/bin/master_ip_failover
**主库**
`ifconfig ens33:1  10.0.0.55/24`

• 配置故障提醒

cp -r email /usr/local/bin
chmod +x /usr/local/bin/send
send 为发送邮件报警指令
vim /etc/mha/app1.cnf
report_script=/usr/local/bin/send

额外的数据补偿

由于当ssh不能连时，会导致数据丢失。
设计理念：找一台机器，实时保存主库的二进制日志文件。必须是5.6以上的版本，支持GTID。这里我们直接用db02

[binlog1]
no_master=1        #不参与选主
hostname=10.0.0.13   #本机的ip地址
master_binlog_dir=/data/mysql/binlog  #保存主库的binlog到什么位置，注意不能和主库位置一样
。因为这是主从，应该单独保存主库的binlog
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/
mysqlbinlog -R --host=10.0.0.11 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &   拉取二进制日志

重启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

测试

主库
systemctl stop mysql
结果
故障报警未实现

故障恢复

• 启动故障节点
• 恢复一主两从

[root@db03 binlog]# grep -i 'change master to' /var/log/mha/app1/manager
Sun Apr  5 17:36:33 2020 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.0.12', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';

• 故障库执行

mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.12', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
Query OK, 0 rows affected, 2 warnings (0.02 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

• 恢复mha的配置文件

vim /etc/mha/app1.cnf
[server1]  添加到配置文件
hostname=10.0.0.11
port=3306
[binlog1]    移动最后面
hostname=10.0.0.13
master_binlog_dir=/data/mysql/binlog
no_master=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 &
• 启动binlogserver

rm -rf /data/mysql/binlog
mysqlbinlog -R --host=10.0.0.12 --user=mha --password=mha  --raw  --stop-never mysql-bin.000001 &

MHA的binlog server 为什么能实时保存成功，而不像从库有延时

因为主库commit时，一方面要往本地写入binlog，而是往远程的binlog server写入binlog，只有这两个执行成功，才会commit成功
MHA进行切换时，当主库连不上，才会去找binlog server ？？？

MHA故障排查

• 搭建过程中排查

1 .masterha_check_ssh 和 masterha_check_repl检查必须要过
2 .检查配置文件
节点配置不对地址和端口
vip 和 发送邮件 脚本，指定位置和权限
3 .软连接
mysqlbinlog 和 mysql

• 切换过程中的问题

查看/var/log/mha/app1/manager 日志文件 一般脚本问题多一些

• 恢复MHA故障

1 .检查各个节点是否启动成功
2 .找到主库是谁show slave status\G
3 .恢复一主两从
4 .检查配置文件
5 .检查vip 和binlog server

• 恢复过程

1 .检查vip是否在主库上，如果不在需要手动调整
2 .重新开始binlog server，拉取现有的主库日志
3 .启动manager

GTID补充说明

当500G大数据做主从时，应该怎么做？
1 .先进行XBK物理备份
2 .在从库进行恢复
因为GTID是逻辑的，物理备份XBK恢复时，并没有执行--set-purge-gtid，所以从库没有记录GTID
解决
1 .手动进行set-purge-gtid
2 .在从库change master to 中 master_auto_positon=1 改为从库的binlog中最后一个GTID+1 ，比如master binlog中最后一个GTID是10000，则从库 master_auto_position=10001,在XBK的binlog中查看GTID，是否和主库的一样。
平时
master_auto_positon=1,只从第一个gtid来进行备份，只不过在mysqldump主库数据时，已经自动加入了参数set-purge-gtid，所以从库执行change master to就自动跳过备份文件中已有的gtid了

GTID主从监控

show slave status\G;
  Retrieved_Gtid_Set:     # 已接收到的GTID，relay log中读到的
  Executed_Gtid_Set:   #已经执行到的GTID