云服务真的靠谱吗？ AWS 用户中断31小时仅恢复6周数据
网络剪报服务商 - Instapaper 遭受了超过31小时的服务中断，而且他们声明还需要一个星期的数据库恢复时间。
Instapaper 是一个网络内容收藏站，允许用户保存“所有有趣的文章，视频，烹饪食谱，歌词或浏览时遇到的任何其他内容”。
但是他们的服务在2月8日中断，官方博客已经在2月9日声明了事情的来龙去脉。
Instapaper 说：我们花费了数个小时和云服务商电话沟通，服务商申明我们的数据库遇到了系统限制，不能提供文章保存服务。我们唯一的选择是导出所有数据，导入新建的数据库。
Instapaper 还说：我们位2016年99.3%的可用性自豪，我们确保用户的数据没有丢失。但是恢复还需要时间。
在经过了 31 个小时的业务中断之后，Instapaper 宣布经过努力，重建数据库实例使得服务重新上线，但是数据仅恢复到最近的 6 个星期，从2016-12-20之后的内容可以访问了。
全部的数据恢复要持续到2月17日，好吧，这是整整10天，用10天去恢复数据，使得用户能够访问自己所有的收藏，这个恢复时间也是相当的惊人！
从该网站的脚本就可以看到，Instapaper 托管在 AWS 云平台上：
鉴于我们的职业性，需要来分析一下故障的原因，并引以为戒。
Instapaper 的数据库是 MySQL 数据库。在该公司工程师的博客上，曾经描述过该网站的架构。
Instapaper 最初的全文检索使用一台 Sphinx 服务器直接和 MySQL 联合提供搜索，这个搜索使用 AWS EC2 大约70GB 内存，4TB 存储的资源：
Instapaper’s full-text search is available to Premium subscribers only, and it was originally set up as a Sphinx server to be used in conjunction with Instapaper’s MySQL database.
Since making the transition to Amazon Web Services, Instapaper’s full-text search has run on a single m2.4xlarge EC2 instance, a memory-optimized instance with ~70GB of RAM. The Sphinx full-text indexes are stored in a 4TB mounted volume, which is a RAID10 array configured as 8 1TB EBS volumes.
Instapaper 的索引数据量（数据库的数据量未知），在2016年5月时数据量2.2TB，每月增长约110GB，后来实在慢的不行，最后选择了 AWS 的 elasticsearch cluster来承载这项服务。
云和恩墨的 MySQL 专家对有限的信息做了分析：
1. 数据库当时，实际上是无法写入数据而非实例挂掉，并且最后的云服务商给出的原因是操作系统限制。从结果逆推原因，会导致数据无法写入而非实例挂掉的，只能是文件存储相关的限制了（内存限制超标的话，会swap变很慢或者直接被oom，cpu计算量的限制，也只是会变慢），这个限制来源很多，操作系统文件系统限制（比如x86的4GB），用户配额限制（文件大小），磁盘容量限制，文中并没有详细提到具体限制来源，只是交代为操作系统限制。
2. 直接决定的处理方式是先导出，之后导入。从最终结果看由于恢复时间过长，并没有作为现在的应急措施，实际上是回退到两个月前的备份（文中提到故障数据库只保存六周的数据，看来是直接使用历史归档数据库提供服务了，基本说明并且当前数据库没有任何备份或者有效备份）。一般来说，MySQL在数据无法写入的时候，实际上的确可以尝试使用select导出来拯救数据，只是并不能保证一定可以成功。
3. 文中提到整个数据库还在导出中，按照时间估计，需要9天时间导出整个故障数据库，猜测导出慢的主要原因：
文档类大型数据，一般采用text等格式，存储的时候会多一跳文件指针。
（猜测）如果采用mysqldump导出，这个软件是纯粹的单线程工具，速度肯定会很慢。
超大数据表的导出，文件指针的跳转本身代价就不小。
建议：
1. 备份。从结果看，生产数据库没有任何备份或者有效备份。
2. 云数据库服务限制，自运维数据库类似的问题，如果在打开双1（或者哪怕innodb_flush_log_at_trx_commit=1）的情况下，直接拷贝数据文件出来就能恢复数据库。
2017 似乎是数据库多灾多难的一年，新年伊始，就有很多故事和事故涌现出来，理一理最近几件事：
还有，如果这个 MySQL 有一个 Slave 备库幸存，该有多好啊？当然即使是 Oracle 数据库 ，配备 DataGuard 也并不多，参考《2016年度中国Oracle数据库使用现状分析报告》：
闲言少叙，数据库的“备份重于一切”，赶紧用 Bethune （https://bethune.enmotech.com）为你的数据库做个巡检压压惊吧，发现潜在问题，早日消除安全隐患！
