BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

调查报告深入揭示了GitLab.com服务中断18小时的根本原因

| 作者 David Iffland 关注 4 他的粉丝 ,译者 Rays 关注 3 他的粉丝 发布于 2017年3月1日. 估计阅读时间: 3 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

在结束故障并清除了问题后,GitLab给出一个帖子,总结了导致长达18小时服务中断的原因、他们计划如何继续发展,以及整个事故是如何发生的。

数据库的高负载在一开始被诊断为大量垃圾邮件的涌入。但是在进一步审查后,明确了是由于无事生非的家伙将一位GitLab员工举报为滥用,事故因此而恶化了。另一位员工在审查滥用报告时并没有意识到被举报的账号其实是团队中一位工程师的账号,因此意外地删除了该账号:

我们随后发现这一部分负载是由一个后台任务试图去移除GitLab员工及其相关数据所导致的。这就是他们的账号被标识为滥用并意外地被删除的结果。

根据作为当事人的工程师在故障报告中的记录,他的账号被删除是因为“我们收到来自一位用户的垃圾邮件报告,该用户是在发出垃圾邮件报告的10分钟前创建的。这就产生了人为错误,删除了我的所有项目。”

由于数据库负载的加重,预写式日志 (WAL,Write-Ahead Log)在得到从数据库处理之前就被主数据库清洗掉了,导致主数据库停止向从数据库复制。不幸的是,WAL归档也并未被打开。WAL归档会要求数据段在得到移除许可前被归档。

由于复制已经停止了,需要对从数据库做一次重建。启动复制需要一个空的数据目录,因此一位工程师手工清理干净了一个目录。但该目录并非是从数据库的数据目录,他意外地清除了主数据库的数据目录。

虽然主数据库的不幸损失应该只会让站点关闭一小段时间,但是对于GitLab团队而言事情更糟。在努力恢复数据的过程中,团队发现自己的备份无法工作。作为备份的主要方法的pg_dump由于版本不匹配的问题而不能运行,因此并未备份任何东西。没有人知道存在这个失败,通知邮件因为不支持DMARC被服务器拒收。

其它的备份方法也因为各种原因而无法使用,团队并未对数据库使用Azure磁盘快照。即使使用了磁盘快照,在线取回数据也将花费很长的时间:

每个存储账号的限制大概为30TB。恢复快照时使用同一存储账号中的主机通常会完成得很快。但是当用在不同存储账号中的主机时,完成该过程将需要数小时乃至数天。

唯一的方法是恢复事故发生之前六个小时的LVM快照。

团队在改进他们的修复恢复过程中碰上了14个问题,最终完成了快照的恢复。他们在事故发生后两个星期中实现了WAL-E,功能是将WAL数据段实时地归档到AWS S3。对一次恢复的测试表明,这种备份类型在两个小时以内就可以恢复到指定的时间点。此外,他们正在实现一个自动测试PostgreSQL备份恢复的系统。

查看英文原文: GitLab.com Postmortem Digs into Root Causes of 18 Hour Outage


感谢薛命灯对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT