码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2017-10-13 19:15:17      阅读:187      评论:0      收藏:0      [点我收藏+]

标签:处理   数据   content   mysq   最新   执行命令   err   直接   mys   

通常情况下我们主库的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 -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 status\G;

 

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

 

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

技术分享

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

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

标签:处理   数据   content   mysq   最新   执行命令   err   直接   mys   

原文地址:http://www.cnblogs.com/davygeek/p/7662415.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!