以下故事虚构, 如有雷同纯属巧合. 人到中年又遇到了中年危机, 有家有舍的压力大, 这人的戾气也就大了,如今经济也处于下行阶段, 更是对大家精神状态的一种考研把. 下手也会更狠啊, 老板们还请善待研发人员,避免此类事故反复发生.
老王厂子里的mes系统连带着erp系统是找外包的软件公司开发的, 用的数据库选型当初选的就是免费的mysql来做的, 因为老王的厂子不大, 因此mes一直工作的不错, 国内的厂子大家大概都知道的, 老板非技术出生, 既不懂也不太关注it方面的技术, 一直也都挺平稳运行的, 厂子里的信息安全管理是做的是非常差或者说就是没有, 这也算是个全国很多中小厂子的通病了, 这也就给小帅这样的研发人员留下了报复的可能性了. 小帅在来厂子之前, 是一个软件研发, 因为35+了, 去年从一线被裁了, 赚了点钱, 老家也早已买房置业了, 心想着反正年纪也算比较大了, 回来到家以为找个对口的工作了此残生也就算了, 人生没必要那么大的抱负和自己的身体过不去.
所以虽然小帅找到老王工厂的时候工资虽然低了点, 但是因为工作挺对口, 小帅还是觉得非常高兴的.也赶巧老王当时厂子的生产端有些研发任务,就招了小帅来做, 任务做的也很顺利,那时候是小帅和老王的蜜月期, 但是老王那边研发任务完成后, 小帅基本上整天就无所事事了, 老王跟所有私企老板一样,厂子是不得养闲人的,看到小帅天天没什么事干, 肯定是不高兴的,因此有意无意的就把小帅往pe的岗位上调动, 还夸小帅的脑子好用, 比没文凭的人学习速度更快, 开始让小帅去做试产的工作, 这小帅也是个性情中人, 认为自己来就是坐办公室干技术研发的, 现在调去试产干这干那, 成了打杂的了, 有种被卸磨杀驴的感觉. 两下没沟通好, 老王认为自己是老板, 让你干啥你就得去干啥, 都懒得跟小帅解释甚么了.有诗曰：人有二心生祸灾，天涯海角致疑猜。
基本上这梁子就结下了, 小帅愤怒辞职, 老王也没含糊直接就批了, 心想着养着你也是闲人, 实习期自己辞职, 也省了诸多麻烦, 事情到这就没啥了. 果不其然, 结果反转来了, 老王厂子没过两月服务器就出问题了, 具体情况还查不到, 甚么问题, 反正mes, erp全趴窝了, 虽不至于停产, 但是对生产影响确实不小.
老王憋了一肚子火, 一边忙着救火, 一边寻思肯定是小帅搞的鬼, 想赵小帅看看能不能私下解决一下, 可是微信和电话都被拉黑, 人是联系不上了. 老王一度怀恨在心想要把小帅给法办了,但是没证据,只能自吞苦果作罢.不过老王并没有吸收教训加强信息安全的管理, 只是加重了对懂技术的人的忌惮, 一朝被蛇咬十年怕井绳吧.
以下是一些技术分析和恢复的过程, 没啥兴趣的小伙伴可以跳过了.
目前被清除的只是data目录, 因此查看my.ini配置, 可以获取mysql使用的是innodb引擎存储的, ok, 了解innodb的都知道他是一种二进制方式存储的, 他会比另外一种myisam类型的存储引擎在恢复难度上有所降低.
从Mysql5.5版本开始，InnoDB是默认的表存储引擎。其特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读、同时被设计用来最有效的利用以及使用内存和CPU。
根据innodb设计的架构图, 可以看到innodb的数据分别存储在ibdata1文件和分别对应表名的ibd文件中,也有可能只单独存放在ibdata中, 没有ibd文件. 但是对我们接下来的恢复情况而言, 其实并无甚么不同.
innodb数据库是由page页组成的, page的最小组成单位是行, mysql将行数据存储在pag中, page结构如下图
长时间的使用,势必会造成数据库的碎片化, 虽然所有的数据库和文件系统都在避免此类事情的发生, 但是收效依然不理想, 所以才会出现那么多奇幻又个性十足的技术来提升数据库和文件系统的性能, 所以首先我们需要对全盘扫描, 尽可能多的收集散落的在分区里的page.当然扫描恢复的pages是无法用mysql进行直接加载和读取的.
因此我们需要求助其他的一些办法了.
到这里开始, 哪些关于btree以及索引关于如何提升数据库性能的技术与我们就无关了, 因为我们只是找回丢失的数据, 线性的对pages进行处理即可获取数据.不知道老王会不会有下一次了, 更不知道幸运之神不知道下次会不会在眷顾老王了. 全剧终
