摘要：
通常，我们的主数据库binlog只保留7天。如果从属数据库故障超过7天且数据未同步，则主从架构将异常，需要重建主从架构。
通常情况下我们主库的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查看整个集群的状态，如下图：
可以看出我们已经正常的恢复了我们的集群，再也不用担心从库全部挂了！！！