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

发布时间：2023-09-08 14:46:12 所属栏目：MySql教程来源：

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

（编辑：聊城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!