求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
从史上八大MySQL事故中学到的经验
 

发布于2013-5-3

 

摘要:本文列举了史上八大MySQL宕机事件原因、影响以及人们从中学到的经验,文中用地震级数来类比宕机事件的严重性和后果,排在最严重层级前两位的是由于亚马逊AWS宕机故障(相当于地震十级和九级)。

本文列举了史上八大MySQL宕机事件原因、影响以及人们从中学到的经验,文中用地震级数来类比宕机事件的严重性和后果,排在最严重层级前两位的是由于亚马逊AWS宕机故障(相当于地震十级和九级)。

一、Percona网站宕机事件

震级:3

发生时长:2011年7月11日

持续时长:数日

地点:加州Pleasanton(幸福屯)

宕机原因:Percona网站主服务器上的3块硬盘损坏,同时因为人员变更,导致未能如预期地恢复,多个网站资产因此下线数小时到数天不等,影响其软件下载及交易。

经验:备份不一定永远正常,不应该对其抱有过多期待。

二、GitHub服务中断

震级:4

发生时间:2012年9月10-11日

持续时长:1:46小时

地点:加州圣弗朗西斯科

宕机原因:GitHub将一对古老的、基于DRBD的MySQL服务器替换成一个拥有3个节点的集群。在合并到新系统时,“活动的”数据库自动出了多个故障转移(failover),同时又因为集群管理软件的错误操作导致性能下降,最终造成网站宕机。

经验:GitHub修改了Pacemaker配置来保证故障转移仅仅可以被运维人员控制。

三、Journal Space所有数据丢失及网站关闭

震级:5

发生时间:2009年1月5日

持续时长:无限期

宕机原因:Journal Space是一个拥有6年历史的博客平台,基于MySQL开发,其唯一的数据库备份机器由RAID系统维护。最终网站的数据前员工的报复行为被重写,最终导致所有用户数据丢失以及网站关闭。

经验:永远不要把驱动器镜像当做备份——它能防范物理故障带来的问题,但是不提供时间点恢复功能。

四、PHPFog共享数据库运行中断

震级:6

发生时间:2012年10月8日

持续时长:8小时

地点:俄勒冈州波特兰

宕机原因:PHPFog将用户数据合并到一个新的共享数据库服务上,但是在合并过程中遭受过多的堆叠连接,最终共享数据库停止响应,因此在共享数据库从快照中恢复前一直处于服务不稳定状态。从问题发生到解决一共历时8小时。

经验:这一事件后,PHPFog加速Amazon RDS用户迁移活动。

五、Couch Surfing因MySQL数据库故障导致服务关闭

震级:7

发生时间:2006年6月

地点:加州圣弗朗西斯科

持续时长:1个月

宕机原因:流行社交网站Couch Surfing曾拥有90000名用户,在2006年遭遇了一场严重的硬盘问题,在试图恢复数据时发现数据库增值备份遭遇问题。其MySQL数据库以及应用关键部分丢失,因此创始人最终关闭了这项服务,随后用户社区又将它重启。

经验:任何MySQL系统必须有一个以上备份服务器;每天都必须验证MySQL备份进程。

六、magnolia因丢失主数据库和备份导致最终无法完全恢复

震级:7

发生时间:2009年1月30日

地点:加州圣弗朗西斯科

持续时长:无限期

宕机原因:Magnolia和Delicious一样,是一个流行的书签服务,基于MySQL数据库。该服务在由于硬盘损坏以及备份系统的错误,丢失了主数据库和备份,最终无法完全恢复。

经验:确保硬件的可靠性非常重要;备份系统是否可行必须得到充分的验证。

七、Amazon RDS宕机事件

震级:9

发生时间:2012年6月29日

持续时长:3小时

地点:弗吉尼亚州北部

用户影响:亚马逊EC2云计算服务以及包括Netflix公司、Heroku、Pinterest、 Quora、HootSuite和Instagram等。

宕机原因:一个被称为derecho的强雷暴天气系统通过弗吉尼亚州北部,使得亚马逊在该地区的设施失去了动力,发电机不能正常运行,消耗应急电源的不间断电源(电源)系统,从而导致运行在Amazon RDS上的大概上千个MySQL数据库宕机。

经验:扩大7*24小时工程师支持团队规模,发生电源系统故障、UPS启动之前完全支持手动操作开启发电机开关。

八、Amazon RDS宕机事件

震级:10

发生时间:2011年4月21日

持续时长:48小时

地点:弗吉尼亚州北部

用户影响:导致使用AWS平台的Reddit、Foursquare、Hootsuite、Quora以及其他多家社交网络服务商成为“受害者” 。

宕机原因:亚马逊修改网络设置,同时在对主网络升级扩容过程中,工程师不慎将主网数据全部切换到从网,由于从网带宽较小,而它的设计目的并非用于主网容灾或备份,因此导致网络堵塞,所有EBS(Elastic Block Store)节点通信全部中断,导致存储着数据和日志的MySQL数据库宕机,其中运行在一个可用区域里41%的MySQL数据库宕机24小时,14.6%宕机48小时。

经验:亚马逊重新审计了网络设置修改流程、增强自动化运维手段以及容灾架构设计。

相关文章 相关文档 相关视频



我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优
 
分享到
 
 


MySQL索引背后的数据结构
MySQL性能调优与架构设计
SQL Server数据库备份与恢复
让数据库飞起来 10大DB2优化
oracle的临时表空间写满磁盘
数据库的跨平台设计
更多...   


并发、大容量、高性能数据库
高级数据库架构设计师
Hadoop原理与实践
Oracle 数据仓库
数据仓库和数据挖掘
Oracle数据库开发与管理


GE 区块链技术与实现培训
航天科工某子公司 Nodejs高级应用开发
中盛益华 卓越管理者必须具备的五项能力
某信息技术公司 Python培训
某博彩IT系统厂商 易用性测试与评估
中国邮储银行 测试成熟度模型集成(TMMI)
中物院 产品经理与产品管理
更多...