134512

这份文档之所以要起134512这个名字，是因为在昨天（2023.9.22 13:45:12)SSE_MARKET发生一起重大事故。我知道后立刻进行排查，通过检查后端和数据库的日志，在mysql的gerneral log中发现了在13:45:12出现了怪异的删除语句，就是把帖子全部删除的语句，对应同一时刻，后端的日志中发现连续出现了多条删除帖子的请求。 一开始我们还以为数据库被攻击了，但是通过对比上面两个日志，最有可能是正常操作导致触发代码本身的问题。然后检查了一下对应代码： 实际上看到这段代码基本上确定就是代码本身出现了问题。代码非常简洁，也可以说非常潦草，没有必要的一些判断。后来Michale去模拟了一下用这个函数去删除本身就不存在的帖子，确定了确实会导致全部的帖子被删。至于这个代码是谁编写的也没必要去追责了，因为SSE_MARKET可以说是我们小组出于热情和为软工服务的贡献精神搞的，而且大家也是摸着石头过河，很难在一开始就考虑得很清楚。昨天我在A321跟旁边的研究生说了发生的事故，然后有一个师兄问我什么时候能修复。我说我也不确定，如果师兄能加入我们肯定能更快修复。然后一个师姐问我们有工资吗，我也如实回答，我们没有工资，做这个是出于纯粹的热情。当然，做这个还是有一点好处的，就是可以拿到志愿时。 回到正题，我们现在有两个任务：一是恢复数据，二是修复漏洞。

恢复数据

使用binlog日志恢复MySQL数据库删除数据的方法 - 知乎 (zhihu.com) [mysqlbinlog 恢复指定表_mob649e816347dd的技术博客_51CTO博客](https://blog.51cto.com/u_16175495/7202342#:~:text=如何使用mysqlbinlog恢复指定表？ 1 找到删除表数据的时间点或者binlog文件位置。 可以通过以下两种方式来确定： 如果知道删除表数据的时间点，可以通过查看binlog文件的内容来找到对应的位置。 可以使用 mysqlbinlog 命令来查看binlog文件的内容：,表的操作记录： mysqlbinlog –start-position%3D12345 –database%3Dmydb –table%3Dmytable %2Fpath%2Fto%2Fbinlog.000001 1. ) 可以定位到进行帖子删除是在binlog.000003的Pos217032开始的，不过还不能确定就是它。 3720678 命令：

mysqlbinlog --start-position=0 --stop-datetime='2023-09-22 13:54:00' binlog.000001 --database=ssemarket --table=posts 1.sql
mysqlbinlog --stop-datetime='2023-09-22 13:54:00' binlog.000001 --database=ssemarket --table=posts 1.sql
mysqlbinlog binlog.000002 --base64-output=decode-rows -v >1.sql
mysqlbinlog binlog.000001 -d ssemarket >1.sql
mysqlbinlog binlog.000002 --skip-gtids --short-form -d ssemarket -r 2.sql
mysqlbinlog binlog.000003 --skip-gtids --short-form -d ssemarket 3.sql
mysqlbinlog binlog.000003 -d ssemarket -r 37206783.sql
mysqlbinlog binlog.000001 --stop-datetime="2023-09-22 05:54:10" > 1.sql
mysqlbinlog binlog.000003 > 3.sql
mysqlbinlog binlog.000003 --stop-datetime="2023-09-22 13:54:10" > 3.sql
mysqlbinlog binlog.000003 --stop-datetime="2023-09-22 05:54:10" > 3.sql
mysqlbinlog binlog.000003 --stop-position=995720 > 3.sql
mysqlbinlog binlog.000002 > 2.sql
mysqlbinlog binlog.000004 > 4.sql
mysqlbinlog binlog.000005 > 5.sql
mysqlbinlog binlog.000006 > 6.sql
mysqlbinlog binlog.000007 > 7.sql
python binlog2sql/binlog2sql.py -h114.132.75.27 -P3506 -uroot -p'admin' -dssemarket -tposts --start-file='mysql-bin.000003' --start-datetime='2023-09-22 13:54:00' --stop-datetime='2023-09-22 13:55:00' > raw.sql
python binlog2sql/binlog2sql.py -h114.132.75.27 -P3506 -uroot -p'admin' -dssemarket -tposts --start-file='mysql-bin.000003'> raw.sql
mysqlbinlog binlog.000001  mysql -u root -p
mysqlbinlog binlog.000002  mysql -u root -p
mysqlbinlog binlog.000003  mysql -u root -p
mysqlbinlog binlog.000004  mysql -u root -p
mysqlbinlog binlog.000005 binlog.000006  mysql -u root -p
mysqlbinlog binlog.000007  mysql -u root -p
mysqlbinlog binlog.000007  mysql -u root -p
mysqlbinlog binlog.000001 binlog.000002 binlog.000003 --stop-datetime="2023-09-22 13:50:00"  mysql -u root -p
mysqlbinlog binlog.000001 binlog.000002 mysql -u root -p

发现自带sh没有mysqllogbin，决定拷贝到windows，曲线救数据库！ 发现binlog的时间非常怪异，居然和general logs的时间对应不上。好吧，并不是，是我神志不清了。