“谁动了我的数据表”，Table doesn't exist问题排查实践

在数据库使用过程中，你大概率会遇到‘自己需要的数据找不到’的情况，提示你，甚至提示你整个表都不存在Table doesn't exist。首要的当然是从备份文件中将数据进行恢复，如表级时间点恢复或实例时间点恢复，其次我们还要找出‘罪魁祸首’，究竟是谁动了我的数据？今天我们通过一个简单的实际案例，来定位到这个误操作的人员。

问题现象

之前用的好好的，突然在今天下午出现问题，一张重要的表不见了。

处理思路

1、对数据库任何变动（不含不改变数据库的操作，如show、select）都会在binlog中记录，可以通过binlog来定位‘误操作’具体的时间。

2、配合数据库审计日志（默认是关闭的，开启会对性能有些许影响），就可以定位到误操作人员的IP。

3、数据库支持多用户并行操作，DBA要事前做好权限分配和控制，以防用户操作到不应该操作的数据。

分析过程

1、华为云数据管理服务DAS中提供云DBA服务，里面有包含性能、锁&事务、空间、参数、binlog等多种常用运维方法。

2、根据问题出现时间，解析binlog日志，查找可疑的操作

3、点击‘查看DDL语句’，可以看到，在2021/4/2 14:50:52，t_employee表确实被drop了。

4、进入云数据库RDS，单击实例名称，进入实例详情页

5、实例详情页，左侧的‘SQL审计’，找到对应的时间段，下载审计日志

6、打开审计日志，查找对应的操作，即可找到操作的IP了

这个 100.125.xxx.xxx 是DAS的地址，说明用户是通过DAS界面进行的drop操作。

案例总结

有用户通过DAS的地址Drop了这个表，如果要找回这个数据，可以通过恢复备份的方法。