mysql数据恢复

1.前言

演示通过mysql全备+binlog日志恢复误删的某库数据，前提是数据需要开启binlog，需要有定时全备文件，一般在访问流量低的时候进行全备，以免影响业务的正常，全备操作可参考https://blog.youkuaiyun.com/ApexPredator/article/details/129303794?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22129303794%22%2C%22source%22%3A%22ApexPredator%22%7D

2.数据删除过程

在上午某个时间点误执行了drop命令删除了test库

drop database test；

3.误删除后需要进行的操作

3.1执行删除命令后需要快速执行刷新binlog日志操作

flush logs;

3.2报告领导，发布数据库故障通告

3.3使用全备文件和binlog日志进行数据恢复

4.数据恢复操作过程

4.1解压全备文件

gzip -d full_20230306000000.sql.gz

4.2将全备数据导入测试库

mysql -u 用户名 -p 密码 < full_20230306000000.sql #或者在数据库中执行source /opt/full_20230306000000.sql

4.3此时测试库中已经有了截至00点之前的所有数据，只差00点到上午删库节点之间的数据，此部分数据通过binlog文件恢复

4.4查看full_20230306000000.sql可以得知00点之后记录数据的binlog文件和pos起点

vim full_20230306000000.sql

通过上图可知00点后记录数据的binlog文件名称是mysql-bin.000033，pos起点是154

4.5查看数据库现在记录数据的binlog文件名称

mysql -u 用户名 -p 密码

show master status;

4.6因为删库后执行了flush logs刷新了binlog文件，所以记录drop命令是在mysql-bin.000033文件中，查找drop命令的前一个pos点作为数据恢复的结束点，若是以drop命令的pos点作为结束点，则在数据恢复中又会执行drop这个命令

find / -name mysql-bin.000033

#查看mysql-bin.000033文件，且筛选drop database test这个命令，且查看这行输出的前八行

mysqlbinlog /var/lib/mysql/mysql-bin.000033 |grep -i -B 8 "drop database test"

如上图所示，drop命令的结束点是873，所以取783作为数据恢复的pos结束点

4.7将binlog数据倒出为sql文件

mysqlbinlog --start-position=154 --stop-position=783 /var/lib/mysql/mysql-bin.000033 > /opt/logdb.sql

#也可以使用此条命令直接导入到测试库中 mysqlbinlog --start-position=154 --stop-position=783 /var/lib/mysql/mysql-bin.000033 | mysql -u 用户名 -p 密码

4.8将binlog导出的sql文件恢复到测试库中

mysql -u 用户名 -p 密码 < /opt/logdb.sql

4.9至此测试库的数据已恢复到删库前的数据，将需要的库从测试库导出

mysqldump -u 用户名 -p 密码 test > /opt/test.sql

4.10将测试库导出的sql文件导入生产库即可

#mysqldump导出单库中是不包含创建库的命令，在导入数据库前要先创建库

mysql -u 用户名 -p 密码

create database test;

use test;

source /opt/test.sql;