删库之后如何优雅的解决(跑路)?

大家好我是迷途,一个在互联网行业,摸爬滚打的学子。热爱学习,热爱代码,热爱技术。热爱互联网的一切。无论你是正在路上的旅人,还是背上行囊,整装待发的学子。 都可以点赞关注一下帅途的动态 当然如果帅途拿到比较好的学习资料或者看见比较好的文章也会第一时间跟大家分享。

前言

记录一次帅途周末加班,由于自己的误操作,把公司数据库干掉的惨痛经历,本文内容背景完全真实,为了保护隐私,文中人名用字母替代。

注意:由于本文操作内容过于危险,请各位小伙伴千万不要模仿!!!
在这里插入图片描述

背景

帅途目前就职于一家赛事服务公司,公司不算太大,但是在业内也算小有名气。主要从事b2b2c方面的赛事系统,和用户系统的开发。由于庚子鼠年开头受到新冠病毒影响,体育赛事行业受到前所未有的冲击。公司开始全力发展线上业务。帅途也被抽调去了线上组,全力开发线上业务。一切就从这里展开~

在这里插入图片描述

正文

起因

2020年5月24日清晨,阳光温柔的洒在脸上,鸟儿在树上跳着舞。房间里躺着一个穿着短裤短袖睡得四仰八叉的年轻人,多么美好的假期。这时年轻人放在床头柜上的手机嘟嘟嘟的响了起来,年轻人迷迷糊糊拿起手机一看,原来是产品经理G打来的电话。

年轻人迷迷糊糊的接起电话,已经习以为常的问了一句:“又是那个客户在瞎搞了?又要改什么东西。”

G说到:“有个主办方,把赛事积分配错了,你看你那边能不能帮忙处理一下?”

年轻人无奈道:“运营那边怎么搞得,这都多少个了。天天这样”

G又说到:“你赶快处理一下吧,就是XX体育局那个主办方,上面领导挺重视的。”

年轻人无奈坐起身,跑到厨房拿了一盒牛奶,然后走到书房打开电脑,连接teamViewer。
在这里插入图片描述

无奈的想到,自从加入被抽调到线上业务,已经记不得这是多少次紧急处理问题了。好怀念以前做B端系统的时候,那用考虑什么用户环境,版本号,并发。还不用随时随地处理问题,现在搞得,放假手机24小时关注,出去玩电脑都得随时带着,就差跟段子里一样坐着地铁,公司一个电话打来,直接在地铁上撸代码了。

年轻人连好远程,给G发了个消息问道:“积分怎么处理?”

G回到:“他们之前的用户报名赠送积分配置错了,现在他们赛事还没开始,你先统一把积分处理成xx就好了”

“算了偷个懒,不写代码处理了,直接数据库处理算了,反正就一个update,又没多大事”年轻人心里想着。(各位小伙伴,一定不要偷懒!帅途这是血与泪的教训,就放在眼前!就算要偷懒也一定记得在测试环境先测试一边sql,无论多简单。然后正式库执行的时候一定要先start transaction ;开启事务!另外 一定要备份!要备份! backups!

年轻人给G回了个消息:“好的,处理完了,我叫你。”

惊魂开始

年轻连上电脑之后,熟练的打开navicat,打开了尘封多年的代码小本本,找到了公司的数据库root账号。
在这里插入图片描述
登录了root账号之后,想了一下,改个积分简单~找到主办方id,然后把积分修改了就好了,我还能继续回去补个回笼觉。在梦里还能继续跟新来的UI小姐姐一起牵着手去逛街。。。

花了10秒钟,写出了update语句,简直不要太easy

// 就是这一行罪恶的sql,在用户报名记录表中修改主办方id为10的用户的积分为50.
// 然后帅途居然把where给写掉了,对 你没有看错!写掉了!!!!!
update m_apply_record set sponsor_id=10,integral=50

点击运行,“去冰箱拿个面包来吃,刚睡醒就喝了个牛奶,饿死了。”年轻人心里想着。
在这里插入图片描述
年轻人拿完面包回来,看了一下刚刚执行的结果,瞬间如临深渊。手上拿着的面包掉在地上也浑然不知,5月的艳阳天,年轻人却冒了一身冷汗,哪一个瞬间,背上的汗水就湿透了衣服。脑海里想着,完了,300万用户数据,全炸了。我明天是不是会上新闻头条,会不会被csdn首页置顶,成为各位小伙伴口中又一位删库跑路的勇士。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

解决

在短短一分钟时间里,年轻人仿佛经历了一场激烈的大战。像是一口气狂奔了五公里,又或者是坐着朋友开的车在拥堵的城市道路开着200码。浑身冷汗直流,颤抖不止。

回过神来的年轻人,立马反应过来,现在不是想这些的时候,怎么解决才是王道。

我刚才有备份吗?
没有,刚刚就一个很简单的操作,没有备份。最近的备份是头一天凌晨4点备份前一天的数据。

能回滚吗?
不行,我刚才没有开启事务,而且又是navicat工具执行,无法回滚

mysql日志打开了吗?
打开了!可以抢救,不要慌,先想解决方案。

果不其然,大约过了5分钟之后,产品经理G打来电话,问道:“怎么回事,怎么线上所有正在进行的赛事都用不了了?”

年轻人面色沉静道:“看见了,刚刚改数据出了点小问题,你不要慌5分钟解决。”
ps(其实这里帅途内心,非常慌张,咳咳!但是绝对不能让他们发现异样,不然先不说项目奖金之类的还有没有,估计还得先考虑是不是真的要跑路了。这里得心态有点像,每次测试组小姐姐提bug的时候,嘴上特别硬气,唉你是不是又误操作了,是不是环境又不对,然后自己偷偷摸摸把bug修复了。)

挂断电话之后,年轻人脑海里面立马浮现出一套解决方案,如果我现在直接用mysql的bin_log恢复数据的话起码要一小时以上,况且这么大数据量的情况下不可能快速解决。

现在数据全是乱的,用户根本没有办法正常操作,那就只有最后一个办法了,切库!还好当初无聊的时候跟运维J要了咋门服务器的账号密码,有时候也会帮他看看问题bug之类的,说干就干,年轻人立马打开idea,修改配置文件,将数据库切换到备份库,打包,6台服务器6个节点,大概花了7-8分钟,刷刷刷,搞定~

在这里插入图片描述
年轻人弄完这些之后,给G发了一条微信消息:“搞定了,不过这边显示可能出了个小问题,有些用户数据展示不正常,我正在处理,现在赛事能正常使用了~”(哪里是什么小问题,差点把帅途给吓死,不过表面功夫还是得过得去,作为和测试产品周旋多年的江湖大虾,波澜不惊是最基本得素养。)

做完这一切之后,年轻人默默开始用sqlbin恢复数据。

-- 查看当前所有binlog日志
show master logs;

-- 查看当前日志记录动作
show binlog events in 'mysql-bin.000003'; 

然后再我们Linux上面导出我们执行误操作的日志文件,一般来说都是最后一个日志。

-- 导出日志文件
/usr/bin/mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/mysql-bin.000003 > /logs/mysqlLogs/1.sql

根据end_pos恢复到某一个节点

-- 根据end_pos恢复据 在Linux执行
/usr/bin/mysqlbinlog  --stop-position=32314 --database=goteam_test  /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v goteam_test

-- 解析版
#{mysqlbinlog}  --stop-position=#{end_pos} --database=#{数据库名称}  #{日志文件位置} | /#{mysql数据库所在位置} -u#{账号} -p#{密码} -v #{数据库}

例如:我们要恢复到当前这个表中update语句执行之前,我们可以在Linux上执行命令

-- 根据end_pos恢复据 在Linux执行
/usr/bin/mysqlbinlog  --stop-position=9960 --database=goteam_test  /var/lib/mysql/mysql-bin.000001 | /usr/bin/mysql -uroot -p123456 -v goteam_test

在这里插入图片描述

根据时间节点恢复数据

-- 根据时间恢复
/usr/bin/mysqlbinlog  --stop-datetime='2020-05-11 16:28:05' --database=goteam_test  /var/lib/mysql/mysql-bin.000001 | /usr/bin/mysql -uroot -p123456 -v goteam_test

-- 恢复中间某一段时间数据
/usr/bin/mysqlbinlog --start-datetime="2020-05-10 16:28:05" --stop-datetime="2020-05-10 20:58:18" --database=goteam_test /var/lib/mysql/mysql-bin.000001 | /usr/bin/mysql -uroot -p8856769abcd -v goteam_test

参考链接:程序员保命技能,Mysql bin_log数据恢复,你还不知道吗?

结语

帅途在这里总结一下本次经历,一直到现在,帅途的心境都可以用4个字来形容,那就是惊魂未定!其实帅途这两天也咨询了身边不少朋友,从十几个人的小公司leader到某BAT大厂的开发,运维岗,同学、朋友,几乎每一个人都有过或多或少的删库也好,错改数据也好的经历,只是可能每个人的处理方案造成的损失大于小罢了。无论你是开发十几年大佬,还是初入江湖的开发新秀,亦或者身处学堂的莘莘学子,希望你们千万不要像帅途一样粗心大意,为了图省事,偷个懒。搞到最后虽然解决了问题,但是这个月的绩效和奖金也一起被解决了。当然也要学好压箱底的招数傍身,毕竟中国有句古话“不怕一万,就怕万一”嘛。
在这里插入图片描述

如果各位小伙伴真的迫不得已一定要对正式环境的数据进行操作,那么在照做之前,一定要问自己几个问题:

  • 我必须要直接对正式环境进行操作?
  • 我是否有备份?
  • 我是否在测试环境测试过执行结果?
  • 如果遇到不可控原因照成数据错误,我是否能很快处理?

最后帅途在这里祝各位小伙伴永远不会删库,代码运行一次成功,产品经理永远不会改需求,甲方爸爸都听你的~

看到这了就快点赞关注一下吧

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章