线上mysql主从架构恢复异常案例分析

本文主要给大家介绍线上mysql主从架构恢复异常案例分析，文章内容都是笔者用心摘选和编辑的，线上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位置了。后面就可以正常工作，进行主从同步了。

看完以上关于线上mysql主从架构恢复异常案例分析，很多读者朋友肯定多少有一定的了解，如需获取更多的行业知识信息 ，可以持续关注我们的行业资讯栏目的。