QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

十年难得一遇!从数据误删到全量恢复的惊险记录

  • 2020-04-23
  • 本文字数:2411 字

    阅读完需:约 8 分钟

十年难得一遇!从数据误删到全量恢复的惊险记录

本文由 dbaplus 社群授权转载。

引言

线上的数据库服务我们有完善的备份策略和恢复预案,数据即使被误删除了也是能够恢复的,误删除的数据量恢复只是时间问题。但各位同学自己部署的测试环境或者是在自己电脑中的开发环境的数据库就没有同级别的资源保障了。如果恰好你又把一些不能丢失的数据放到了这种环境中,那么建议要做定期备份,有备才能无患。


今天给大家分享的案例便是这种在线下自搭建环境的一次数据误删除事件。数据不幸被删除和万幸能被全量恢复可谓十年一遇。

事件背景

测试环境中的一台服务器准备做迁移替换,小 A 同学接到了这个光(危)荣(险)的任务。小 A 选择了直接 rm -rf /mysql 删除这台机器上挂载的数据分区来清理磁盘空间。


不到两分钟,还在挑灯夜战的某位同学就发现一个常用的测试环境无法正常使用了。这时候的小 A 定是心如止(死)水(灰),还是找 DBA 帮忙看看吧。


值班 DBA 小 D 被电话叫起紧急支援,但小 D 登录到服务器上一看也淡(傻)定(眼)了,数据、日志、软件环境统统都被删除了,唯一的一次备份是一年前升级测试环境数据库时做的备份。给 DBA 老 A 打电话吧,问问他的建议。


恢复经历

一旦发生了误删数据先不要慌,停止所有操作,第一时间寻求帮助。即使您是老司机,这时候也要找一位同学帮忙一起观察后续的操作,避免手抖出现再次误操作。


另外要强调的是,在出现数据误删除的服务器上同时只能有一个人操作,其他人应通过桌面共享软件或站在操作人身后观察,避免多人交叉操作出现二次故障。

1、找回数据文件

老 A 在得知数据、日志和软件环境都被删除后,先使用了 ps 命令查看 mysqld 进程是否还存活。



进程还在,这就有戏了,不幸中的万幸。抓紧到 /proc/${pid}/fd 目录看看有没有还未关闭的表可以抢救。



真是太幸运了,这个测试环境里面的表比较少,所有表的数据文件还都是打开状态。数据被找回的概率就很大了。接下来就是如何把这些显示为 deleted 的文件从文件系统中找回了。


在介绍如何找回被删除的文件前,先来介绍一个运维经常会遇到的删除了文件,但磁盘空间不释放的问题。下图是一个模拟的例子,当 test.txt 文件被 tail -f 命令使用时,rm test.txt 并不会释放空间,当将 tail -f 命令 ctrl+c 中止后,磁盘空间才释放。



一个文件在文件系统中的存放分为两个部分:数据部分和指针部分,指针位于文件系统的 meta-data 中,数据被删除后,这个指针就从 meta-data 中清除了,而数据部分存储在磁盘中,数据对应的指针从 meta-data 中清除后,文件数据部分占用的空间就可以被覆盖并写入新的内容,之所以出现删除 test.txt 文件后,空间还没释放,就是因为 tail -f 进程还在一直打开这个文件句柄,文件对应的指针部分由于进程锁定,并未从 meta-data 中清除。由于指针并未被删除,那么系统内核就认为文件并未被删除,因此通过 df 命令查询空间并未释放。


有了之前遇到的类似经验我们知道,MySQL 被删除的数据由于句柄还在打开状态,因此还未完成删除,是可以被找回的,已经关闭的表就无法找回了。找回的方法也比较简单,直接 cat 对应的文件句柄,再通过管道(pipe)或输出重定向的方式即可找回原来的数据文件了。但要注意的是为了保证原来的磁盘不要再被写入新的数据,不要在原分区下做磁盘写操作。这次的环境是部署在云服务器上的,再挂载一块新的云盘到这台服务器上就能把数据文件找回了,找回方式如下图所示:



如果读者使用的是自己的笔记本,可以插一块 U 盘或移动硬盘,将数据拷贝到 U 盘或移动硬盘;如果使用的是物理机可以考虑使用管道给 netcat 命令把数据文件传输到另外一台服务器。如下图所示:



表比较多的话建议写个脚本进行批量修复,注意提前分好目录结构,把对应句柄的文件直接恢复到指定的目录,便于后续处理。数据文件找回来啦!!!


2、恢复数据文件

数据文件已经找回了,已经算是完成了一半,至少业务的数据都在这些文件里面,但独立的 ibd 文件是无法被 MySQL 识别的,需要配合表结构定义文件(MySQL 5.7 之前为 frm 文件)才可使用。老 A 咨询了业务同学,他们使用的是开源的服务,可以在其他环境上再部署一套,这样就顺利的拿到了这个服务的建表语句。


MySQL 5.6 以上版本支持通过 ALTER TABLE xxx DISCARD TABLESPACE 和 ALTER TABLE xxx IMPORT TABLESPACE 的方式来删除和导入表空间文件(ibd 数据文件)。而我们这次的测试环境刚好是 5.7 的版本,支持这种语法,真是太幸运了。抓紧找个别的临时环境来建表导入数据就好了。操作方式如下:



笔者在操作的时候使用的账号不是 MySQL 账号,导致第 4 步在引入表空间的时候提示表空间不存在,修改文件属主再重新导入就可以了。提醒大家还是要沉着,不要忙中出错。

3、重建环境

完成了上一步千万不要开心太早,由于原来的表空间是未正常关闭的,这种方式恢复的表不可直接使用,数据有无损坏还需要进一步验证。这里老 A 建议把数据使用 mysqldump 出来,然后再恢复到准备迁移的新环境中。精力所限 MySQL 数据逻辑备份和恢复的方案这里就不再讲解了,读者可以自行搜索学习。


备份出来的数据表被导入到新环境后,老 A 请开发同学验证了里面的数据,故障前最新的数据都还在,服务修改配置重新启动功能正常,这时业务终于长出一口气。

总结

老话说“有备无患”,线上数据库服务我们有每天的定时全量备份 ,还有基于 binlog 的实时增量备份。对于自已部署的环境也要加强备份意识。笔记本上的代码要及时提交 git,产品文档要及时上传公司的云盘持久存储。线上数据修改要提前备份修改前的内容,删除数据建议先标记删除再物理删除。



作者介绍


贝壳找房 DBA 团队,负责支撑起贝壳找房平台的数据库运维及数据库产品的开发工作,努力提供高效、稳定、安全的数据库服务。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650787420&idx=1&sn=0af559f651cdc55577d020e2a7b42048&chksm=f3f97bc9c48ef2df6db31046b70d8c08b811d64c7d77a5204ffec27e46e10703038779e319bb&scene=27#wechat_redirect


2020-04-23 10:052159

评论

发布
暂无评论
发现更多内容

阿里云云原生开放日:云原生火力全开| KubeCon 热点速递 DAY1

阿里巴巴云原生

阿里云 Kubernetes 容器 云原生

工赋开发者社区 | 工业机器人产业链及主要配套厂商

工赋开发者社区

工赋开发者社区 | 精益与MES融合下的数字化转型

工赋开发者社区

CSS小技巧之单标签loader

南城FE

CSS css3 前端 Loader

阿里云在云原生领域喜获多项 OSCAR 开源尖峰案例奖

阿里巴巴云原生

阿里云 开源 云原生

【有奖体验】轻点鼠标,让古籍数字化“重生”

阿里巴巴云原生

阿里云 云原生 函数计算

Koordinator 协同 containerd NRI 增强容器 QoS,提升应用性能

阿里巴巴云原生

阿里云 云原生 Koordinator

《云原生 AI 工程化实践训练营-先锋系列》开营啦!

阿里巴巴云原生

阿里云 AI 云原生

Python - 字典2

小万哥

Python 程序员 软件 后端 开发

活在无限中

少油少糖八分饱

读后感 阅读 动漫 葬送的芙莉莲 有限与无限游戏

深势科技基于 Serverless 容器为科研人员打造高效的开发平台

阿里巴巴云原生

阿里云 Kubernetes 云原生 Kubernetes Serverless

公平,而非平等

俞凡

管理 组织架构

以生产力为中心:超宽带的跨时代之舞

脑极体

超宽带

阿尔比特(ARBT)DAPP质押挖矿系统开发丨源码技术搭建

l8l259l3365

寻找AI时代的关键拼图,从美国橡树岭国家实验室读懂AI存力信标

脑极体

存储

云原生场景下高可用架构的最佳实践

阿里巴巴云原生

阿里云 高可用 云原生

阿里云易立:以云原生之力,实现大模型时代基础设施能力跃升 | KubeCon 主论坛分享

阿里巴巴云原生

阿里云 Kubernetes 云原生 KubeCON

OpenResty 入门以及 WAF 防御实战

越长大越悲伤

nginx openresty waf

十年难得一遇!从数据误删到全量恢复的惊险记录_开源_dbaplus社群_InfoQ精选文章