目前发现，在删除回收站文章时，有可能导致整个contents表被清空！目前判断是数据库组件bug，具体还需要进一步确认。

因此请不要通过后台删除回收站文章，并且从现在开始将mysql数据库调整为binlog开启状态，并且设为row模式，并且创建定时备份任务，以防数据丢失！

若有人因此导致数据丢失，尽量不要再对数据库进行写入操作，且检查my.cnf是否开启log-bin。若未开启，请联系专业数据恢复公司；若已开启，请将bin-log文件备份出服务器，并尝试解析出还原的sql语句。注意：mixed模式无法直接还原删除的闪回sql，因此只能重新执行一次sql以达到还原的目的。

具体的恢复方式如下，请大家进行参考（本人亲测可用）。lnmp脚本就是默认开启bin-log并为mixed模式，因此使用lnmp脚本安装的用户，可直接使用分享的方法。

注意，如果你没有开启binlog，或者mixed模式下没有近期备份，很有可能无法完全恢复或者根本不能恢复。此方法适用于row模式或者有近期备份（数据在1000条变动以内最佳）的情况。

1. 通过终端命令登录mysql

一切都是以你为服务器管理员（有root权限）为基础，如果你是在虚拟主机上，很遗憾，你只能尝试获取自动备份或者是联系服务器管理员恢复。

mysql -uroot -p

输入密码登录。

2. 查看binlog文件

在mysql控制台（也就是登录后的界面），输入

show master status;

会显示类似的结果如下：

+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000051 |       967 |
| mysql-bin.000052 |       965 |
+------------------+-----------+

3. 最新的binlog文件是mysql-bin.000052，我们再定位误操作SQL的binlog位置。误操作人只能知道大致的误操作时间，我们根据大致时间过滤数据。

注意，从这里开始，row模式和mixed模式会有区别。

row模式，请直接开始按照 https://blog.csdn.net/u013421629/article/details/79045292 的教程去做；mixed模式请继续按照本教程。

因为mixed模式可能不会记录删除每一行的记录，所以无法实现闪回（flashback）功能。这就需要我们根据备份的sql和binlog进行分析，到底从备份时间开始到误操作前，有哪些sql的变动。讲到这里，熟悉mysql的小伙伴大概就知道怎么做了。这里为了照顾不太熟悉sql的小伙伴，我们讲得再详细一些。

首先我们需要下载binlog2sql，执行以下命令：

git clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sql
pip install -r requirements.txt

缺啥补啥，这里就不详细说了。然后是导出sql记录，执行以下命令，前面的参数与mysql登录相似，照用就行了。在mixed模式下，--database和--table的过滤可能无效，因此会影响到其他的数据库，所以如果你的数据库有其他网站的内容，请务必备份好，然后在操作之后恢复回去。start-datetime和stop-datetime按照你想恢复数据的区间来定，注意结束时间千万不要超过你误操作的时间点，否则再执行一次你的数据还是空的。至于怎么知道开始时间，你的备份sql创建时间就是开始时间了。

python binlog2sql/binlog2sql.py -h 127.0.0.1 -P 3306 -u root -p xxxxxx --database='blog' --table='contents' --start-file='mysql-bin.000052' --start-datetime='2020-9-4 00:00:00' --stop-datetime='2020-11-28 01:20:00' > /root/backup.sql

最后，把原先备份的最新sql导入到数据库（可把现在的数据库备份后清空，再导入，以免数据重复），然后再把/root/backup.sql导入到数据，完成！

检查一下数据完整性，然后，以后记得经常备份！

如果你也遇到了数据丢失的问题，通过上面的方法还是不能恢复，请在评论区进行留言，尽量为你解答。但是！重要的数据请不要自己折腾，最好请专业恢复人员，否则折腾完了再补救已经迟了！