距离2010年开始创业快10年了，收获了
- 比实际年龄老10年的外貌
- 中度抑郁症
- 负债累累
当然还是有些其他的收获，比如下面这个删库事件。刚好发生6周年，把当年事故后写在redmine上的news拿来再看一次，也算有个纪念。
2014年1月9日 数据库事故
摘要：程序员误操作，把生产环境的数据库表删除之后的抢救措施
事件回放
13:02
从全果的座位上发出“Fuck Fuck”的惨叫声
13:04
他站起来承认，误把38个openfire相关的数据表给删除了
13:05
Tom说他早就猜到了这一天会到来，但是没有想到这么快
小伙伴都惊呆了，刘飞询问，为什么会把数据库误操作呢？
13:06
打击太大，大家都呆滞了几分钟
13:08
全果询问是否要把服务停止
13:11
对外访问服务被停止
13:12
Tom开始联系Ucloud，云服务提供商在QQ群上远程支持备份恢复方法。好在Ucloud的UDB自动每天3点进行全备份。我们被删除的38个表应该可以找回3点时候的数据，但是之后的修改需要方法
13:13
Ucloud团队给出备份恢复的方法
13:24
开始下载备份数据到 haproxy01: /data/mysql_back 目录下，文件大小2G
wget http://data.xxxxxx
13:36
3点的备份数据下载解压成功
13:40
但是备份数据中，我们只需要38个表，这个需要perl 脚本去获取38个表的数据
https://gist.xxxxx restore.pl xxxxx
13:55
文件导出成功，合并后，开始导入mysql
mysql -h xxxxx
14:00
UCloud 方面开始把3点后的binlog 整理压缩，准备让我们下载分析
14:18
开始下载4个binlog 文件，准备开始分析，期间要在haproxy01上安装mysql-server 5.5，才能有mysqlbinlog 命令
sudo apt-get install mysql-server-5.5
分析binlog 文件，需要排除3点备份前的binlog，使用下面的命令，找到–start-position=，并且删除最后的drop table 命令
less adc0204d-a320-4b5a-8658-52a90ccd667e_20140109030446.sql
15:18
经过Tom和朱峰的共同努力，binlog分析后的sql文件生成完毕，发现无法导入mysql
15:25
需要最后每行结尾增加分号隔开
15:36
开始导入最终的sql文件，一共108万行，这是3点后到停服前对openfire所有38个表的修改语句
16:02
文件导入完毕，Tom终于上了一次厕所。刘飞开始重新部署大机
16:05
发现系统重启后，redis相应很慢。Tom对haproxy02的redis-server进行了重启。
16:10
大机重新打包
16:18
大机恢复正常访问，但是有些用户发现好友数量为减少到了1。参见 #200
16:30
全果恢复了所有人的好友缓存
问题全部解决。
~END