云服务真的靠谱吗? 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 条评论
登录 后参与评论

相关文章

来自专栏贾老师の博客

关于 docker 的一些总结和观点

1195
来自专栏Android 开发者

Android P 电量管理

Android P 在现有平台的功能基础上加入多项新特性以提升设备电量管理能力,确保系统对应用进行最合适的资源分配。

1653
来自专栏用户2442861的专栏

关于图片或者文件在数据库的存储方式归纳

http://www.cnblogs.com/wangtao_20/p/3440570.html

851
来自专栏安智客

TUI设计概要

TUI是TEE的一个重要基础模块。最初人们认识了解TEE最直观的展示就是TUI,早在指纹识别成为手机的标配之前,TEE的主要应用是围绕着TUI进行,但由于普适性...

1054
来自专栏为数不多的Android技巧

Android插件化原理解析——概要

2015年是Android插件化技术突飞猛进的一年,随着业务的发展各大厂商都碰到了Android Native平台的瓶颈:

562
来自专栏企鹅号快讯

PoS端恶意软件LockPoS再次苏醒 携来新型代码注入技术

“用指尖改变世界” ? 以色列网络安全公司Cyberbit的研究人员表示,通过僵尸网络Flokibot分发的PoS端恶意软件LockPoS已经从一段时间的沉睡中...

1825
来自专栏大内老A

WCF传输安全(Transfer Security)的基本概念和原理:认证(Authentication)[上篇]

对于任何一个企业级应用来说,安全(Security)都是一个不可回避的话题。如何识别用户的身份?如何将用户可执行的操作和可访问的资源限制在其允许的权限范围之内?...

1688
来自专栏架构师之路

feed留,单聊群聊,系统通知,状态同步,到底是推还是拉?

可以理解为一个发布订阅业务,典型业务是微博(朋友圈)。你关注了姚晨的微博,姚晨发布了消息,你的主页能看到她最新发布的消息,这个场景是推送,还是拉取呢?

1053
来自专栏杨建荣的学习笔记

运维平台的建设思考-元数据管理(r7笔记第57天)

之前也写过一篇比较基本的文章,也算是自己对运维平台的一个基本思考。运维平台的建设思考(r6笔记第20天) 当然想法简单,而且缺乏实践,但是朝着这个方向迈进是没有...

3725
来自专栏「3306 Pai」社区

构建MySQL自动化平台思路

这里做个小预告,可能下周或者下下周。我的好基友顺子要给大家讲讲MHA的故事。请期待~~

852

扫码关注云+社区