什么状况?下厨房的数据库不是每天备份的吗?这不科学啊?

下厨房

备份

数据库

69 条回复 • 1970-01-01 08:00:00 +08:00

1

Livid

MOD

2013-06-30 21:19:12 +08:00

天，不知道说什么好……

2

Kvm

2013-07-01 04:36:39 +08:00

这个彻底蛋疼了。。。。。

3

dreamage

2013-07-01 04:39:58 +08:00 via Android

弄到SAE去吧

4

hanbaoo

2013-07-01 08:08:49 +08:00 via iPhone

我总觉得，不是这样。。。一周前，我查一道菜，就很多null，当时还觉得奇怪没数据怎么会出现在搜索结果里
然后看了这个日志，总感觉是危机公关的味道

5

Kenny

2013-07-01 08:21:34 +08:00

好几个应用都比下厨房好用很多，而且貌似下厨房还没出 iPad 版？

6

Gawie

2013-07-01 08:49:28 +08:00

"那位程序员后来怎样了也顺便说下进展把。。。不要杀害他，但是可以用我们喜欢的方式折磨他吗？"

7

alexrezit

2013-07-01 08:51:32 +08:00

@uitony

8

Fedor

2013-07-01 09:01:32 +08:00

想知道这个攻城狮后来肿么样了。

9

vietor

2013-07-01 09:14:30 +08:00

我曾经在来北京的第一个公司就出过类似的事情。

我们公司是做“宽带计费”的，我在进行出帐的时候，不小心执行了错误的存储过程，造成出帐错误，又因为没有启用Oracle事务，造成无法恢复。计费少了，运营商亏了，好在“没有用户投诉”，我自己也没有受到太大的批评，但从此以后造成我一个习惯：做重大操作之前，必定检查再三才“怀着忐忑之心”执行。

10

jun0205

2013-07-01 09:19:27 +08:00

@vietor Oracle 默认是可以还原24之内的数据

11

vietor

2013-07-01 09:22:08 +08:00

1

关于数据删除，我在另一个公司有过类似经历。

我们公司做的是一套基于邮箱的电信增值业务。邮箱服务器放在一个RAID5的“国产”服务器上，但灾难的是两块硬盘相继损坏，造成数据丢失。将硬盘也送到“数据恢复”的公司去看，发现修复价值不大，就硬着头皮让运营商把使给平了。之后我们将邮件服务器放到一台“研华工控机”（不是做广告啊，的确让人放心）上硬是用了半年，知道我们重新购买了一个HP的服务器。那个“国产”服务器之后又坏过一次内存，造成我们只拿那台机器做备份了，不敢放任何有价值的数据。

最大的感受是：小心“国产”服务器呀，坑人那。

12

vietor

2013-07-01 09:23:27 +08:00

@jun0205 当时用的数据库版本是8i还是9哇，忘了，05年左右的事了。

13

cxshun

2013-07-01 09:24:59 +08:00

操作前不做备份，这能吐槽一下吗？貌似操作前备份数据库是必做的事情啦。
目测下厨房会失去一部分用户。

14

vietor

2013-07-01 09:29:51 +08:00

@cxshun

“下厨房的工程师准备给备份系统升级，过程中将线上的数据库误删除”，估计是连错数据库了。

还有可能性是没有做定时备份，只做了一个镜像备份，删了备份库的操作被同步到了主库，好是奇怪呀。

15

xhinking

2013-07-01 10:07:29 +08:00

半夜12点操作数据库一定要清醒啊~
感觉国内料理界倒退5年啊~~

16

julyclyde

2013-07-01 11:11:24 +08:00

应该是没做备份和备份恢复实验
说实话国内绝大部分小企业是缺乏运维人才的
国内的教育和培训也大都是偏向开发方向

17

Mihuwa

2013-07-01 11:25:41 +08:00

数据库操作一定要小心啊

18

explon

2013-07-01 11:33:45 +08:00

不重视数据备份的悲剧下场

19

julyclyde

2013-07-01 11:37:37 +08:00

1

@vietor 硬盘就是耗材，你自己没做好RAID状态监控，别把责任推给厂家。厂家只要能在硬盘故障的时候点亮故障灯就算尽到义务了

20

feiandxs

2013-07-01 11:37:59 +08:00

我打赌楼上也有不少人到现在还喜欢生产环境挽袖子就上。。。

21

julyclyde

2013-07-01 11:43:25 +08:00

@feiandxs 小网站就是这样的

22

vietor

2013-07-01 11:43:32 +08:00

@julyclyde 的确是没有做好做好状态监控，第一块坏了的时候没有及时补上。呵呵，总有些人为因素的。只是两块坏的间隔太短了，和产品还是有直接关系的，那个HP的一块都没有坏过那，当然国产的价格便宜了点，其中一个创始人用过那家的服务器——悲剧的后果。

23

julyclyde

2013-07-01 11:54:37 +08:00

@vietor 问题是：硬盘又不是国产的。这事除了没做好监控以外，基本上就是不可控因素了。轮到你倒霉了而已

24

solo7net

2013-07-01 11:56:10 +08:00

3

我也干过....
DB1
DB2
某大神:你把DB1导个表结构出来放到DB2
我:点这?
神:恩导入就行了
我:次奥 DB1怎么空了
发现导出的第一行 USE DB1;

25

julyclyde

2013-07-01 11:57:38 +08:00

1

@solo7net 按说只要执行导入脚本完成了，数据好歹还在吧，只不过是旧数据而已

26

solo7net

2013-07-01 11:58:45 +08:00

@julyclyde 导出的只有表结构

27

julyclyde

2013-07-01 12:00:21 +08:00

@solo7net 哈哈哈……

28

est

2013-07-01 15:36:09 +08:00

@solo7net 赞这个。感谢已发送

29

Leo

2013-07-01 16:24:40 +08:00

被顶起来的评论
Biu爷
那位程序员后来怎样了也顺便说下进展把。。。不要杀害他，但是可以用我们喜欢的方式折磨他吗？

虽然好残忍但好想笑

30

feiandxs

2013-07-01 17:01:25 +08:00

@Kenny 求更好的应用介绍

31

ayang23

2013-07-01 17:49:22 +08:00

1

@xhinking 半夜12点操作数据库一定要清醒啊 +1
本人就犯过2

32

kennedy32

2013-07-01 20:15:57 +08:00

@vietor 你怎么这么多悲剧

33

MayLava

2013-07-01 20:49:24 +08:00

我也犯过2。
为了调试方便在host里把线上域名指向localhost，然后各种测试。
然后有一次刚改回localhost，执行了清空数据库操作，结果浏览器的解析缓存没有重置，直接清了线上的所有数据(￣▽￣")。。。。

34

xuzhe

2013-07-01 21:11:58 +08:00

1

数据不备份、备份是否完整不验证，出了事儿只能是活该了。

35

dreampuf

2013-07-01 21:24:20 +08:00

人才都是坑出来的。

36

likuku

2013-07-01 21:25:32 +08:00

@vietor 「。那个“国产”服务器之后又坏过一次内存，造成我们只拿那台机器做备份了，不敢放任何有价值的数据。」... 有时备份就是唯一的救命稻草，没了就死了，备份机应该比线上生产机更加可靠才行啊。

37

zyAndroid

2013-07-01 22:39:07 +08:00

去年11月，一个误操作删除了一张表里两个多月的数据（百万行），到现在想想都心有余悸。

老板说“这是你工程师生涯的第一个里程碑”，当时差点儿羞愤自尽啊啊啊

38

gracece

2013-07-01 23:03:14 +08:00

自己的一个小网站，一不小心也把一个表清空了，着实蛋疼了好几天。估计下厨房那个工程师会铭记这个教训的=。=

39

vietor

2013-07-02 08:47:25 +08:00

@likuku 主要的原因是“成本”，老板也是在出事之后才开始腾出机器进行“备份”。
本来RAID5是一个不错的选择，哪知“点太背”，坏硬盘坏内存的。整个系统在没有任何备份的单硬盘“工控机”上都“没任何问题”的跑了半年呢，可想而知那个机器太烂了。

最终奉献一下，那家国产服务器的厂家名称：“宝德”，06-07年左右的事。

40

hadi

2013-07-02 09:41:09 +08:00

除了备份计划，做好自动化部署也比较难出这种状况吧?

41

Hyperion

2013-07-02 09:50:10 +08:00

看到第一条回复毛骨悚然...

Biu爷
那位程序员后来怎样了也顺便说下进展把。。。不要杀害他，但是可以用我们喜欢的方式折磨他吗？

汆水? 清蒸? 凉拌?......

42

chunshuai

2013-07-02 10:38:09 +08:00

@feiandxs 直接线上改。

43

feiandxs

2013-07-02 11:14:58 +08:00

@Hyperion 顺藤摸瓜看了下Biu爷是位漂亮的人妻妹子...=V= #我都在关心些什么糟糕的东西……

44

likuku

2013-07-02 11:24:14 +08:00

@hadi 「自动化部署」...若这个自动化策略出了差错，也会造成破坏。

45

hadi

2013-07-02 15:26:39 +08:00

@likuku 的确没有什么能百分百保证不出问题，不过从 development -> staging -> production 走下来，recipes 一般不会有什么大问题吧，手工重复执行这些步骤，出错机率还是要高一些的，也不符合程序员偷懒的原则嘛。

46

neodreamer

OP

2013-07-02 15:27:25 +08:00 via iPad

@solo7net >_<!!!!!

47

akira

2013-07-02 15:45:50 +08:00

不是每家公司都会注重数据库安全的

48

moyaya

2013-07-02 16:35:24 +08:00

我们网站也有过一次误删除数据库的经历，结果我们自己每天在AWS上有备份，阿里云有快照，大概只丢了一天的数据。

49

kalintw

2013-07-02 19:50:00 +08:00

CTO可以下课了

50

jjgod

2013-07-02 20:29:06 +08:00

这么大规模的上线网站，三个月没备份，挺恐怖。

51

marginleft

2013-07-02 22:35:58 +08:00 via iPad

@vietor 浪潮？

52

marginleft

2013-07-02 22:37:29 +08:00 via iPad

@vietor 哦，好吧。不是浪潮

53

vietor

2013-07-02 22:37:34 +08:00

@marginleft “宝德”

54

dongbeta

2013-07-02 22:51:02 +08:00

删除过线上数据库的工程师，一抓一大把。

55

julyclyde

2013-07-03 10:57:54 +08:00

@kalintw 这种小企业，CTO应该是联合创始人，不会下课的

56

haohaolee

2013-07-03 14:56:39 +08:00

@solo7net @est 表示这个笑话没看懂.....

57

uitony

2013-07-03 15:46:58 +08:00

2

感谢v2ex上朋友对这件事的关注，
技术总结了下技术原因和细节： http://tech.xiachufang.com/?p=18
再附上一封道歉信： http://blog.xiachufang.com/article/5601

如果数据完全恢复不了的话，确实属于「灾难性」问题。
不过最终结果我们是幸运的，感谢宽容的用户们。

下厨房技术团队有一半来源于v2exer，事故从发生到目前阶段性的解决，技术团队面对问题的积极处理和响应（几乎一直熬夜），这次事故客观上会帮助下厨房团队安全意识的提升，尽管成长代价确实有点大。

在夜里上传数据的间歇，技术团队自发地为这次事故分摊责任，总结教训，并且向公司主动请罚。
我愿意并且值得为这样的技术团队继续投以100%的信任。