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
网友评论