MySQLBinLog:MySQL被删库后恢复

原文:https://hudaye.work/index.php/archives/115/

前言

本文章只适用于以下情况

  • 有数据库完整备份
  • 完整备份至少需要包含迁移到被删服务器前的数据
  • 服务器性能较好

接下来解释一下,首先,我们需要一个完整备份(如果你的数据不是原生在被删服务器上而是从别的服务器迁移来的话),服务器性能需要较好,因为需要执行大量SQL语句。

步骤

1.查看日志

被删了,不要慌,先打开日志看一看。根据宝塔配置文件,我们可以找到日志文件目录(该目录内记录了除查询语句以外的所有语句执行日志)
配置配置
所以我们可以找出日志文件在/www/server/data/目录,所以执行如下shell命令即可查看所有日志。

cd /www/server/data/
ls

配置文件配置文件
如图,mysql-bin.xxxxxx即为配置文件,这样我们就可以取得配置文件名,为下一步做准备。
接下来执行mysql -p以root身份登入SQL服务器
root密码root密码
root密码可在上图部分修改
为了便于查看,执行flush logs;(分号带上)可以让SQL服务器向下个文件写入日志,而不会继续刷新当前最后一个日志文件,便于我们浏览数据。
如图如图
接下来执行show binlog events in 'mysql-bin.0000xx';(文件名为上图ls后的最后一个日志文件)
如图如图
找到被执行的DROP语句,记录下最后第三个|前的数字,如158144,接下来恢复时要用,好了,对日志的分析到此为止。

2.恢复数据

接下来,登出SQL服务器, 进入/www/server/data/目录,然后执行cp /www/server/mysql/bin/mysqlbinlog mysqlbinlog将日志读取工具cp到该目录,然后执行

./mysqlbinlog mysql-bin.日志数 --database=数据库名 --stop-position=上面记录的数字-1 | mysql -p 数据库名

注:如果不是恢复最后一个日志的内容,无需指定–stop-position(因为最后一个日志包含攻击者的DROP语句,如果不指定将会重复删库)
执行执行
恢复恢复
可以看到,执行后我们的表回来了。
注:数字不同是因为上个日志又过长了,所以我切换了一下日志,演示环境与真实环境有所不同。

最后

该日志只是记录了所有对数据库的操作,所以如果不想太麻烦的话还是需要有一份完整备份,然后再用该日志恢复近日的操作。
如果有任何问题欢迎Telegram@kaguyacloud 如果不是大问题的话可以提供无偿指导,觉得有用也可以赞赏一下。
参考文章1 参考文章2
以上文章写的也很精彩,不过目录和宝塔未对应,所以我写了这篇文章来适配一下宝塔。

因为想尽快为大家带来教程,所以编写较为仓促,如有疏漏,欢迎提出,非常感谢!