Database
Couch Surfing因MySQL数据库故障导致服务关闭
| 发生时间 | 2006年6月 |
|---|---|
| 地点 | 加州圣弗朗西斯科 |
| 持续时长 | 1个月 |
| 宕机原因 | |
| 流行社交网站Couch Surfing曾拥有90000名用户，在2006年遭遇了一场严重的硬盘问题，在试图恢复数据时发现数据库增值备份遭遇问题。其MySQL数据库以及应用关键部分丢失，因此创始人最终关闭了这项服务，随后用户社区又将它重启。 | |
| 经验 | |
| 任何MySQL系统必须有一个以上备份服务器；每天都必须验证MySQL备份进程。 | |
Journal Space所有数据丢失及网站关闭
| 发生时间 | 2009年1月5日 |
|---|---|
| 持续时长 | 无限期 |
| 宕机原因 | |
| Journal Space是一个拥有6年历史的博客平台，基于MySQL开发，其唯一的数据库备份机器由RAID系统维护。最终网站的数据因前员工的报复行为被重写，最终导致所有用户数据丢失以及网站关闭。 | |
| 经验 | |
| 永远不要把驱动器镜像当做备份——它能防范物理故障带来的问题，但是不提供时间点恢复功能。 | |
Magnolia因丢失主数据库和备份导致最终无法完全恢复
| 发生时间 | 2009年1月30日 |
|---|---|
| 地点 | 加州圣弗朗西斯科 |
| 持续时长 | 无限期 |
| 宕机原因 | |
| Magnolia和Delicious一样，是一个流行的书签服务，基于MySQL数据库。该服务在由于硬盘损坏以及备份系统的错误，丢失了主数据库和备份，最终无法完全恢复。 | |
| 经验 | |
| 确保硬件的可靠性非常重要；备份系统是否可行必须得到充分的验证。 | |
GitHub服务中断
| 发生时间 | 2012年9月10-11日 |
|---|---|
| 持续时长 | 1小时46分 |
| 地点 | 加州圣弗朗西斯科 |
| 相关URL | https://github.com/blog/1261-github-availability-this-week |
| 宕机原因 | |
| GitHub将一对古老的、基于DRBD的MySQL服务器替换成一个拥有3个节点的集群。在合并到新系统时，“活动的”数据库自动出现了多个故障转移（failover），同时又因为集群管理软件的错误操作导致性能下降，最终造成网站宕机。 | |
| 经验 | |
| GitHub修改了Pacemaker配置来保证故障转移仅仅可以被运维人员控制。 | |
Amazon RDS宕机事件
| 发生时间 | 2011年4月21日 |
|---|---|
| 持续时长 | 48小时 |
| 地点 | 弗吉尼亚州北部 |
| 用户影响 | |
| 导致使用AWS平台的Reddit、Foursquare、Hootsuite、Quora以及其他多家社交网络服务商成为“受害者” 。 | |
| 宕机原因 | |
| 亚马逊修改网络设置，同时在对主网络升级扩容过程中，工程师不慎将主网数据全部切换到从网，由于从网带宽较小，而它的设计目的并非用于主网容灾或备份，因此导致网络堵塞，所有EBS(Elastic Block Store)节点通信全部中断，导致存储着数据和日志的MySQL数据库宕机，其中运行在一个可用区域里41%的MySQL数据库宕机24小时，14.6%宕机48小时。 | |
| 经验 | |
| 亚马逊重新审计了网络设置修改流程、增强自动化运维手段以及容灾架构设计。 | |
Percona网站宕机事件
| 发生时长 | 2011年7月11日 |
|---|---|
| 持续时长 | 数日 |
| 地点 | 加州Pleasanton(幸福屯) |
| 宕机原因 | |
| Percona网站主服务器上的3块硬盘损坏，同时因为人员变更，导致未能如预期地恢复，多个网站资产因此下线数小时到数天不等，影响其软件下载及交易。 | |
| 经验 | |
| 备份不一定永远正常，不应该对其抱有过多期待。 | |
Amazon RDS宕机事件
| 发生时间 | 2012年6月29日 |
|---|---|
| 持续时长 | 3小时 |
| 地点 | 弗吉尼亚州北部 |
| 用户影响 | |
| 亚马逊EC2云计算服务以及包括Netflix公司、Heroku、Pinterest、 Quora、HootSuite和Instagram等。 | |
| 宕机原因 | |
| 一个被称为derecho的强雷暴天气系统通过弗吉尼亚州北部，使得亚马逊在该地区的设施失去了动力，发电机不能正常运行，消耗应急电源的不间断电源(电源)系统，从而导致运行在Amazon RDS上的大概上千个MySQL数据库宕机。 | |
| 经验 | |
| 扩大7*24小时工程师支持团队规模，发生电源系统故障、UPS启动之前完全支持手动操作开启发电机开关。 | |
PHPFog共享数据库运行中断
| 发生时间 | 2012年10月8日 |
|---|---|
| 持续时长 | 8小时 |
| 地点 | 俄勒冈州波特兰 |
| 宕机原因 | |
| PHPFog将用户数据合并到一个新的共享数据库服务上，但是在合并过程中遭受过多的堆叠连接，最终共享数据库停止响应，因此在共享数据库从快照中恢复前一直处于服务不稳定状态。从问题发生到解决一共历时8小时。 | |
| 经验 | |
| 这一事件后，PHPFog加速Amazon RDS用户迁移活动。 | |
Programme
Cloudflare DNS解析失败
| 发生时间 | 2017年1月 |
|---|---|
| 持续时长 | 6小时45分 |
| 宕机原因 | |
| 在新年第一天协调世界时（UTC）子夜，在Cloudflare的自定义RRDNS软件内部深处，一个数字本该在最糟糕的情况下总是为零，结果却变成负数。稍后，这个负值引起RRDNS“恐慌”。这个恐慌是使用Go语言的恢复特性而发现的。最终影响就是，为Cloudflare的一些托管网站提供的一些DNS解析以失败告终。 | |
| 经验 | |
| 程序获取的时间不总是增长的，即后运行的代码获取的时间可能小于先运行的代码获取的时间。 | |