揭秘：Instapaper基于AWS上MySQL历时一周的恢复
编辑手记：网络剪报服务商-Instapaper 于2月9日出现了服务中断，故障发生后官方声明需要一个星期的恢复时间。而剖析其故障的原因，是由于最初使用了ext3文件系统，其固有的空间上限2TB导致的服务中断。这个责任该由谁来承担？Amazon的RDS可靠吗？随着故障的解决，我们来听听Instapaper的负责人怎么说。
本文来自Brian Donohue博客的翻译，若有不合理的地方，请参考原文。
正文：
Instapaper服务在2月9日（星期三）12:30到2月10日19:30发生长时间的中断。 在做完全恢复的同时，我们首先利用归档恢复到一个时间点，通过有限的访问来保证服务的连续，而昨天（2月14），我们 已经完成了所有的恢复。
遭遇故障的主系统是MySQL数据库，这套系统我们以托管的方式运行在Amazon的关系型数据库服务上（RDS）。通过这篇文章我将深入剖析故障发生的原因，详细的处理过程，以及为了今后更高效可靠运行我们的应对方案。
原因剖析：
简单来讲，数据库的故障时由于在2014年4月之前创建的RDS实例中的文件上限导致的。2月9号12:30，当Instapaper用户在存放文章的 bookmarks 表上插入数据并做保存的时候，使得对应的数据文件大小超出了2TB，随后其他用户在向该表中插入新的条目的过程中，收到如下报错：
存在2TB上限的根本原因是，该MySQL RDS实例使用了ext3文件系统，该文件系统的最大上限是2TB，而之后创建的实例则使用了ext4文件系统，其对象可以使用的文件大小的上限为6TB。
Instapaper RDS history
2013年4月，betaworks 从Marco Arment 收购了Instapaper，之后我们将Instapaper从软件层迁移至 Amazon 的Web 服务上，这是因为所有的betaworks 的企业都运行在AWS上，这样使得AWS上运行的项目都有技术支撑。迁移过程是由betaworks和他们的两个常规DevOps合作商一起完成的。而之后所有在Instapaper的操作由新组建的团队一起完成，其责任是由当时的团队管理者承担，后来2014年10月，该管理者离开了公司，我就从他那里接管了后续的事情。
故障系统最初的实例是在2013年6月份创建的，2015年初做备份的时候遇到一些性能问题，在经过AWS的技术支持确认后，判断当时使用的硬件和数据库版本过旧，根据他们的建议，如果我们将MySQL数据库进行版本升级到v5.6.19+，就可以解决这个问题。
2015年3月，我们对最初创建的实例做了一个只读的副本复制，为了减少停机时间，对版本的升级和系统的切割过程是在半夜完成的，当时用了不到5分钟时间。
虽然这个只读的副本实例是在2014年4月之后创建的，但由于是之前实例的拷贝，理所当然地继承了老实例的ext3文件系统，上限仍然为2TB。
故障防范
由于对老的文件系统的限制不清楚，因此很难预料到这次事故，我们并没有做任何的防范措施。就目前的情况分析，在RDS的控制台并没有任何形式的监控、告警或者日志能够让我们事先知道我们即将达到2TB的文件上限，也便于及时采取措施。甚至在故障发生后的今天，对于我们遭遇的严重问题，仍然没有任何说明和呈现出来。
如果我们能够事先知道文件的上限，当时就不会对2013年的老实例进行只读的副本迁移，以现在的角度来看，我们作为RDS的用户，有以下两种途径本可以避免这次的事故。
第一种，我们可以将旧系统的数据做一个完整的dump到磁盘，然后通过还原创建新的RDS实例，我们可能需要跟Amazon一起合作，创建一个新的只读的RDS实例，然后再实现切割。
第二种方案是将只读的副本运行在Amazon Aurora上，它是Amazon的托管SQL兼容的数据库系统，我们之前基于成本是考虑过迁移到Aurora上的，然而Aurora只能在一个VPC上运行，而Instapaper仍然运行在EC2-classic上。因此作罢。
但这些方案最终都没有执行，因为我们根本不清楚有这个文件上限存在。
关于备份
RDS的一个很大的好处在于对数据库系统做每日自动备份，我们系统的备份保留了最近十天的。然而，由于这些备份仍然是整个文件系统的快照，同样具有2TB的文件上限。
服务恢复受到限制
在这次由于文件系统故障导致的MySQL实例的故障中，我们没有做有效的灾难恢复方案，文件系统的限制同样导致了备份的限制。
故障发生后，我们与AWS技术支持人员进行长时间电话会谈，与Pinterest站点负责可靠性的工程师讨论了关于文件系统的限制，认识到当前唯一的解决方案是使用完全转储和恢复来重建大小为2.5TB的数据库。Pinterest的SRE团队以尽快的速度指导我们将Instapaper的生产数据库转储到由i2.8xlarge实例提供的5.5TB RAID-0磁盘。
但是在我们进行dump的时候发现，这个过程实在太漫长了，第一阶段的dump花了将近24个小时，第二阶段因为开了并行，但也用了10小时才完成。于是我们决定实施连续性方案，利用当前归档恢复到一个时间点，提供有限访问来保障Instapaper的运行。在故障发生后的31小时后，我们才开始实施了这个方案。之后创建实例并投入生产使用又花了将近6个小时的时间。
由于我们没有对这类故障提前做应对方案，也就没有考虑到通过转储和还原的方式所需要的时间成本。我们最初对于转储时间的预估是6到8个小时，但我们的预测是基于行数的，在操作的过程中发现以行数计算的25%的数据事实上只是实际数据的10% 左右。如果我们早知道重建数据库需要花这么大的代价，我们可能会直接启动有效的服务恢复，从而在很大程度上减少最初的停机时间。
数据还原
当做好服务备份，数据转储完成的时候，下一步就是将所有的转储数据导入到新的文件系统，我们跟RDS的项目团队密切合作，完成了以下两项任务。
1、创建原系统的只读副本。我们在老系统上没有测试过，因此本次使用Aurora是存在很大的风险的。而实际的只读副本从创建到投入使用花了24个小时。
2、创建MySQL数据库的RDS实例，不通过二级索引库将所有的数据导入，这大概花了8个小时；后面又创建了3个二级索引库，每个索引库的创建时间是16小时，在我发布这篇文章（2月14）的时候，最有一个索引库海正在创建中。
当我们意识到创建二级索引库的时间是如此长，Amazon的工程师将一个ext4的文件系统挂到故障数据库上，试图在旧的ext3文件系统和新的ext4文件系统上做异步的数据传输。这个过程大概花了8小时，最终就是通过这种方式将所有的数据和索引完整备份并恢复到了ext4多文件系统上。
Syncing with temporary production database
为了同步故障期间（上周四到周一）的数据，RDS的工程师利用有限归档下恢复得到的临时生产数据库的二进制日志文件，基于行复制创建了一个新的ext4文件系统的备份数据库，这个过程用时三小时。
完整的服务还原
当我们将基于归档的临时数据库的所有数据和索引都同步到exy4文件系统的备份数据库之后，最后一步是修改相关配置将应用指向新库，实现交接。
在我们的整个还原过程中，对用户早期的文章没有造成损失，有数据损失的是后面修改过的文章和故障发生后写的文章。
故障影响
这是所有网页应用程序开发商的噩梦。对于文件系统的上限我们事先毫不知情并且没有任何预防措施，不仅仅导致数据库的故障，连同备份也是不全的。事后我们唯一的解决方案就是将现有数据恢复到基于全新文件系统的全新数据库上。
这个方案后面又被复杂化了，由于我们唯一的接口的托管实例是MySQL数据库，这使文件系统级像rsync一样的解决方案不可能在没有Amazon工程师的直接帮助完成的。
从我们诊断出问题到重建数据库完成，哪怕整个过程非常流畅，也需要至少10个小时才能完成，当然这听起来比总共31个小时的宕机时间和连续5天的访问限制好很多。我只是想说明一下这类问题的严重性，哪怕是在最完美的情况下，仍然是一个很棘手的问题。
我们坚持认为这个问题很难预见和防范，但是缺乏这种类型故障的灾难恢复计划导致了比必要更长的停机和恢复时间。 此外，为了更好地利用可用资源，我们可以事先跟一些专家，包括在Pinterest内部和Amazon网络服务团队，加强沟通，这有利于故障后问题的快速处理。
防范措施
在总结这次事件的时候，我们为系统范围的Instapaper故障制定了更好的解决方案流程，将问题升级到Pinterest站点的可靠性工程团队。
除此，我们会加强对mysql数据库备份的校验，以前是每三个月做一次校验，今后的频率将提升为每个月做一次。
不管以上的措施能不能防范这样的事故发生，但至少会在今后面对类似故障的时候减少响应和处理时间。
Relational database service（关于RDS的声明）
我们将会继续使用Amazon的关系型数据库服务（RDS），虽然这次的事故的确让我们产生失望和顾虑，但这些年在使用Amazon的服务的过程中，作为用户我们不得不承认Amazon是一家可靠并强大的服务公司，RDS提供了快照、故障转移、只读复制等多种优质服务，而这些都远超出了Instapaper团队所能做的。
此外，RDS团队在加速我们的完全恢复方面做出了巨大的帮助， 以Instapaper事故为鉴，他们在服务中添加关于ext3文件系统一些警示和相关信息。
关于责任
关于这件事我认为我该承担全部的责任，尽管关于ext3文件系统的限制我并不清楚，但是对于一项我每天都会接触到的技术来说，哪怕是被托管，我也应该要考虑到这些限制的。除此而外，没有提前做任何灾难恢复的预案也是我的责任，今后将会加强与Pinterest 站点的可靠性团队的合作，保证下次再遇到类似的故障的时候能够游刃有余，有备无患。
以下分享一些网友的评论：
感谢Brian详细的分析和阐释，同样作为AWS的用户，这篇文章给了我很大的警示，今后我将会加强灾难恢复的预案和防范。
-by Ron Heft
我很喜欢Instapaper，从Marco推出的那一天，我几乎每天都会使用，现在也购买其中的一些服务，并享受该平台所创造的一切便利和美好。而在这次事故中，看到Instapaper的负责人能够公平公正地分析，并愿意自己承担责任，这更加让我佩服。
-by John Philpin
感谢这篇文章。使我有机会从别人的错误中学习，作为一个Instapaper用户，我很高兴你能够这么快恢复服务和数据。 我自己从中学到的主要是，也许在某个时候，你就会遇到的严峻的现实问题，要时刻谨记，云只是别人的电脑，要有安全意识。 虽然我没有太多使用RDS，但我不希望在使用任何托管的数据库平台时还要去关心文件系统大小限制。希望云服务提供商能够考虑这一点
-by Jamison Dance
我们总是忙于处理各种事情，根本没有时间去总结思考和学习，在这次的事故中，其实我并不认为易地而处，我们会处理多好。感谢作者能够坦诚地描述事件的来龙去脉将故障透明化，也感谢给作为商业服务开发商的我们提出警示，我们也会加强对灾难恢复的预案和防范措施制定。
-by Steve Johnson
故障完美地解决令人欣慰，而不因事故失去的合作才最难能可贵。如果双赢是完美的最终目的，那么理解和合作，则是最重要的途径。
加入"云和恩墨大讲堂"微信群，参与讨论学习
搜索 盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。