（转）从史上八大MySQL宕机事故中学到的经验

　一、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小时。　　经验：亚马逊重新审计了网络设置修改流程、增强自动化运维手段以及容灾架构设计。