Instapaper宕机原因及故障恢复过程详解

原文：Instapaper Outage Cause & Recovery
作者： Brian Donohue
翻译：黑色巧克力

译者注：Instapaper一项保存网页以便稍后阅读的服务，它曾经历过长时间的中断，作者作为运营总监给我们讲述了故障的原因和恢复过程。

Instapaper服务于周三(2月9日)至2月10日(周四)下午7时30分之间出现了长时间的中断，我们将Instapaper服务作为一个短期的解决方案，提供了有限的访问权，同时我们也在努力恢复服务。2月14日，我们完成了服务的全面恢复。

失败的关键系统是我们的MySQL数据库，该数据库作为托管解决方案在Amazon的关系数据库服务(RDS)上运行。下面将讨论哪里出了问题，如何解决问题，以及怎样提高可靠性。

根本原因

简而言之，数据故障是由2014年4月之前创建的RDS实例的2TB文件大小限制造成的。2月9日(星期三)下午12:30，我们的“书签”表，存储了Instapaper用户保存的文章，超过了2TB文件的大小限制。随后在书签表中插入新条目开始抛出以下错误:

OperationalError: (OperationalError) (1114, "The table 'bookmarks' is full")

之所以存在这种限制，是因为在2014年4月之前创建的MySQL RDS实例使用了具有2TB文件大小限制的ext3文件系统。而2014年4月以后创建的实例由ext4文件系统支持，并受6TB文件大小限制。

Instapaper的RDS历史

2013年4月，betaworks从Marco Arment获得Instapaper。收购后，我们将Instapaper从Softlayer迁移到Amazon Web Services，因为所有betaworks公司都在AWS上运行，因此工程师在该平台上拥有专业知识。为了执行迁移，betaworks与他们的两个常规开发承包人一起工作。迁移后，运营被移交给新成立的Instapaper团队，运营责任落在我们的工程总监身上。2014年10月，我们的工程总监离开公司后，我接手了后期运营。

我们的原始实例在2013年6月创建，在2015年初的备份窗口中遇到一些性能问题。AWS支持是在旧硬件上和旧版本的MySQL v5.6.18上运行。如果我们升级到最新的版本(v5.6.19 +)，AWS问题将得到解决。

在2015年3月，我们创建了一个2013年6月的RDS实例的读取副本，升级了MySQL版本，并在午夜的时候完成了转换开关操作——大约5分钟。尽管这个实例是在2014年4月之后创建的，但它作为一个从原始的RDS实例中创建的一个副读本，因此，它继承了相同的文件系统和2TB文件大小的限制。

预防

如果不了解2014年4月前的文件大小限制，就很难预见和防止这个问题。据我们所知，RDS控制台的监控、警报或日志记录中没有任何信息可以让得知正在接近2TB文件的大小限制。即使是现在，也没有任何迹象表明托管数据库存在关键问题。

如果对文件大小的限制有所了解，那么很可能会在2013年的betaworks承包人的基础上继续进行软层迁移。就我们所知只有两种方式，作为RDS的客户，本可以阻止这个问题。

首先，可以将数据库完全转储到磁盘，然后将数据库恢复到新的RDS实例。在这个场景中，可能需要直接与Amazon一起工作，以将新的RDS实例设置为旧版本的读取副本，然后执行切换。

另一个选择是创建一个运行Amazon Aurora的读取副本，亚马逊的托管sql兼容数据库系统。我们之前曾考虑过迁移Aurora(主要是为了节约成本)，但是Aurora只在VPC上运行，而Instapaper仍然运行在EC2-classic上。

然而最终，不太可能在不了解局限性的情况下进行这些操作。

备份

RDS的一个重要特性是自动的备份数据库实例。我们为MySQL数据库存储了10天的备份。但是，由于这些备份都是文件系统快照，所以它们也会受到2TB文件大小的限制。

有限服务恢复

这次事件中没有一个好的灾难恢复计划，因为一个关键的文件系统问题MySQL实例失效，所有的备份也受到了影响。

在用AWS支持并与Pinterest网站可靠性工程师讨论限制之后，我们了解到唯一出路是使用完整的转储和恢复重建2.5 TB数据库。Pinterest的SRE团队尽可能快地引导我们通过将Instapaper的生产数据库提交给由i2.8xlarge实例提供的5.5TB raid-0磁盘。

当思路变得清晰时，转储将花费很长时间(第一次花费24小时，第二次使用并行化花费了10个小时)，我们开始执行一项应急计划，从Instapaper存档中访问有限的工作状态来获得一个实例。这一短期解决方案在停工31小时后投入生产。创建该实例并将其投入生产的总时间大约为6个小时。

由于没有针对这类事件的计划，所以对转储和恢复数据库所需的时间没有很好的把握。对数据库转储的初步估计是6到8小时。但我们使用行数进行了估计，之后学习了前25%的Instapaper书签只占全部数据的10%。如果知道重建数据库将是连日的工作，我们需要直接启动有限的服务恢复，那么我们就可以大大减少初始停机时间。

数据恢复

当服务返回并完成数据转储之后，下一步是将所有的转储导入到一个不受2TB文件大小限制的实例中。我们在整个周末与RDS工程师紧密合作，以实现两种并行工作流程:

1. 设置一个Aurora阅读复制的旧数据库。我们同意使用Aurora是有风险的，因为我们没有对Instapaper代码库进行彻底的测试，但设置的阻力很小。阅读的复制品大约在24小时内完成。
2. 创建一个新的MySQL RDS实例，导入所有没有二级索引(8小时)的数据，并在导入数据之后创建三个二级索引(每个二级索引大约花费16小时)。写这篇文章的时候，最后一个二级索引仍在创建中。

在认识到二级索引创建时间长得不可接受之后，其中一位Amazon工程师将ext4文件系统安装到失败的生产数据库中，并在ext3文件系统和ext4文件系统之间执行了rsync。rsync在大约8小时内运行，最终为我们提供了一个新的、ext4支持的数据库实例，并恢复了所有数据和索引。

与临时生产数据库同步

使用来自临时生产数据库的二进制日志(带有限的存档)，RDS工程师将新的ext4支持的数据库建立在临时生产数据库上，以便同步周四和周一之间的更改。这个复制的总时间大约是三个小时。

全部服务恢复

一旦拥有新的ext4支持的数据库，并将完整的数据和索引与临时生产数据库同步，最后一步是推广新数据库，并部署应用程序代码以指向新数据库。

我们在不丢失任何用户旧文章的情况下进行了恢复，并更改了最近的文章或在从中断中恢复后保存的文章。

反射

这是任何web应用程序开发人员最糟糕的噩梦。不知道基于文件系统的限制和没有可见性，不仅使生产数据库变得无用，也使所有的备份失效。唯一的方法是将数据恢复到一个拥有全新实例的新文件系统上。由于托管实例中唯一的接口是MySQL，这使得在没有Amazon工程师的直接帮助下，让类似rsync的文件系统级的解决方案难以实现，因此变得更加复杂。

即使已经完美地执行了全新实例，从诊断出问题到完全重建数据库的那一刻起，总停机时间至少是10个小时。当然，这远远少于总停机时间和五天有限访问的时间，但只是希望在一个完美的世界中说明这类问题的严重性。

我们坚信这一问题很难预见和预防，但由于缺乏灾难恢复计划，从而导致经济的下降和恢复的时间比必要的时间更长。此外，还可以从通信的角度，在Pinterest和Amazon Web服务团队中采取措施，以便更好地利用相关的处理资源。

行动项目

作为在Pinterest上回顾过程的一部分，我们定义了一个更好的工作流，适用于系统范围的Instapaper中断，使问题立即升级到Pinterest的站点可靠性工程团队。

另外，我们将更积极地测试MySQL备份。过去每三个月测试一次备份，现在将每个月测试一次。

上述两项操作都不会阻止问题的发生，但是它们会在发生故障时加速我们的响应时间，并且是很好的实践。

关系数据库服务

我们现在将继续使用Amazon的关系数据库服务。尽管在没有警告或可见性的情况下体验问题是令人沮丧的，但是RDS一直是一种可靠而健壮的服务，可以在未来的几年时间内使用，并处理快照、读取复制和其他任务，而不需要从Instapaper团队获得任何工程开销。

此外，RDS团队对加速全面恢复非常有帮助。他们甚至向我们提出了一个特别请求，以添加关于ext3支持数据库的一些附加信息。

问责制

我需要对事故和停工负责，虽然关于2TB限制的信息没有直接向我提供，但有责任了解在日常操作中使用的技术局限性，即使这些技术是由另一家公司托管的。此外，我还需要对缺乏适当的灾难恢复计划负责，并将与Pinterest的网站可靠性工程团队密切合作，以确保我们从失败中彻底恢复过来，避免再次发生。