【问题发生】
某个系统,不小心在界面上误删除了数据,查数据库确认对应的数据已经从数据库中删掉。
检查 mysql 设置,binlog 缺省开启,对应时间的binlog文件保存完整,可以用来恢复数据。
【数据库层的数据恢复】
利用 mysqldump --no-data 建立镜像的数据库环境,作为验证工作的环境。
使用 mysqlbinlog logfile databasename > logfile.sql 将binlog文件中的二进制内容转化为sql文本。
观察sql文本,并利用已知主键搜索,查到相关的 INSERT/UPDATE 记录。不过我很疑惑没有查到对应的 DELETE记录。
在验证数据库环境中手动执行查到的INSERT、UPDATE记录,在数据库中确认数据基本完好。
【应用层验证】
整理手动执行的记录,在真实环境中再次执行手动执行,在应用系统中确认数据基本完好。
【经验和教训】
1)手动恢复数据耗时耗力,需要同时对数据库实现和应用层都很熟悉,这是最后的手段,能不用就不用;
2)能够查看到binlog 文件保存完整,就可以认为数据可以恢复,只是恢复的完整程度需要继续确认。
3)必须在镜像环境中工作,工作验证无误以后,将在镜像环境中的操作严格复制到实际工作环境中。
4)在我的例子中,因为记录条目数较少(<50条),手动恢复的方式较为适合。
5)实际我的工作中优先尝试基于脚本的自动恢复,先后遇到数据库表格式有变化、字符集问题、特殊字符问题,反而耽误了时间。
应该仅对数据量较大(>500条)的情况做自动恢复。
6)数据库层的数据恢复后,还需要做应用层的验证才能最终确认恢复成功。
某个系统,不小心在界面上误删除了数据,查数据库确认对应的数据已经从数据库中删掉。
检查 mysql 设置,binlog 缺省开启,对应时间的binlog文件保存完整,可以用来恢复数据。
【数据库层的数据恢复】
利用 mysqldump --no-data 建立镜像的数据库环境,作为验证工作的环境。
使用 mysqlbinlog logfile databasename > logfile.sql 将binlog文件中的二进制内容转化为sql文本。
观察sql文本,并利用已知主键搜索,查到相关的 INSERT/UPDATE 记录。不过我很疑惑没有查到对应的 DELETE记录。
在验证数据库环境中手动执行查到的INSERT、UPDATE记录,在数据库中确认数据基本完好。
【应用层验证】
整理手动执行的记录,在真实环境中再次执行手动执行,在应用系统中确认数据基本完好。
【经验和教训】
1)手动恢复数据耗时耗力,需要同时对数据库实现和应用层都很熟悉,这是最后的手段,能不用就不用;
2)能够查看到binlog 文件保存完整,就可以认为数据可以恢复,只是恢复的完整程度需要继续确认。
3)必须在镜像环境中工作,工作验证无误以后,将在镜像环境中的操作严格复制到实际工作环境中。
4)在我的例子中,因为记录条目数较少(<50条),手动恢复的方式较为适合。
5)实际我的工作中优先尝试基于脚本的自动恢复,先后遇到数据库表格式有变化、字符集问题、特殊字符问题,反而耽误了时间。
应该仅对数据量较大(>500条)的情况做自动恢复。
6)数据库层的数据恢复后,还需要做应用层的验证才能最终确认恢复成功。