您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 数据库 > 正文

不小心删除了公司数据库,是什么样一种体验?

发表于:2017-08-23 作者:古的白 来源:知乎

人生大起大落落落落落落,实在是太刺激了,下面这真是一个悲伤的故事。

那年公司 ERP 系统刚进行升级。

因为公司陆续上了 MES 和 PDM 系统。为了加快整个公司信息化平台的统一,请了个第三方公司来做中间接口。

然后故事开始了。

某一个晚上,第三方人员问我要 ERP 的 SA 密码。

我很警惕:“你要干嘛?”

“我测试一下中间表。”

“有没有写表的操作?”

“没有,只有读表的操作。”

于是我放心的给了 SA 密码。给了 VPN 权限通道。放她进来了。

十分钟后…..

她带着哭腔打电话来(是的,对方做测试的是个 93 年的萌妹子。)

“吴哥哥,服务器中毒了。。。。”

我当时还在逛果壳呢,一听她说我服务器中毒了,我表示无比淡定。还以大哥的经验教训了一顿她。

“叫你不要往我服务器传插件嘛,这次帮你解决一下,下次不准了哟。”

我认为是小 case 呢,不就中毒了嘛,系统往回滚一天就好了。

然后悲剧的事情就出现了,远程进不去,于是我就去机房本地登录,居然也进不去。

我不死心,强制重启,居然还是进不去。我的服务器系统就这样崩了。。。

好在那几天在做开发,系统没有启用,于是我和我的老板汇报了这个情况:

“老大,我们服务器系统崩了。”

“哦,那就搞好它让它别崩。” 果然是霸道总裁啊。

当时数据和应用服务器我都是分开跑的,所以应用服务器奔溃了,我觉得也没多大事,就重新做系统吧。于是我重新做了个系统,然后喊萌妹子上来搭平台。

“小刘啊,你可害惨我了,一个下午给你重做服务器系统了,我基础环境都配置好了,你上来搭平台吧。”

萌妹子那是无比的歉意啊,又是答应请我吃饭又是答应请我看电影的。我都想系统再崩溃一次了。

按理说这样应该是没问题了,就在我走出机房,在外面抽了根烟,45 度仰望了一下天空,联想了一下和萌妹子点个 9 分熟的牛排,在喝一口二锅头这样浪漫的晚餐的时候。电话来了。

来电话的是萌妹子的老板。

“小吴,我想找一下 information.db 和 mfmedia.db 这两个总表没找到,你给我找一下。”

我都蒙了,从来没人问过我这样的问题,难道她老板不是 IT 行业的。

“数据库文件都在目录树里啊,自己去找啊。”

“没有。”

于是我登上服务器一看,我傻了。所有的表都空了,所有的表都静静的躺在那,但是里面都空了。。。

不可能啊,我数据库是放在另外一台服务器上的,怎么可能会没有了。

于是我问萌妹子:“XXX,你到底做了什么操作啊,为毛我数据库都没了。”

萌妹子说:“我啥也没干啊,只是按照步骤一路点 YES。”

我才想起来,在第一次配置基础环境的时候,建账套会提示是否初始环境,如果点是了,数据库就会被初始化,然后这位萌妹子傻傻的点了是。

“你知道不知道你干了什么,公司 06 年到现在所有的数据,财务的,供应链的,进销存的全部都在这台服务器里,200 多个 G 数据,因为你一个是,全没了。”

萌妹子也吓蒙了,话都说不出来了。

没办法,我再给我老板打电话。

“老板,有个好消息,有个坏消息。”

“直接说坏的。” 我就喜欢我们老板这么直接。

“恩。。恩。。那个。。就是那个。ERP 的数据没了。”

“哦,那就找回来。” 老板还是那么的霸气。我特么都要爱上他了。

“老板,我想你没明白这个的严重性。ERP 数据没了,从 06 年开始的都没了,这意味着就算找回来,整理所有的表,排错也需要 3 天左右时间,到时候所有的生产都要暂时停止。如果找不回来,我们可能就要倒闭了。”

我忽然有种掌握天下苍生的感觉。。。

对面沉默了 5 秒后,爆吼了一句:“吴 XX,你给我滚到我办公室来!!”

中间和老板手握手谈心,被老板亲切慰问的细节跳过不表。

当时公司高层对数据安全还没有那么重视,之前预算做的项目,我已经做了备份的计划书,一直没被审批下来,现在估计悔得肠子都清了。

于是我开始漫长的数据恢复之旅。

我之前已经做了个本地备份的计划,每天晚上会备份一次。我把希望都放在了它身上。等我把备份的数据库附件上去,发现时间居然都是两个星期之前的。

而且还有一些新表都没有,我联系对方,对方告知研发人员两个星期前做测试的时候把备份计划关了。。。

我心里万头草泥马奔腾而过。

最后没有办法,把老服务器又翻了出来,翻出之前的老数据,开始转换。

期间老板给我短信:“数据恢复进行的怎么样了呢。”

“报告,正在稳步进行中,按照目前的状况,可恢复的可能性超过 90%。” 别问我 90% 怎么算出来的,我就是哄他才这样说的。

“唉,真是心急呀,睡都睡不着。小吴呀,当初要是听你的,上了备份该多好呀。” 现在知道后悔了,哼哼。

“老大别担心,我会搞定的。” 是的,作为一位负责的员工,我就是这么让老大心安。

“恩,那就交给你了哦,熬夜少抽点烟哦。” 哎呀,瞬间觉得我老大萌萌哒有没有。

这里花了我一个晚上加一个白天。

数据转换好了,还有一些时间差的数据没法找到。于是通知各个部门,找单据,开始往里面补单子,一条一条的按照业务流程补进去。

为了协同更方便,在会议室加设了几十台电脑集体办公。。。

在大家一片怨声载道中,三天时间,终于把数据恢复了过来。三天内我没离开机房超过 10 米,吃喝拉撒都在机房,不对,拉撒不在。

这件事情造成的后果:
 

1. 大部分员工放假三天,我加班三天三夜。

2. 本来很爱我的大部分员工因为单据事件,集体转为黑我恨我了。

3. 公司立马批了我的计划,冷备,热备,异地容灾,全部上全了。

4.我挥刀自宫,自己罚了自己,扣除了自己一个月工资。

5.老板到现在还是在怀疑请的那家公司已经被我们竞争对手收买,是故意来破坏我们的。

6.萌妹子拉黑了我。

这真是个悲伤的故事。

看完了这个悲伤的故事,我们要回归理性,MySQL 数据库误删除后怎么办?

在日常运维工作中,对于数据库的备份是至关重要的!数据库对于网站的重要性使得我们对 MySQL 数据库的管理不容有失!

然而是人总难免会犯错误,说不定哪天大脑短路了,误操作把数据库给删除了,怎么办?下面,就 MySQL 数据库误删除后的恢复方案进行说明。

工作场景

MySQL 数据库每晚 12:00 自动完全备份。

某天早上上班,9 点的时候,一同事犯晕 drop 了一个数据库!

需要紧急恢复!可利用备份的数据文件以及增量的 binlog 文件进行数据恢复。

数据恢复思路

利用全备的 SQL 文件中记录的 CHANGE MASTER 语句,binlog 文件及其位置点信息,找出 binlog 文件中增量的那部分。

用 MySQLbinlog 命令将上述的 binlog 文件导出为 SQL 文件,并剔除其中的 drop 语句。

通过全备文件和增量 binlog 文件的导出 SQL 文件,就可以恢复到完整的数据。

实例说明

首先,要确保 MySQL 开启了 binlog 日志功能。在 /etc/my.cnf 文件里的 [mysqld] 区块添加,如下图,然后重启 MySQL 服务。

1.在 ops 库下创建一张表 customers
 

2.现在进行全备份
 

参数说明:

-B:指定数据库

-F:刷新日志

-R:备份存储过程等

-x:锁表

–master-data:在备份语句里添加 CHANGE MASTER 语句以及 binlog 文件及位置点信息

3.再次插入数据
 

4.此时误操作,删除了 test 数据库
 

此时,全备之后到误操作时刻之间,用户写入的数据在 binlog 中,需要恢复出来!

5.查看全备之后新增的 binlog 文件
 

这是全备时刻的 binlog 文件位置,即 mysql-bin.000002 的 106 行,因此在该文件之前的 binlog 文件中的数据都已经包含在这个全备的 SQL 文件中了。

6.移动 binlog 文件,并导出为 SQL 文件
 

剔除其中的 drop 语句,查看 MySQL 的数据存放目录,由下面可知是在 /var/lib/mysql 下,将 binlog 文件导出 SQL 文件,并 vim 编辑它删除其中的 drop 语句。

注意:在恢复全备数据之前必须将该 binlog 文件移出,否则恢复过程中,会继续写入语句到 binlog,最终导致增量恢复数据部分变得比较混乱。

7.恢复数据
 

查看数据库,看看 ops 库在不在。

此时恢复了全备时刻的数据。接着,使用 002bin.sql 文件恢复全备时刻到删除数据库之间,新增的数据。

再次查看数据库,发现全备份到删除数据库之间的那部分数据也恢复了!!

以上就是 MySQL 数据库增量数据恢复的实例过程!

最后,总结几点:
 

本案例适用于人为 SQL 语句造成的误操作或者没有主从复制等的热备情况宕机时的修复。

恢复条件为 MySQL 要开启 binlog 日志功能,并且要全备和增量的所有数据。

恢复时建议对外停止更新,即禁止更新数据库。

先恢复全量,然后把全备时刻点以后的增量日志,按顺序恢复成 SQL 文件,然后把文件中有问题的 SQL 语句删除(也可通过时间和位置点),再恢复到数据库。