|
编辑手记：网络剪报服务商-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
故障防范 由于对老的文件系统的限制不清楚，因此很难预料到这次事故，我们并没有做任何的防范措施。就目前的情况分析，在RDS的控制台并没有任何形式的监控、告警或者日志能够让我们事先知道我们即将达到2TB的文件上限，也便于及时采取措施。甚至在故障发生后的今天，对于我们遭遇的严重问题，仍然没有任何说明和呈现出来。 如果我们能够事先知道文件的上限，当时就不会对2013年的老实例进行只读的副本迁移，以现在的角度来看，我们作为RDS的用户，有以下两种途径本可以避免这次的事故。
但这些方案最终都没有执行，因为我们根本不清楚有这个文件上限存在。 关于备份 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的项目团队密切合作，完成了以下两项任务。
当我们意识到创建二级索引库的时间是如此长，Amazon的工程师将一个ext4的文件系统挂到故障数据库上，试图在旧的ext3文件系统和新的ext4文件系统上做异步的数据传输。这个过程大概花了8小时，最终就是通过这种方式将所有的数据和索引完整备份并恢复到了ext4多文件系统上。 Syncing with temporary production database为了同步故障期间（上周四到周一）的数据，RDS的工程师利用有限归档下恢复得到的临时生产数据库的二进制日志文件，基于行复制创建了一个新的ext4文件系统的备份数据库，这个过程用时三小时。 完整的服务还原当我们将基于归档的临时数据库的所有数据和索引都同步到exy4文件系统的备份数据库之后，最后一步是修改相关配置将应用指向新库，实现交接。 在我们的整个还原过程中，对用户早期的文章没有造成损失，有数据损失的是后面修改过的文章和故障发生后写的文章。 故障影响这是所有网页应用程序开发商的噩梦。对于文件系统的上限我们事先毫不知情并且没有任何预防措施，不仅仅导致数据库的故障，连同备份也是不全的。事后我们唯一的解决方案就是将现有数据恢复到基于全新文件系统的全新数据库上。 这个方案后面又被复杂化了，由于我们唯一的接口的托管实例是MySQL数据库，这使文件系统级像rsync一样的解决方案不可能在没有Amazon工程师的直接帮助完成的。 从我们诊断出问题到重建数据库完成，哪怕整个过程非常流畅，也需要至少10个小时才能完成，当然这听起来比总共31个小时的宕机时间和连续5天的访问限制好很多。我只是想说明一下这类问题的严重性，哪怕是在最完美的情况下，仍然是一个很棘手的问题。 我们坚持认为这个问题很难预见和防范，但是缺乏这种类型故障的灾难恢复计划导致了比必要更长的停机和恢复时间。 此外，为了更好地利用可用资源，我们可以事先跟一些专家，包括在Pinterest内部和Amazon网络服务团队，加强沟通，这有利于故障后问题的快速处理。 防范措施
不管以上的措施能不能防范这样的事故发生，但至少会在今后面对类似故障的时候减少响应和处理时间。 Relational database service（关于RDS的声明）我们将会继续使用Amazon的关系型数据库服务（RDS），虽然这次的事故的确让我们产生失望和顾虑，但这些年在使用Amazon的服务的过程中，作为用户我们不得不承认Amazon是一家可靠并强大的服务公司，RDS提供了快照、故障转移、只读复制等多种优质服务，而这些都远超出了Instapaper团队所能做的。 此外，RDS团队在加速我们的完全恢复方面做出了巨大的帮助， 以Instapaper事故为鉴，他们在服务中添加关于ext3文件系统一些警示和相关信息。 关于责任关于这件事我认为我该承担全部的责任，尽管关于ext3文件系统的限制我并不清楚，但是对于一项我每天都会接触到的技术来说，哪怕是被托管，我也应该要考虑到这些限制的。除此而外，没有提前做任何灾难恢复的预案也是我的责任，今后将会加强与Pinterest 站点的可靠性团队的合作，保证下次再遇到类似的故障的时候能够游刃有余，有备无患。
以下分享一些网友的评论：
-by Ron Heft
-by John Philpin
-by Jamison Dance
-by Steve Johnson 故障完美地解决令人欣慰，而不因事故失去的合作才最难能可贵。如果双赢是完美的最终目的，那么理解和合作，则是最重要的途径。 加入"云和恩墨大讲堂"微信群，参与讨论学习 |
|
|
