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

忘是亡心i 2021-11-17 15:38 366阅读 0赞

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

2013年06月25日09:24 来源： [CSDN][] 作者：CSDN 摘译 编辑： [王玉圆][Link 1]  [我要评论(0)][0]

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

**　一、Percona网站宕机事件**

震级：3

发生时长：2011年7月11日

持续时长：数日

地点：加州Pleasanton(幸福屯)

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

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

**　二、GitHub服务中断**

震级：4

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

持续时长：1:46小时

地点：加州圣弗朗西斯科

宕机原因：GitHub将一对古老的、基于DRBD的MySQL[服务器][Link 4]替换成一个拥有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年遭遇了一场严重的[硬盘][Link 5]问题，在试图恢复数据时发现数据库增值备份遭遇问题。其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的强雷暴天气系统通过弗吉尼亚州北部，使得亚马逊在该地区的设施失去了动力，发电机不能正常运行，消耗[应急电源][Link 6]的不间断[电源][Link 7]([电源][Link 8])系统，从而导致运行在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小时。

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

摘自：[http://tech.it168.com/a2013/0625/1499/000001499210.shtml][http_tech.it168.com_a2013_0625_1499_000001499210.shtml]

转载于:https://www.cnblogs.com/linbixing828/p/3170459.html

[CSDN]: http://www.csdn.net/article/2013-04-22/2814997-Biggest-MySQL-Disasters
[Link 1]: http://archive.it168.com/user/%CD%F5%D3%F1%D4%B2/
[0]: http://tech.it168.com/a2013/0625/1499/000001499210.shtml#articlecomment
[Link 2]: http://product.it168.com/list/b/0402_1.shtml
[Link 3]: http://product.it168.com/list/b/0218_1.shtml
[Link 4]: http://product.pcpop.com/Server/10734_1.html
[Link 5]: http://product.pcpop.com/HDD/10734_1.html
[Link 6]: http://product.it168.com/list/b/0723_1.shtml
[Link 7]: http://product.it168.com/list/b/0222_1.shtml
[Link 8]: http://product.pcpop.com/Power/10734_1.html
[http_tech.it168.com_a2013_0625_1499_000001499210.shtml]: http://tech.it168.com/a2013/0625/1499/000001499210.shtml