本文主要是介绍MySql从删库到跑路那年我真的差点跑路了,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
本文为转载文章,如有侵权请直接我们联系删除。更多相关资讯,请到掌桥科研http://www.pbsti.com/
人生大起大落落落落落落,实在是太刺激了,下面这真是一个悲伤的故事。
那年公司 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 米,吃喝拉撒都在机房,不对,拉撒不在。
这件事情造成的后果:
-
大部分员工放假三天,我加班三天三夜。
-
本来很爱我的大部分员工因为单据事件,集体转为黑我恨我了。
-
公司立马批了我的计划,冷备,热备,异地容灾,全部上全了。
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语句删除(也可通过时间和位置点),再恢复到数据库。
本文为转载文章,如有侵权请直接我们联系删除。更多相关资讯,请到掌桥科研http://www.pbsti.com/
这篇关于MySql从删库到跑路那年我真的差点跑路了的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!