一位工程师删除了GitLab的生产数据库。300 GB。
2017年1月31日,世界标准时间23:27:一位GitLab工程师在熬夜修复一个损坏的副本时,不小心删除了db1而非db2上的PostgreSQL数据目录。
2017年1月31日,世界标准时间23:27:一位GitLab工程师在熬夜修复一个损坏的副本时,不小心删除了db1而非db2上的PostgreSQL数据目录。db1是主数据库。GitLab.com大约300 GB的数据库在一两秒内消失了,而且五个备份和复制机制都失效了。事后分析:从垃圾邮件高峰到错误主机名的时间线,pg_basebackup为何看似卡住,pg_dump为何一直静默失败(9.2二进制文件在9.6数据库上,失败邮件被DMARC退回),从6小时前暂存快照恢复的18小时过程在YouTube上直播,以及谁应该真正承担责任。对响应的评价:SHIP IT。
本视频涵盖的内容
- 2017年1月31日:在主数据库的数据目录上执行rm -Rvf;约300 GB被删除,留下4.5 GB
- 5个备份全部失败:S3桶为空(pg_dump版本不匹配),数据库没有Azure快照,副本被清除,每日LVM复制没有Webhooks
- 2月1日,世界标准时间18:00:GitLab.com从6小时前的手动快照恢复;实时文档、直播、附带修复列表的无责事后分析
翻译的文字记录
译自英文原版旁白。可用音频和字幕由 YouTube 控制。
0:00 GitLab的一名工程师在错误的数据库服务器上运行了 rm -rf, 然后 GitLab.com 的三百吉字节数据在一两秒内消失了, 这大约是读取一个主机名所需的时间。 2017年1月31日,晚上11:27, 世界标准时间。GitLab 发推称其不小心删除了生产数据, 向互联网公开了事故记录,并在 YouTube 上直播了恢复过程, 这是该平台第二热门的直播。 第二天,书面声明:五种备份技术中,
0:25 没有一种能可靠运行。 它是如何发生的,为什么会发生,以及谁应该真正承担责任。 这里是 The Daily Diff,事后分析。 下午5:20:一名工程师制作了生产快照, 以测试暂存环境中的负载均衡器。 晚上7点:垃圾邮件攻击数据库,以及一个硬删除GitLab员工的作业, 该员工因被举报滥用行为。 晚上11点:副本落后太多,以至于主数据库已经丢弃了
0:48 它所需的日志;唯一的修复方法是清除副本并重新复制主数据库。 pg_basebackup 挂起,没有输出。 它实际上是在静默等待主数据库;没有人知道这一点, 操作手册也没有说明。 这位工程师本打算在11点下班,他认为空数据目录是问题所在,并将其删除。 他认为空数据目录是问题所在并将其删除。 在 db1 上。主数据库。 一两秒后他注意到了;大约三百吉字节的数据中,
1:11 剩下4.5 GB。备份。 第一:pg_dump 到 S3,每日执行。 桶是空的。 cron 任务在一个没有数据库的应用服务器上运行,所以软件包选择了 用于 9.6 数据库的 PostgreSQL 9.2 二进制文件,失败,并发送邮件 失败通知,由于缺少 DMARC 而被退回。 第二:Azure 磁盘快照,为文件服务器启用, 而不是数据库。
1:32 第三:副本,一小时前被故意清除。 第四:每日快照,24小时前,所有 webhook 被 暂存同步剥离。第五:下午5:20的手动快照,用于不相关的测试。 这个快照成功了。 恢复意味着以每秒六十兆比特的速度,通过 Azure 的廉价存储将暂存磁盘复制回生产环境: 需要十八个小时。 GitLab.com 于2月1日晚上6点恢复。 世界标准时间,数据落后六小时。
1:58 git blame:两个主机名仅相差一个字符,以及五个从未有人 恢复过的备份系统。 不是工程师的错。 由首席执行官签署的事后报告让他匿名, 将生产提示符设为红色,并为数据持久性指定了负责人, 因为在此之前它没有负责人。 影响范围:停机十八小时,数据丢失六小时, 大约五千个项目,五千条评论,
2:18 七百个新用户,以及五千人看着进度条。 Hacker News 给这份实时文档打了1,162分,并引用了其中一句话 回复他们:五个备份中,没有一个可用。 裁决,事后分析:对响应的评价是 SHIP IT。 他们公开处理了事故,归咎于流程,并发布了带有问题编号的修复列表。 并发布了带有问题编号的修复列表。 周一行动:恢复备份。 如果你从未恢复过它,你就是没有备份。
2:42 把你仍然不被允许谈论的事故发给我, 在评论区,或发送至 the daily diff dot dev。 这就是今天的 The Daily Diff。 我是 Axrisi 的 Niko。 负责任地合并。
来源
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com



