从史上八大MySQL事故中学到的经验

本文列举了史上八大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小时。