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