记一次线上mysql主从架构异常的恢复经历

前提:之前一位同事负责的一位客户,因后期转到devops小组。所以将此用户交接给我,在后期发现有一套数据库主从环境,从库已经无法正常使用。查看slave 状态为:

其中:
Master_Log_File:#此处显示的bin-log已经在master上找不见了
Read_Master_Log_Pos:#显示的行数也就存在没有意义了
Slave_IO_Running:NO #salve io进程显示为no,无法从master同步数据
因此判定从库已经无法使用,需要及时修复。保证主从架构正常使用。

以下是恢复的全部过程:
##########################################################

主要思路:
1、在不锁表的情况下备份master数据库的所有数据文件
2、将slave数据库进程停掉。并将备份文件从master传输到slave端,解压
3、重新执行 change master设置bin-log文件名称,和position

##########################################################

一、在数据库的Master端使用percona-xtrabackup进行文件级别的数据库备份。

在master数据库执行下面命令:(需要根据实际情况修改)
innobackupex --defaults-file=/etc/my.cnf --user=root --password=51idc --no-lock --use-memory=4G --compress --compress-threads=8 --stream=xbstream --parallel=4 /backup > /backup/$(date +%Y-%m-%d_%H-%M-%S).xbstream

注意:其中
1、/backup这个目录可以自定义,他代表备份文件存放的位置。
2、/etc/my.cnf这个文件是数据库启动时读取的默认配置文件,需要根据实际情况进行修改;我这边使用的是/etc/my.cnf
3、修改数据库连接密码
4、--no-lock代表不锁表进行备份,保证线上业务正常运行的同时进行数据备份。

这个操作时间依据数据量的大小,我自己备份花费了30min左右(130G数据)。备份完成后出现一个文件:
2019-02-27_11-12-21.xbstream

二、在数据库的slave端使用命令进行恢复数据,因为在恢复之前需要保证主从数据库的数据一致,但是之前因为从数据库很久都没有同步master的数据了,因此目前主从数据量差的较多。

a、需要先停掉数据库
/etc/init.d/mysql stop #停掉数据库
b、删除之前的数据文件,默认在/var/lib/mysql下;删除mysql目录下的所有文件,因为接下来我们需要将备份数据解压到此目录下。
c、在slave数据库的机器上执行两次解压操作,将备份文件解压到本地。

xbstream -x < /backup/2019-02-27_11-12-21.xbstream -C /backup/2019-02-27_11-12-21
innobackupex --decompress --parallel=4 /backup/2019-02-27_11-12-21
d、删除所有以 .qp结尾的文件
find /backup/2019-02-27_11-12-21 -name "*.qp" -delete
e、创建完备份之后数据被没有马上可以被还原,需要回滚未提交事务前滚提交事务,让数据库文件保持一致性。
innobackupex使用—apply-log来做预备备份
--user-memory:指定预备阶段可使用的内存,内存多则速度快,默认为10MB

innobackupex --apply-log --use-memory=4G /backup/2016-03-16_15-25-55

f、再将还原的数据文件拷贝到/var/lib/mysql目录下,其中/var/lib/mysql目录在/etc/my.cnf文件中指定的datadir

innobackupex --defaults-file=/etc/my.cnf --copy-back --use-memory=4G /backup/2019-02-27_11-12-21
此过程需要的时间较长,我这边还原大概是2H左右。还原完成后,在/var/lib/mysql目录下有两个文件,可以看到salve目前保存的最近的bin-log文件和position

若出现找不到qpress命令的报错可以安装repo.percona源后使用 yum -y install qpress 进行安装
repo.percona源安装命令:
yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

g、修改/var/lib/mysql的属主属组
chown -R mysql.mysql /var/lib/mysql

h、启动数据库;
/etc/init.d/mysql start

I、重做主从配置
mysql -uroot -p #进入到数据库内
change master to master_host=‘主xxx.xxx.xxx.xx‘,master_port=3306,master_user=‘root‘,master_password=‘51idc‘,master_lo_file=‘master-bin.xxx‘,master_log_pos=xxx;

其中:master IP 、master_password根据实际情况确定。
bin-log日志文件名、master_log_pos的位置需要在这两个文件中查看。

h、启动slave
mysql> start slave;

j、查看slave状态:
mysql> show slave status\G;

可以看到从数据库slave的Slave_IO_Running: Yes、Slave_SQL_Running: Yes均是yes
并且有了新的bin-log文件和position位置了。后面就可以正常工作,进行主从同步了。

原文地址:https://blog.51cto.com/12476193/2356200

时间: 2024-11-07 06:12:05

记一次线上mysql主从架构异常的恢复经历的相关文章

记一次线上MySQL数据库死锁问题

最近线上项目报了一个MySQL死锁(DealLock)错误,虽说对业务上是没有什么影响的,由于自己对数据库锁这块了解不是很多,之前也没怎么的在线上碰到过.这次刚好遇到了,便在此记录一下. 出现死锁问题背景 项目层面:报错的项目做的是一个批量下单的动作,会同时写入多条订单数据,代码之前写的是一个事务中一个循环一条一条insert到数据库(至于为啥没用批量插入就不追究了,历史原因了). 数据库层面:一张test表(非线上真实表),比较重要的是有一个 type 和 name的唯一索引. 事务隔离级别:

mysql-poxy 实现mysql主从架构读写分离

在高并发系统设计中,后端数据库的性能往往会成为系统的瓶颈,这时候就需要进行合理的设计,以分摊后端数据库的压力,比如在数据层前面构建缓存层.数据文件存放在RAID这样的设备.对数据进行分库分表分区存放.合理利用索引.进行数据的读写分离等.mysql-proxy提供了mysql数据库的读写分离能力,mysql-proxy通过Lua脚本能分析得出用户的sql请求,如果发现在是read请求,则会转化到master-slave模型的slave中,如果是write请求,则会转发到master中,以达到读写分

MySQL主从架构之Master-Slave主从同步

MySQL复制 MySQL复制是指将主库上的DDL和DML操作通过二进制日志传到从库上,使主库和从库上的数据保持同步 MySQL主从架构:优点:故障时候可以切库:读写分离:从库执行其他业务例如备份. 1:Master-Slave    主从同步 2:Master-Slave-Slave……级联 3:Master-Master   互为主备 [主从同步]Master-Slave 注:需要主库打开log-bin ;设置server-id #mysqldump -uroot -p --all-data

MySQL 主从架构配置详解

无论是哪一种数据库,数据的安全都是至关重要的,因此熟练掌握数据库的安全备份功能,是作为开发人员,特别是后端开发人员的一项必备技能.MySQL 数据库内建的复制功能,可以帮助我们对数据进行异地备份,读写分离,在较大程度上避免数据丢失.数据库服务器压力过大甚至宕机带来的损失. 使用MySQL 主从架构一年多了,想起当年学习这些东西的时候,苦于完整的中文资料比较少,当时英文又不太好,遇到不少问题.刚好最近也有一段时间没更新博客了,心血来潮,决定翻译一下 MySQL 官网的英文文档,官网文档讲解的非常详

MySQL主从架构详解

1.复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

使用Innobackupex快速搭建(修复)MySQL主从架构

MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一.但对于较大的数据库则该方式并非理想的选择.使用Xtrabackup可以快速轻松的构建或修复mysql主从架构.本文描述了使用innobackupex快速来搭建或修复主从架构.供大家参考. 1.基于主库做一个完整备份 # mkdir -p /log/bakforslave # innobackupex --user=root -password=*** --socket=/tmp/mysql.sock --def

使用innobackupex基于从库搭建mysql主从架构

?? MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一.但对于较大的数据库则该方式并非理想的选择.使用Xtrabackup可以快速轻松的构建或修复mysql主从架构.本文描述了基于现有的从库来快速搭建主从,即作为原主库的一个新从库.该方式的好处是对主库无需备份期间导致的相关性能压力.搭建过程中使用了快速流备份方式来加速主从构建以及描述了加速流式备份的几个参数,供大家参考. 有关流式备份可以参考:Xtrabackup 流备份与恢复 1.备份从库###远程备份期间

mysql主从同步异常原因及恢复syncnavigator

mysql数据库做主从复制,不仅可以为数据库的数据做实时备份,保证数据的完整性,还能做为读写分离,提升数据库的整体性能.但是,mysql主从复制经常会因为某些原因使主从数据同步出现异常.因此,下面介绍的是mysql主从同步异常的原因及恢复的方法. 这个问题是在部署主从复制的时候,可能会遇到的 回到顶部 Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL s

线上MYSQL同步报错故障处理总结(转)

前言 在发生故障切换后,经常遇到的问题就是同步报错,数据库很小的时候,dump完再导入很简单就处理好了,但线上的数据库都150G-200G,如果用单纯的这种方法,成本太高,故经过一段时间的摸索,总结了几种处理方法. 生产环境架构图 目前现网的架构,保存着两份数据,通过异步复制做的高可用集群,两台机器提供对外服务.在发生故障时,切换到slave上,并将其变成master,坏掉的机器反向同步新的master,在处理故障时,遇到最多的就是主从报错.下面是我收录下来的报错信息. 常见错误 最常见的3种情