距离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