从史上八大MySQL宕机事故中学到的经验
【IT168 评论】本文列举了史上八大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小时。
经验：亚马逊重新审计了网络设置修改流程、增强自动化运维手段以及容灾架构设计。