回忆一次事故
前言： 2014年刚来到北京这个大都市，进入了不同的工作环境，接触了不同的工作内容，工作失败与成功都是混合的，我们要正面面对失败，敢于向成功进步。
正文： 2015年5月份，加入公司已经将近一个年头，公司从事手机游戏研发工作，我在公司担当手游运维工作，在工作中学了不少以前工作所没接触到的东西，那个时候还经常接触mysql，因为当时没有专门人员做数据，都是由我们运维去做数据方面的处理工作，比如运营提的一些玩家去留啊，日活啊，充值量啊，卡点位置等等，各种各样的需求，那个时候我们就是跑sql语句，将运算后的结果通过邮件发送给运营。 事故的原因不是因为我们运维计算数据造成的，造成这个的原因是另外的。当时国外泰国版游戏需要更新一个大版本，大版本更新了，数据库的存储结构发生了变化，需要我们进行数据结构的升级，当时我们有多个数据库结构的sql文件，并且表明了对应哪个版本的应该使用那个文件，但是后来却发生了一个不该发生的事故，当时更新sql的时候直接用了部署高版本时的sql文件，这个文件是用来直接部署某个版本时应该使用的，而非从某个低版本升级到高版本所使用的，里面有很多drop命令，最近将库里的table都删除了，然后悲催的事情就发生了，升级完大版本后，测试人员就进不去了，后来通过多方面排查发现了mysql的大问题。 这个时候已经没有别的办法了，修复数据吧。 这个事故是在更新大版本的时候发生的，所以这个时候已经没有数据写入了，这样对我们的恢复工作来说相对简单些，不需要进行锁表等操作。
流程： 1.mysql每天一备，并且保留七天。我们先将前一天的数据进行整体恢复，这个是最简单的，进入mysql。 mysql> source backup.sql; Query OK, 100000000000 row affected (100000 sec) Rows matched: 100000000000 Changed: 100000000000 Warnings: 0 2.我们的定期备份是每天晚上的2点开始备份，我们可以从定期备份的文件里得到本文件的时间。 mysqlbinlog --start-datetime="2015-05-17 02:01:00" --stop-datetime="2015-05-08 01:01:00" /data/mysql/data/mysql-bin.001020 >>aa.sql 2.这样我们再次把文件导入即可。 mysql> source a.sql; Query OK, 10000000 row affected (10000 sec) Rows matched: 10000000 Changed: 10000000 Warnings: 0
感言： 通过这件事情，我们可以发现好的沟通是很重要的，而且有些时候sql文件中出现drop的字样也是一种很危险的行为，作为运维来讲，我们要把好最后的一关，就算前面都错了，如果能到我们这被我们发现，那我们就是成功的，运维的重要性就提升了。
