返回 登录
1

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的网站可靠性工程团队密切合作,以确保我们从失败中彻底恢复过来,避免再次发生。

评论