云服务真的靠谱吗? 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 似乎是数据库多灾多难的一年,新年伊始,就有很多故事和事故涌现出来,理一理最近几件事:

五重备份无一有效,还有哪些 rm -rf 和GitLab类似的忧伤? 关于炉石传说的Oracle数据库故障不要以为你也可以幸免

讲真,你应该验证你的备份有效性了

还有,如果这个 MySQL 有一个 Slave 备库幸存,该有多好啊?当然即使是 Oracle 数据库 ,配备 DataGuard 也并不多,参考《2016年度中国Oracle数据库使用现状分析报告》:


原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-02-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏移动开发试验田

【移动开发】市面上主流「移动推送服务」的体验比较

推送服务基本上是每个 App 的刚需,自己也用过许多家推送服务,最近腾讯云上线了一个类似于 firebase 的移动开发平台,上面集成了很多的移动服务,包括推送...

3487
来自专栏喔家ArchiSelf

解读六边形架构

追溯微服务架构的渊源,一般会涉及到六边形架构。追溯六边形架构的起源,要看始作俑者Alistair Cockburn的这篇文章 http://alistair.c...

1063
来自专栏美团技术团队

大众点评账号业务高可用进阶之路

1633
来自专栏Android群英传

震惊!我逆向了Android代码居然看见……

941
来自专栏JavaQ

不得不推荐的开发利器

子曰:“工欲善其事,必先利其器“,事先把工具准备好,可以起到事半功倍的效果,本篇将介绍开发过程中经常使用到的开发工具们。

1752
来自专栏FreeBuf

关于Fuzz工具的那些事儿

前段时间一直在研究fuzz工具,这里就写篇文章总结一下下。 在安全测试中,模糊测试(fuzz testing)是一种介于完全的手工渗透测试与完全的自动化测试之间...

7255
来自专栏郭耀华‘s Blog

【绝对给力】Android开发免豆资料(教程+工具+源码)地址汇总

教程下载: 【免费】android界面效果全汇总.pdf http://down.51cto.com/data/209179 Android终极开发教程...

3829
来自专栏cloudskyme

模块化服务规范——OSGI

什么是OSGI OSGi(Open Service Gateway Initiative)有双重含义。一方面它指OSGi Alliance组织;另一方面指该组织...

3973
来自专栏编程一生

架构师之路--视频业务介绍,离线服务架构和各种集群原理

1352
来自专栏.NET技术

正确理解CAP定理

  CAP的理解我也看了很多书籍,也看了不少同行的博文,基本每个人的理解都不一样,而布鲁尔教授得定义又太过的简单,没有具体描述和场景案例分析。因此自己参考部分资...

1062

扫码关注云+社区