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

相关文章

来自专栏分布式系统进阶

Kafka的消费积压监控-Burrow

843
来自专栏吴伟祥

MySQL基准测试 转

基准测试是  指通过设计科学的测试方法、测试工具和测试系统,实现对一类测试对象的某项性能指标进行定量的和可对比的测试。例如,对计算机CPU进行浮点运算、数据访问...

803
来自专栏小怪聊职场

大数据|zookeeper简介及3个简单易懂的案例分析(一)

2655
来自专栏Linyb极客之路

通用型系统架构设计

Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总...

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

datapump跨平台升级迁移的对比测试和优化 (r8笔记第81天)

目前计划对跨平台的数据库环境进行迁移,一来降低运维成本,二来更加可控。其实对于很多机器来说,如果机器跑了很多年,一直没有重启过,那么时间长了,一 个直...

34711
来自专栏架构师小秘圈

大型网站图片服务器架构的演进

作者:丁浪,非著名架构师。关注高并发、高可用的架构设计,对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技术研究和分享。 声明:版权归丁浪...

3354
来自专栏北京马哥教育

服务器程序源代码分析之二:php-fpm

php作为排名top2 互联网开发工具,非常流行,可以参考:中国最大的25个网站采用技术选型方案 php这个名称实际上有两层含义 广义的php 是指用后缀名为....

2704
来自专栏编程一生

干货 | 云智慧透视宝Java代码性能监控实现原理

1152
来自专栏高性能服务器开发

(八)高性能服务器架构设计总结4——以flamigo服务器代码为例

一个项目的服务器端往往由很多服务组成,就算单个服务在性能上做到极致,支持的并发数量也是有限的。举个简单的例子,假如一个聊天服务器,每个用户的信息是1k,那对于一...

785
来自专栏SDNLAB

从NETCONF/YANG看网络配置自动化

1 引子 NETCONF和YANG的目的是以可编程的方式实现网络配置的自动化,从而简化和加快网络设备和服务的部署,为网络运营商和企业用户节约成本。NETCONF...

3015

扫描关注云+社区