基于GTID的主从架构异常处理流程

通常情况下我们主库的binlog只保留7天，如果从库故障超过7天以上的数据没有同步的话，那么主从架构就会异常，需要重新搭建主从架构。 

本文就简单说明下如何通过mysqldump主库的数据恢复从库的主从架构

下面就以我们在线上业务中实际遇到的情况做个简单说明

本文就以以下集群为例:

主库: 192.168.38.249

从库: 192.168.38.230, 192.168.36.175

主从模式: 开启GTID 基于Auto_Position模式复制

状态： 主库正常，从库都延迟过多，报错"Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'"

说明: 本文使用的连接mysql的方式都是通过--socket,大家使用可以根据自己的实际情况修改成自己的方式。

1.备份主库数据

登录机器使用mysqldump备份数据库

#备份数据 需要增加参数--master-data=2
mysqldump --socket=/export/dataroot/vt_data/mysql.sock --master-data=2 --single-transaction -uvt_dba vt_db > vt_db.sql
 
#备份完成之后将备份好的数据拷贝到从库机器上，准备恢复时使用
 
#传文件脚本
#把备份文件传到中间机器再抓发下，如果机器网络通也可以直接传过去
#scp vt_db.sql root@192.168.69.122:/export/.trash/
 
#反向传递
#scp root@192.168.69.122:/export/.trash/vt_db.sql vt_db.sql

2.恢复从库

登录从库机器，上一步已经把备份的文件上传到从库机器上，下面我们就准备通过执行命令恢复

#登录mysql
mysql --socket=/export/dataroot/vt_data/mysql.sock -uvt_dba -Dvt_db
 
#更新数据并且重新建立主从关系
#操作说明
# stop slave 停止主从复制
# reset slave 重置主从复制关系
# reset master重置从库的master这里是清楚自己本身的binlog这个很重要
# source /vt_db.sql 恢复数据
# change master to master_auto_position=1设置主从信息
# start slave开启主从复制
stop slave;reset slave;reset master; source /vt_db.sql;change master to master_auto_position=1;start slave;
 
#查看主从关系
show slave statusG;

恢复完了之后最好马上备份下刚恢复的数据，这样如果新增加机器就有最新的备份数据了

192.168.36.175的恢复同理，恢复完成之后可以通过orc查看整个集群的状态，如下图：

可以看出我们已经正常的恢复了我们的集群，再也不用担心从库全部挂了！！！