记一次真实的线上事故：一个update引发的惨案！

目录

• 前言
• 项目背景介绍
• 要命的update
• 结语

前言

  从事互联网开发这几年，参与了许多项目的架构分析，数据库设计，改过的bug不计其数，写过的sql数以万计，从未出现重大纰漏，但常在河边走，哪有不湿鞋，就在五一假期的头一天，我干了职业生涯中最愚蠢，也是最刺激的一件事：执行update的时候忘了添加where条件，结果更新了整张表（系统最重要的一张表）的时间字段。。。

项目背景介绍

  简单介绍一下项目背景：大家可以把其理解为一个文章检索系统，前台用户端通过输入日期、关键字以及文章类型可以查询出对应的文章内容并查看：

  后台管理端可以通过多维度对现有的文章进行维护（使用过我开发的代码生成器的朋友一定对下面的界面很眼熟，没错，后台（包括界面）百分之90的代码都是我拿它生成的）：

要命的update

  当时整个系统的开发工作全都压在了我一个人的身上，而且工期很紧，只有不到一周的时间就要上线，临危受命，只能硬扛。

  系统前台使用人群主要为企业的财务人员并且使用的时间比较分散；后台使用人群为内部管理员（只有两位）；每年新添加的文章数大概两三千左右的样子。综合考虑下来，基本不会有什么并发量，数据量也不大，缓存是没必要了，搜索引擎更是大材小用，所以为了快，便采用SpringBoot+MySql的方式进行开发。

  最终，项目如期完成，来到了最后的线上部署阶段，当时是4月30号下午三点左右，在检查数据的时候，我发现了一条格式有误的日期数据，于是在navicat执行了这条sql，这正是灾难的开始：

update article set addtime = '2019-07-26 00'

  。。。NO，wait！！执行完毕之后，我意识到大事不妙，企图rollback，然并卵，navicat是自动提交的。。。，由于使用的是测试环境，也没有对数据库做任何备份。。。心中一万匹草泥马飘过，冷静，我要冷静，现在要做的是把数据恢复到之前的样子，也就是把数据回退到执行这条sql之前最近的时间点。

  我开始在网上查阅相关资料，发现开启binlog是数据恢复的前提，如果没有开启，不好意思，常规办法不可恢复！

  当时我脑瓜嗡嗡的，如果没有开启binlog，那就真的凉凉了，我紧张的连接到远程服务器，cd到mysql的安装目录，内心不断祈祷：一定要有啊！一定要有啊！别搞我！

  。。。当我看到var文件夹下的mysql-bin.000002文件时，长舒一口气，还有的救，老天果然还是眷念我的。

  剩下的操作就简单了，根据网上的信息进行汇总，得出执行以下命令便可获得指定数据库指定时间段内所有的sql语句：

/usr/local/mysql/bin/mysqlbinlog
/usr/local/mysql/var/mysql-bin.000002
# 指定数据库名称，注意是数据库，不是表
--database=xxx
# 起始时间
--start-datetime='2020-04-26 00:00:00'
# 结束时间
--stop-datetime='2020-04-30 15:00:00' > backup.sql

  为了保险起见，我备份了mysql目录下的所有文件，然后执行了以上命令，结果意外的顺利，当前目录下生成了backup.sql文件。

  然后我drop掉命令中指定的database，执行backup.sql脚本，一行行OK闪过，持续了十秒左右的样子戛然而止，期间没有报错，感觉可以，有戏！在navicat中刷新，打开article表，谢天谢地，数据恢复了：

  最后，项目成功部署上线，一个update引发的惨案也就此悄无声息的画上了句号。

结语

  通过此次事件，让我明白了备份的重要性，俗话说得好：有备无患。其次，在执行update，delete语句时，一定要记得开启事务，这样一旦出了问题可以rollback！

附：喜欢的朋友可以关注公众号 “螺旋编程极客” 第一时间获取最新内容更新！