下厨房数据丢失引发的自我反思
2013-07-08 00:57
363 查看
下厨房6月26日数据丢失事故总结
http://tech.xiachufang.com/?p=18626技术故障的致歉信
http://blog.xiachufang.com/article/5601刚录完mysql主从同步的视频,群里有人发了个链接,是一个数据丢失事故总结。自己吓一跳,我自己在数据上面也并不是那么上心。总有一天我也会出同样的错。必须反思下。
从总结当中发现了一些问题。虽然我没有指责他们的权利,但我也没有这个心思,只是对自己的反思, 因为自己也在数据漫游中整过很多问题。
大的备份数据重要性我就不讲了。
一眼看到的是流程啊,没有流程来规定这些东西出错,rm -rf真心不是人能抗拒的。我想到的是如下几点:
1、为什么机器下架不把他搬回公司再进行操作。反思的是,再三确定再三确定。特别是重大操作时。
2、应该从管理角度重视数据的问题,难道因为增加服务器就不进行备份,前后两个月零3天。预算?这事应该会很重视IT工作了。
3、应该从技术角度去规避数据问题,可以添加权限不允许删除,只允许增加数据。rm -rf 在主服务器上应该有限制,另外主服务器的权限一定只能掌握在部分人手里。
4、有主就有从,而主从是通过binlog来进行复制,并且本地sql线程执行。那么册了主的数据,从的数据应该还在啊?怎么会没了,因为不是drop表drop库而是rm -rf 文件。
5、一定要重视数据的备份以及流程,要有规范。
事帮发生之后产生的亮点比问题更多。
历时七天,数据恢复99%。
事故后恢复工作从数据来源分为4条线索进行:
1. 硬盘上数据的恢复(主线)
2. 从memcache导出的数据恢复
3. 从binlog里恢复
4. 从搜索引擎的快照里恢复页面
1、第一时间技术人员商讨怎么办?并制定一系列的措施。确定主线。
2、停止mysql服务,虽然是个技术恢复说是个错误。
3、找数据恢复公司。并不止一家。持续的进行恢复过程。
4、找技术牛人,数据恢复过程有牛人指导是完全不一样的。
5、强大的公关。网站状态发送以及道歉很诚肯。
6、数据云备份,应该还有更多的方案但是没发公布出来。
想到再继续补充。
相关文章推荐
- 单机磁盘故障引发RabbitMQ镜像队列数据丢失
- 一段mongo数据库数据丢失 引发的血案
- 一个WMI模糊查询引发的数据丢失问题
- 由《天猫程序猿高端算法找妹子》引发我对大数据的反思
- 下厨房6月26日数据丢失事故总结
- Raid数据恢复--一次硬盘ID混乱引发的数据丢失
- 单机磁盘故障引发RabbitMQ镜像队列数据丢失
- 下厨房6月26日数据丢失事故总结 MYSQL主分区被rm 命令误删除
- HP磁盘阵列 RAID ADG 数据恢复报告--Rebuild不当引发数据丢失
- 【转】下厨房6月26日数据丢失事故总结
- 自我学习而已——javascript——数据类型部分
- Oracle rman不完全恢复(数据文件,归档日志,控制文件全部丢失)
- 表单在提交过程中的post数据丢失的情况
- Oracle:只有rman备份(数据,参数,日志,控制文件全丢失)的恢复
- 【程序纠错】warning C4819,该文件保存为 Unicode 格式以防止数据丢失
- Easy Recovery帮你解决数据丢失的苦恼
- 不正确的使用HashMap引发死循环及元素丢失
- PHP POST数据丢失
- 手机内存卡丢失数据怎么办
- Oracle表空间中的实际数据文件丢失的恢复