AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

GitLab 事故之技术详叙:抢救后恢复在线,已确定下一步计划

  • 2017-02-03
  • 本文字数:4194 字

    阅读完需:约 14 分钟

本文对 GitLab 事件进行了全盘回顾,继续追踪 GitLab 在 2 月 1 日发布的申明,追溯各种问题根本原因。然后陈列了恢复在线后,GitLab 声明了哪些下一步举措。最后摘录了一些网友在 Twitter 和 YouTube 的评论,大多数人都对 GitLab 表达了自己的支持和宽容。

事件总览

2017 年 1 月 31 日 18:00(UTC 时间),GitLab 通过推特发文承认 300GB 生产环境数据因为 UNIX SA 的误操作,已经被彻底删除(后发文补充说明已经挽回部分数据),引起业界一片哗然。

2017 年 2 月 1 日 18:14(UTC 时间),GitLab.com 恢复在线。通过使用一个之前的 6 小时备份数据库,GitLab 申明 1 月 31 日下午 17:20(UTC 时间)至晚上 23:25(UTC 时间)之间的数据已经被恢复并可以在生产环境使用,包括项目、问题、合并请求、用户、注释等等。

GitLab 背景

GitLab 目前是硅谷一颗冉冉升起的新星,它估值 3.29 千万美元并且存放着宝贵的用户数据。

GitLab 是基于 Ruby on Rails 开发的一个开源的版本管理系统,它实现了一个自托管的 Git 项目仓库,支持通过 Web 界面进行访问公开的或者私人项目。

GitLab 拥有与 Github 类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序进行交流。此外,GitLab 提供了一个代码片段收集功能,可以轻松实现代码复用,便于日后有需要的时候进行查找。
自 2012 年上线以来,GitLab 已经被超过 10 万个公司或组织使用,包括 IBM、Alibaba.com、Uber、Intel、VMWare 等等。

事件影响

一句话概述

GitLab 申明指出其一个数据库出现了异常,导致 GitLab.com 丢失 6 个小时的数据库数据(问题、合并请求、用户、注释等等),不过 Git / wiki 存储库和自托管安装不受影响。

五点详情

  1. 大约 6 个小时的数据丢失
  2. 大约丢失 5037 个项目(其中 4613 个常规项目,74 个 fork, 350 个 import)。由于 Git 的 repository 没有任何损失,所以 GitLab 可以重建数据事故之前已经存在的用户 / 组的全部项目,但是并不能修复事故中的任何问题。
  3. 丢失了大约 4979(即 5000)左右的注释。
  4. 可能丢失了 707 个用户,很难准确进行评估(部分源自 Kibana 记录)
  5. 受影响的时间点:1 月 31 日 17:20 之后创建的数据

Offline 前的种种挣扎

首次事故:垃圾邮件用户的数据库负载的峰值

2017 年 1 月 31 日 18:00(UTC 时间)发现垃圾邮件发送者正在通过创建片段方式攻击数据库,目的是让数据库不稳定。工作人员随即开始寻找问题并准备应对方案。

2017 年 1 月 31 日 18:00-21:00(UTC 时间),工作人员(team-member-1 )正在预发布环境安装 pgpool 和备份工具,为了拿到最新的生产环境数据他创建了一个 LVM 快照,这个快照会用于预发布环境,他希望可以重用这个快照用于引导其他的副本。这个操作在丢失数据前的 6 小时完成。

副本启用的过程中发现存在问题,并且需要消耗大量时间(根据估计仅仅是初始化 pg_basebackup 同步过程就需要耗时 20 个小时以上)。LVM 快照在工作人员可以修复问题之前又不能再其他副本上使用。整个修复过程都被这个问题耽搁下来。

2017 年 1 月 31 日 21:00(UTC 时间),开始出现锁定数据库写操作,并引起一些停机情况。进一步进行处理,措施包括锁定垃圾邮件的发送 IP、删除一个用户并启用仓库(造成 47000 个 IP 使用了相同的账户签名,进而导致数据库高负载)、删除垃圾邮件用户。

第二个事故:复制延迟触发警报

2017 年 1 月 31 日 22:00(UTC 时间),数据库备份进展出现落后情况,查明造成原因是备份数据库写入操作时出现异常,导致没有跟上备份节奏。

采取处理措施包括:尝试修复 db2 数据库,这时候备份落后了大概 4GB。然后 db2 集群开始拒绝执行备份作业,db2 集群拒绝连接到 db1,调整 max_wal_senders 为 db2,重启 PostgreSQL 数据库,随即 PostgreSQL 数据库提醒存在很多打开的连接,并拒绝启动服务。管理人员随即调整 max_connections 参数从 8000 调整至 2000,PostgreSQL 随即启动。注意,此时 db2 集群依然拒绝执行备份,处于未知原因的挂起状态。

第三个事故:误删操作

2017 年 1 月 31 日 23:00(UTC 时间),工作人员(team-member-1 )感觉 pg_basebackup 拒绝执行的原因是 PostgreSQL 数据文件夹已经存在,所以决定去移除这个文件夹。执行 rm 操作之后,该工作人员意识到命令正在 db1.cluster.gitlab.com 执行,而不是 db2.cluster.gitlab.com。

2017 年 1 月 31 日 23:27(UTC 时间),工作人员(team-member-1 )终止了删除操作,300GB 的数据仅剩余 4.5GB。

下线,进入紧急状态

GitLab 决定下线 GitLab.com 并将事故通过推特向外公布,并且通过 YouTube 对外进行了修复过程的直播。

思考,罗列问题清单

GitLab 进一步对遇到的问题进行梳理和逐一解释,包括:

  • LVM 镜像默认每 24 小时执行一次。工作人员(team-member-1 )事故发生 6 小时之前手动执行了一次。

  • 常规备份也是 24 小时执行一次,但是工作人员(team-member-1 )无法确定存放于何处。另外一名工作人员(team-member-2)认为这意味着失效,因为产生的文件只有几个字节。

    一名工作人员(Team-member-3):PostgreSQL9.2 的二进制文件开始运行,导致 pg_dump 失败。由于数据库版本设置为 PostgreSQL9.6,最终导致SQL 备份不启用。

  • Azure 上的磁盘镜像只是针对 NFS 服务器,没有针对数据库服务器。

  • 同步过程移除了 webhooks。除非我们可以从过去 24 小时的常规备份中提取这些内容,否则将丢失。

  • 复制过程极度脆弱,很易出错,依赖于一系列 Shell 脚本,而这些脚本的注释很差。

  • S3 备份过程没有正常工作。

  • 当备份失败时,没有可靠的警报 / 分页,在 dev host 上面现在也看到这一点

综上所述,5 个备份 / 复制技术都没有正常工作。无奈之下,我们最终启用 6 小时之前的备份。

pg_basebackup 需要等待主机启动复制过程完毕,这个过程需要 10 分钟。这个过程会导致我们认为复制过程卡住了。使用 strace 命令也看不出什么问题原因。

行动, 恢复过程

GitLab 的官方声明中说明了恢复过程的执行步骤:

  1. 2017 年 2 月 1 日 00:36(UTC 时间),备份 db1.staging.gitlab.com 数据。
  2. 2017 年 2 月 1 日 00:55(UTC 时间),挂载 db1.staging.gitlab.com 到 db1.cluster.gitlab.com。从 /var/opt/gitlab/postgresql/data/ 拷贝数据到生产环境 /var/opt/gitlab/postgresql/data/。
  3. 2017 年 2 月 1 日 01:05(UTC 时间),nfs-share01 服务器被征用作为临时备份服务器,放置于 /var/opt/gitlab/db-meltdown。
  4. 2017 年 2 月 1 日 01:18(UTC 时间),包括还存在的生产环境数据,包括 pg_xlog,命名为 20170131-db-meltodwn-backup.tar.gz。

下面这张图显示了删除和随后恢复事件的时间。

未完,GitLab 下一步打算

Todo list

  1. 为不同的环境改变 Linux 终端的格式或者颜色,例如红色代表生产环境,黄色代表测试环境。针对所有用户在 shell 提示符处显示机器的完整名字,例如 db1.staging.gitlab.com,而不是仅仅是“db1”。: https://gitlab.com/gitlab-com/infrastructure/issues/1094
  2. 针对 postgresql 的文件夹拒绝执行 rm -rf 这样的命令?可以设置命令执行保护或者针对数据库文件夹有对应的备份措施。
  3. 为备份增加提醒:检查 S3 仓库之类的体型。增加图形化界面,显示时间变化后的备份大小,当下降超过 10% 时发出警报。: https://gitlab.com/gitlab-com/infrastructure/issues/1095
  4. 找出为什么 PostgreSQL 在 max_connections 被设置为 8000 之后突然出现问题,这个设置在 2016 年 5 月 13 日就已经完成了。因为这个问题的突然出现导致了其他很多问题。 https://gitlab.com/gitlab-com/infrastructure/issues/1096
  5. 通过 WAL 归档增加备份阈值,这个方法对审计失败也许有用。 https://gitlab.com/gitlab-com/infrastructure/issues/1097
  6. 针对上线产品创建常见问题查找指南手册。
  7. 从一个数据中心移动数据到另一个数据中心可以通过 AxCopy 完成:微软声称这个工具比 rsync 要快很多。看上去这是 Windows 上面的问题,但是没有任何 Windows 专家参与。

五天内公开自省报告

GitLab 官方申明指出丢失生产环境数据是不可以接受的错误,5 天之内 GitLab 将对外发布错误发生及保护措施失效的原因,并将发布一系列措施避免悲剧再次发生。

网友们的关注

GitLab 致谢网友

GitLab 申明最后感谢了共计 42 位网友的外援,他们通过 Twitter 和其他渠道上给出的技术建议。

网友留言

“keturu ta”的评价

我们在日本工作,我们能够理解你们的痛苦和精神上的挫折。我们会一如既往地支持你们。

“Axel Dreyfus”的评价

现在已经很少看到这么开放的工作态度了。祝你们好运,永远支持你们。千万不要针对那个 UNIX SA,他已经瘦了 20 磅(开玩笑)。

“Neer”的评价

这样的事故对于任何人都有可能发生,我鼓励涉及团队不要有挫折感。这篇文章已经开始在社交媒体上流传开来了,让我感到这是一家非常公开和透明的公司。我之前没有听说过这个产品,但是从此以后我会开始使用它。

“Codepotato”的评价

感谢这样的全面解释。问题发生确实让人感觉很丢脸,但是同时也体现了你们对外的开放态度。当务之急我们需要找到办法提升恢复速度。

公开,直播修复过程

除了在网络上对事故进行文字说明,GitLab 还在 YouTube 上直播了其数据库修复过程。该过程视频时长 8 小时,共计有 32 万人次观看。 https://www.youtube.com/watch?v=nc0hPGerSd4

写在后面

事故处理过程中,GitLab 采用了开放的态度,事故发生后第一时间对外公布,并对处理过程进行现场直播,让全世界所有程序员都有机会一起参与恢复过程。GitLab 也针对网友提出的关于肇事工作人员如何处理问题进行了官方回应,表态不会因为这次事件解雇事故相关技术人员。

正是由于这样的开放性姿态,网友并没有对事故的发生而进行谩骂、嘲讽,而是一起通过网络对 GitLab 进行鼓励,对处理事故团队提供积极的技术建议。这样的处理方式可以作为 IT 公司生产环境经典解决案例被写入教科书。

参考资料

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/


感谢木环对本文的审校。

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

2017-02-03 18:008869

评论

发布
暂无评论
发现更多内容

AI、IoT、区块链、自主系统、下一代计算五大技术引领未来供应链发展

京东科技开发者

区块链 AI IoT 供应链

Volcano 监控设计解读,一看就懂

华为云开发者联盟

Kubernetes 云原生 监控 Volcano 计算

微服务容错时,这些技术你要立刻想到

华为云开发者联盟

微服务 线程 服务雪崩 断路器 服务降级

甲方日常 91

句子

工作 随笔杂谈 日常

高阶段位机房管理:3D集装箱数据中心,触发科技“火苗”的燃烧

一只数据鲸鱼

数据可视化 3D可视化 机房管理 数据中心可视化 集装箱式数据中心

灵雀云Kube-OVN进入CNCF沙箱,成为CNCF首个容器网络项目

York

灵雀云 Kubernetes Kube-OVN

HTML5中的拖放功能

我是哪吒

html html5 程序员 面试 大前端

Vue 3自定义指令开发

葡萄城技术团队

代码 or 指令,浅析ARM架构下的函数的调用过程

华为云开发者联盟

函数 任务栈 arm架构

[高并发]高并发分布式锁架构大解密,不是所有的锁都是分布式锁!!

Geek_0o5u34

漫谈HTTP协议

架构精进之路

HTTP 七日更 28天写作

阿里巴巴正式推出2021年金三银四1000道Java工程师面试题手册(含答案)

Java架构追梦

Java 阿里巴巴 面试 架构师 金三银四

Vue3 中 v-if 和 v-show 指令实现的原理 | 源码解读

五柳

源码分析 大前端 Vue3

Elasticsearch 批量查询 mget

escray

elastic 七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

【CSS】波纹效果

德育处主任

CSS小技巧 28天写作 纯CSS

【CSS】不规则阴影

德育处主任

css3 html/css CSS小技巧 28天写作 纯CSS

个人隐私之老话重谈

张老蔫

28天写作

美国大选期间美股迎来大涨,舆情到底有何魔力?

星环科技

人工智能 大数据

前端知识总结输出文章目录大全

梁龙先森

JavaScript 大前端 编程语言 28天写作

机器学习应用设计阶段的 10 个陷阱和 11 个最佳实践

机器学习

数据中台:建立在数据网络效应之上的赛道

奇点云

大数据 数据中台 云原生 数据

面对key数量多和区间查询低效问题:Hash索引趴窝,LSM树申请出场

华为云开发者联盟

数据库 数据 存储 Hash索引 LSM树

你会读书吗?

xcbeyond

读书感悟 读书方式 28天写作

音视频行业不可或缺的功能-云端录制

anyRTC开发者

音视频 WebRTC 在线教育 直播 RTC

区块链作用之数字货币的影响

v16629866266

CSS实现数据统计

德育处主任

大前端 CSS小技巧 28天写作 纯CSS

《论雨伞道德》- 不要和自己的良心捉迷藏

石云升

读书笔记 28天写作 雨伞道德

IDEA 异常退出 解决方法

任广印

IDEA

即构SDK新增焦点语音功能,可实现特定用户语音的聚焦

ZEGO即构

前端模拟假数据(json-server光速入门篇)

德育处主任

json 大前端 Node 28天写作 json-server

【Android Tips】小厂的扫码还能怎么做?

李小四

机器学习 二维码 扫码 微信扫码

GitLab事故之技术详叙:抢救后恢复在线,已确定下一步计划_数据库_周明耀_InfoQ精选文章