1
lichao 2013 年 7 月 3 日
我不止一次 shutdown -h 0 然后发现是在服务器上
|
3
wang2191195 2013 年 7 月 3 日 via iPhone
那个员工怎么样了=_=
|
4
thinkxen 2013 年 7 月 3 日 via Android
我了个去啊~
|
5
Ricepig 2013 年 7 月 4 日 via iPhone
有人发现吗?在这个案例里,信息产业部下属公司数据恢复能力强于阿里巴巴dba团队出来创业的沃趣科技
|
7
kennedy32 2013 年 7 月 4 日
每个这种事故,都有因故没有备份数据库的事件出现
相似的错误造成一次又一次事故 |
8
master 2013 年 7 月 4 日
虽然说操作失误千不该万不该,但最后暴露出来的还是对运维的不重视
所以这大概是国内很普遍的情况吧,技术团队兼作运维, 所以因为还有研发的工作在,所以运维的方面即使明知有疏忽, 还是被一再拖延,直到操作失误才发现没有后悔药 |
9
master 2013 年 7 月 4 日
@Ricepig
觉得对于这个问题讨论公司人员背景好像意义不太大, 毕竟是误删磁盘数据的恢复工作,这个肯定还是以做数据恢复为主业的公司更擅长一些 沃趣的关注点毕竟还是放在运维,虽然说删磁盘这种事也算是运维故障 |
10
TonyLiu2ca 2013 年 7 月 4 日
测试环境很重要吧,生产环境的改变之前要有测试计划吧,测试之后要有升级脚本吧。
|
11
jason52 2013 年 7 月 4 日
看看那个数据恢复公司成功恢复的案例,令人大吃一惊啊,什么医院,银行等单位运维都是蛮重要的啊
|
14
sykp241095 2013 年 7 月 4 日
这次下厨房发生了这个事故后,我特意注册了一个 shutdown.sh 域名,请问各位这个域名可以用来做什么。。
|
15
firsthym 2013 年 7 月 4 日
深刻的教训
|
18
laogui 2013 年 7 月 4 日 那个员工怎么样了?有没有被杀害?
|
19
laogui 2013 年 7 月 4 日
看了这个过程感觉技术好牛X,从硬盘修复中、从内存中、从memcache中、从binlog中、从搜索引擎的快照中。从这几种东西里提取了一堆不完整的数据你们竟然最后可以搞一块去。太佩服你们的技术了。
|
21
clowwindy 2013 年 7 月 4 日
rm -rf 之后文件名没有了,但 MySQL 还在运行,文件没有删除。这时候可以连接 MySQL dump 数据。
|
24
manoon 2013 年 7 月 4 日 via Android
这个可以发给领导看一下, 数据的重要性. . . .
|