MySQL binlog 恢复数据

今天手残导入数据把生产的库给覆盖掉了，瞬间傻了，写篇文章祭奠下二傻操作。

生产环境是用宝塔部署的，现在都还怀疑是宝塔的bug引起的，明明新建了数据库，导入到新库，结果导入到了正在使用的生产库，引起这个的原因只能是1、sql里指定了数据库；2、宝塔的bug；排除了1，只能是2了，可没有勇气再去验证下，如果哪位小伙伴也遇到过，回复下，验证下是否是宝塔的bug

下边的一顿神操作，耗时10小时，果然傻事儿是要付出代价的

1、首先看mysql的 binlog是否开启，很可惜，宝塔默认安装的mysql binlog是默认开启的

查看sql        show variables like 'log_bin%';

2、查看mysql版本    show version();

我的mysql是 5.7.32-log

3、进入服务器的数据目录    cd /www/server/data/

4、ls -alth

5、我的服务器 没有安装mysqlbinlog 命令  所以执行 mysqlbinlog --no-defaults mysql-bin.000010 | less    返回的全是enter

6、安装mysqlbinlog  http://ftp.jaist.ac.jp/pub/mysql/Downloads/MySQL-5.7/mysql-5.7.31-linux-glibc2.12-x86_64.tar   

7、安装好后就可以执行恢复命令了  mysqlbinlog --stop-position=135015468 mysql-bin.000010| mysql -uroot -p

执行命令后报了主键冲突，需要把数据里的数据都清掉，记着一定是清表数据，千万别把库删掉。。

8、清完数据后再执行恢复命令  mysqlbinlog --stop-position=135015468 mysql-bin.000010| mysql -uroot -p

执行后又是外键冲突，用Navicat 把表的外键去掉

9、再次执行恢复命令终于好了  mysqlbinlog --stop-position=135015499 mysql-bin.000010| mysql -h 127.0.0.1 -uroot -p

mysql-bin.000010 的数据恢复了，在来恢复mysql-bin.000011的

10、由于mysql-bin.000011  太大298MB ，找点不好找，后来想着用时间点来恢复

执行命令  mysqlbinlog --stop-datetime='2021-04-23 14:00:00' mysql-bin.000011| mysql -h 127.0.0.1 -uroot -p

11、执行到半截，由于触发器的表主键冲突，恢复终端了，只报出了多少行的错，这下傻了，恢复了半截，这咋整，先想到的是这个行数可以按照点位来算，于是执行命令

执行命令  mysqlbinlog --start-position=2763613 --stop-datetime='2021-03-29 01:00:00' mysql-bin.000011| mysql -h 127.0.0.1 -uroot -p

结果总报内存不足的错

 

12、后来想想，不能在重新恢复吧，突然想起表里边的create_time字段，看了下，应该用这个时间，从这个时间开始执行，就ok了

执行命令  mysqlbinlog --start-datetime='2021-03-29 01:00:00' --stop-datetime='2021-04-23 14:00:00' mysql-bin.000011| mysql -h 127.0.0.1 -uroot -p

 

妥妥的好了，下边就是漫长的等待了，静静坐等他恢复完成。。。。