背景是客服反馈有数据被清理掉了，开始追溯日志

查看mysql是否开启日志：

show variables like '%log%';

general_log开关

蛋疼general_log是关闭的，继续看二进制日志有没有开启，

二进制日志开关

好消息，二进制日志是开的

从docker进入该目录 docker exec -it ......,miamiamia~~~~~~

根据系统参数查看该目录下日志文件 并使用log_bin_basename 过滤一下(当然你可以不过滤直接看，文件也不是特别多)

cd  /var/lib/mysql

ls -ltrh|grep binlog

6个日志

看了一下日志，pm反馈昨天数据还有，那28号之前的日志可以放弃，简单看一下日志可以在Navicat里面看，数据量很大可以放弃，直接使用mysqlbinlog命令看，因为数据有上下关联关系，最好还是用命令转成文档看好一些

show binlog events in 'binlog.000006';

找到mysqlbinlog所在目录，因为是docker镜像 文件相对来说少一些，直接用find命令过滤一下,如果是mysql的镜像的话，应该有环境变量的设置可以跳过这一步直接使用该命令即可

find / |grep mysqlbinlog

mysqlbin所在目录

把二进制文件转为txt文本，

/usr/bin/mysqlbinlog --base64-output=DECODE-ROWS -v binlog.000006 > mysqlbin6.txt

exit退出docker镜像，开始拷贝文件到当前目录下：

docker cp 镜像id:/var/lib/mysql/mysqlbin6.txt ./

下载文件，开始分析（就是看一下被删数据的表，ctrl+f开始搜索就可以了）

找到对应位置

这应该是在系统中使用对应功能删除的，不过日志没记录，案件暂时到这里基本可以告一段落了，确定这个时间点公司没这么勤快的人干活，应该是客户自己搞的，再追查到具体操作人就有点难看了

记录一下命令免得再来一次