Chinaunix首页 | 论坛 | 博客
  • 博客访问: 204922
  • 博文数量: 449
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 4525
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-02 14:16
文章分类

全部博文(449)

文章存档

2024年(14)

2023年(218)

2022年(181)

2020年(12)

2019年(24)

我的朋友

分类: Mysql/postgreSQL

2020-03-02 15:49:03

数据库环境部署与故障原因:

本次恢复的数据库安装在客户本地服务器上,服务器操作系统为windows2008 r2 。在当前环境内安装有mysql5.6单实例,引擎类型为innodb,表内数据存储所使用表空间类型为独立表空间。未进行数据库备份,未开启binlog。
导致数据丢失的原因是由于人为误操作使用Delete命令进行删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作,需要从数据库层面进行误删除的数据恢复操作。

数据恢复方案制定:

1、故障类型分类:在本案例中,由于未对生产环境进行备份也未开启binlog日志,无法直接还原数据库,属于典型表内mysql-delete数据误删除。
2、故障分析与可行性方案制定:通常情况下对于mysql innodb误删除导致记录丢失的恢复方案有三种,分别是备份还原、binlog还原和记录深度解析。由于本案例中的数据库没有备份,也没有开启binlog,也就是说前两种方案都不适用,只能使用记录深度解析的方式进行恢复。此恢复方案恢复原理为模拟innodb引擎记录管理方式,根据表结构信息将二进制文件解析为字符记录。

数据恢复流程:

1、获取数据文件:客户将表结构文件及表数据文件(.ibd)通过网络传输的方式发送到数据恢复中心,数据恢复工程师将文件下载后开始对数据进行分析和恢复。
2、使用数据库数据恢复工具进行扫描:


在本次数据恢复案例中,客户提供了数据库表结构脚本,可以使用本工具中的5+3功能进行恢复。
首先读取表结构信息:


开始解析记录:

本工具默认将记录提取为SQL备份格式,等待解析完毕后还原到数据库查看结果(为保障客户隐私关键信息已打码):

客户验收数据:

数据提取完成后,通知客户对提取结果进行验证,并统计恢复记录总数。客户验证后表示最终数据恢复结果完整,总数符合原表内记录条数,本次数据恢复成功。
阅读(1155) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~