今天手残导入数据把生产的库给覆盖掉了,瞬间傻了,写篇文章祭奠下二傻操作。
生产环境是用宝塔部署的,现在都还怀疑是宝塔的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
妥妥的好了,下边就是漫长的等待了,静静坐等他恢复完成。。。。